Skip to content

[aw-failures] [Auto-Triage Issues] Bash allow-list excludes printf, blocking safeoutputs noop invocations and producing empty items[] #31285

Description

@github-actions

Problem statement

Auto-Triage Issues (engine: copilot, model: gpt-5-mini) is silently producing empty safe-output manifests on every scheduled run, then being flagged by the framework's safe-outputs detector as No Safe Outputs Generated.

Both scheduled runs in the last 6 hours show this pattern:

Run Started Conclusion agent_output.json items Failure tracker
§25608959573 2026-05-09 18:45 UTC success [] #31265 (initial body)
§25616399713 2026-05-10 01:17 UTC success [] #31265 (auto-comment 01:22 UTC)

Root cause

The agent reaches for the safeoutputs CLI via shell to satisfy the workflow's required-safe-output rule (no unlabeled issues found → noop). It uses the documented JSON-on-stdin pattern from the framework's mcp-clis system prompt:

printf '{"message":"No action needed: prefetch file found and empty"}' | safeoutputs noop .

The Copilot harness is invoked with this allow-list (from auto-triage-issues.lock.yml):

--allow-tool 'shell(cat *)' --allow-tool 'shell(cat)' --allow-tool 'shell(date)' \
--allow-tool 'shell(echo)' --allow-tool 'shell(gh:*)' --allow-tool 'shell(grep)' \
--allow-tool 'shell(head)' --allow-tool 'shell(jq *)' --allow-tool 'shell(ls)' \
--allow-tool 'shell(pwd)' --allow-tool 'shell(safeoutputs:*)' --allow-tool 'shell(sort)' \
--allow-tool 'shell(tail)' --allow-tool 'shell(uniq)' --allow-tool 'shell(wc)' \
--allow-tool 'shell(yq)'

shell(safeoutputs:*) permits the safeoutputs CLI on its own, but printf is not in the allow-list, so the pipe-and-redirect form is rejected before the pipeline reaches safeoutputs. From the agent stdio log of run §25608959573:

✗ Call safeoutputs noop to signal no action needed (shell)
  │ printf '{"message":"No action needed: prefetch file found and empty;
  │ no unlabeled issues to process"}' | safeoutputs noop .
  └ Permission denied and could not request permission from user

safeoutputs --help succeeds in the same run (shell(safeoutputs:*) matches), so the wiring works — only the printf prefix breaks the call.

The workflow exits with conclusion: success because the harness exit code is 0, but agent_output.json is {"items":[]} and the framework's safe-output detector posts the No Safe Outputs Generated failure issue.

Why this differs from #31178

#31178 tracks the same root cause (Bash permission denials) but for Claude workflows, where the symptom is error_max_turns because Claude retries denied commands until turns are exhausted. Copilot's harness fails fast, so the symptom here is the silent empty-manifest path instead of max-turns.

Affected workflows / runs analyzed

Proposed remediation (pick one)

  1. Add printf to the workflow's bash allow-list — smallest change. Edit .github/workflows/auto-triage-issues.md:

    tools:
      bash:
        - "jq *"
        - "cat *"
        - "printf *"

    Recompile via the compile MCP tool to regenerate auto-triage-issues.lock.yml.

  2. Update the framework prompt's mcp-clis JSON-payload guidance to use a CLI form that doesn't require printf — e.g. recommend safeoutputs noop --message "..." (the tool already accepts --message as a typed flag) or a safeoutputs noop . < /tmp/payload.json pattern when the agent has already written a payload file via the Write tool. Lower-friction across all workflows but a global change.

  3. Add printf (and arguably echo-based redirection helpers) to the default Copilot allow-list at the harness level when safeoutputs is enabled, so any workflow that opts into safe-outputs automatically gets the dependency it needs.

Option 1 is the immediate unblock; option 2 or 3 is the longer-term fix to prevent recurrence in other Copilot/gpt-5-mini workflows that adopt the same prompt pattern.

Success criteria

  • A scheduled run of Auto-Triage Issues produces a non-empty agent_output.json (either an add_labels action or an explicit noop).
  • The framework no longer auto-comments on [aw] Auto-Triage Issues failed #31265 with No Safe Outputs Generated.
  • agent-stdio.log for the run no longer shows Permission denied and could not request permission from user for the safeoutputs noop invocation.

Confidence and unknowns

  • High confidence that printf denial is the proximate cause: confirmed in two runs, both showing the identical Permission denied line for the same printf '...' | safeoutputs noop . shape.
  • Lower confidence about whether option 2 or 3 is preferred — depends on how widely the JSON-payload pattern is documented vs. used by other workflows. The framework prompt under <mcp-clis> explicitly recommends printf '{...}' | server tool . as the preferred approach for multi-arg calls, so other workflows are likely affected as soon as they restrict bash similarly.

References

Generated by [aw] Failure Investigator (6h) · ● 22.3M ·

  • expires on May 17, 2026, 1:36 AM UTC

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions