Problem
Stop letting a single denied sed read burn the whole invocation budget — cap identical-intent permission denials the same way #49096 already asked for jq -Rs, but this time it's shell(sed ...) on an agent-owned scratch file. Discussion Task Miner's attempt 1 hit permission denied by workflow tool permissions: shell(sed -n '205,260p' /tmp/gh-aw/agent/50544.md), retried the identical command pattern, and tripped guard.tool_denials_exceeded (3/3) — max tool denials threshold reached (3/3); stopping SDK session early, then exhausted the run's invocation cap entirely.
Affected Workflows and Run IDs
- Discussion Task Miner - Code Quality Improvement Agent (scheduled workflow,
.github/workflows/discussion-task-miner.md) — §31009371114 (2026-08-05 13:15 UTC)
Probable Root Cause
This is the same class of bug as #49096 (permission-denied retries exhausting the LLM invocation cap) but on a different surface: reading the agent's own scratch/context file (/tmp/gh-aw/agent/50544.md) via sed -n is blocked by workflow tool permissions, and the harness has no short-circuit for "same file, same denial, N attempts" — it keeps retrying until the 3-denial guard fires, then the whole session dies instead of degrading gracefully (e.g. falling back to a cat/Read-equivalent allowed tool, or reporting missing_tool).
Specific Proposed Remediation
- Allow read-only access (
sed -n, cat, head) to files the workflow itself wrote under /tmp/gh-aw/agent/** — these are the agent's own generated context, not untrusted external content, so denying reads of them serves no security purpose.
- When
guard.tool_denials_exceeded fires, exit with a clear missing_tool/report_incomplete signal rather than continuing to burn invocation budget on the same command shape.
- Since this is a scheduled workflow, confirm the fix by re-running Discussion Task Miner on its next scheduled trigger and checking it completes without a permission-denial cascade.
Success Criteria / Verification
Generated by 🔍 [aw] Failure Investigator (6h) · agent · 148.2 AIC · ⌖ 49.3 AIC · ⊞ 5.2K · ◷
Problem
Stop letting a single denied
sedread burn the whole invocation budget — cap identical-intent permission denials the same way #49096 already asked forjq -Rs, but this time it'sshell(sed ...)on an agent-owned scratch file. Discussion Task Miner's attempt 1 hitpermission denied by workflow tool permissions: shell(sed -n '205,260p' /tmp/gh-aw/agent/50544.md), retried the identical command pattern, and trippedguard.tool_denials_exceeded(3/3) —max tool denials threshold reached (3/3); stopping SDK session early, then exhausted the run's invocation cap entirely.Affected Workflows and Run IDs
.github/workflows/discussion-task-miner.md) — §31009371114 (2026-08-05 13:15 UTC)Probable Root Cause
This is the same class of bug as #49096 (permission-denied retries exhausting the LLM invocation cap) but on a different surface: reading the agent's own scratch/context file (
/tmp/gh-aw/agent/50544.md) viased -nis blocked by workflow tool permissions, and the harness has no short-circuit for "same file, same denial, N attempts" — it keeps retrying until the 3-denial guard fires, then the whole session dies instead of degrading gracefully (e.g. falling back to acat/Read-equivalent allowed tool, or reportingmissing_tool).Specific Proposed Remediation
sed -n,cat,head) to files the workflow itself wrote under/tmp/gh-aw/agent/**— these are the agent's own generated context, not untrusted external content, so denying reads of them serves no security purpose.guard.tool_denials_exceededfires, exit with a clearmissing_tool/report_incompletesignal rather than continuing to burn invocation budget on the same command shape.Success Criteria / Verification
guard.tool_denials_exceededorinvocation_cap_exceeded.sed -n/read-only shell access to/tmp/gh-aw/agent/**scratch files is no longer denied by workflow tool permissions.Related to [aw-failures] [aw] Failure Investigator Report — 2026-08-05 (6h) #50518