You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix the read-tool permission scoping bug — it silently denies a workflow's agent read access to its own checked-out working directory, trips the tool-denial threshold, and kills the run.
Two independently-scheduled workflows failed today with the identical signature: the agent tried to read/grep inside /home/runner/work/gh-aw/gh-aw (its own checkout) and was denied by workflow tool permissions, hit the denial cap, and aborted.
audit-diff (baseline §30570103985 vs failed §30760639664): posture flipped write_capable → read_only, turns dropped 1 → 0, GitHub Core API consumption dropped 77% (252 → 59 points) — consistent with the agent barely starting before being denied. No firewall/domain anomalies were found, ruling out a network/egress cause.
audit on Linter Miner (§30759473080) shows the same class of degradation vs its own baseline: posturewrite_capable → read_only, turns3 → 0, 1 critical error, run failed with exit code 1 — same signature, different workflow, same time window.
Probable root cause
A regression in the tool-permission compiler/scoping layer (Copilot CLI driver / sdk-driver) is scoping the read permission too narrowly, excluding the workflow's own checkout directory (/home/runner/work/gh-aw/gh-aw) — the one path every workflow must be able to read. This is not workflow-specific: it hit two unrelated scheduled workflows within a ~30-minute window, and the same fallback ("stop after 3 denials") is what kills the session. This tracks the drop from write_capable to read_only posture seen in the audit-diff, and looks distinct from the existing Design Decision Gate permission issue in #49096 (that one is about shell-expanded file paths, not the base checkout root).
Proposed remediation
Always allowlist the workflow's own checkout root (GITHUB_WORKSPACE) for read in the tool-permission compiler, regardless of any narrower read() scoping computed elsewhere.
Add a regression test that spins up a read-only workflow and asserts a read($GITHUB_WORKSPACE) call is never denied.
Until fixed, treat denialCount>=3 with reason matching read($GITHUB_WORKSPACE) as a missing_tool/config bug class (not a retryable permission issue) so the harness surfaces it immediately instead of burning the full attempt duration (this run spent 19m30s before giving up).
Success criteria / verification
Re-running Daily Testify Uber Super Expert and Linter Miner completes without a permission denied by workflow tool permissions: read($GITHUB_WORKSPACE) denial.
Problem statement
Fix the read-tool permission scoping bug — it silently denies a workflow's agent read access to its own checked-out working directory, trips the tool-denial threshold, and kills the run.
Two independently-scheduled workflows failed today with the identical signature: the agent tried to
read/grepinside/home/runner/work/gh-aw/gh-aw(its own checkout) and was denied by workflow tool permissions, hit the denial cap, and aborted.Affected workflows and run IDs
Evidence
Raw log + audit-diff evidence
Daily Testify Uber Super Expert (§30760639664) log tail:
audit-diff(baseline §30570103985 vs failed §30760639664):postureflippedwrite_capable → read_only,turnsdropped1 → 0, GitHub Core API consumption dropped 77% (252 → 59 points) — consistent with the agent barely starting before being denied. No firewall/domain anomalies were found, ruling out a network/egress cause.auditon Linter Miner (§30759473080) shows the same class of degradation vs its own baseline:posturewrite_capable → read_only,turns3 → 0, 1 critical error, run failed with exit code 1 — same signature, different workflow, same time window.Probable root cause
A regression in the tool-permission compiler/scoping layer (Copilot CLI driver / sdk-driver) is scoping the
readpermission too narrowly, excluding the workflow's own checkout directory (/home/runner/work/gh-aw/gh-aw) — the one path every workflow must be able to read. This is not workflow-specific: it hit two unrelated scheduled workflows within a ~30-minute window, and the same fallback ("stop after 3 denials") is what kills the session. This tracks the drop fromwrite_capabletoread_onlyposture seen in the audit-diff, and looks distinct from the existing Design Decision Gate permission issue in #49096 (that one is about shell-expanded file paths, not the base checkout root).Proposed remediation
GITHUB_WORKSPACE) forreadin the tool-permission compiler, regardless of any narrowerread()scoping computed elsewhere.read($GITHUB_WORKSPACE)call is never denied.denialCount>=3withreasonmatchingread($GITHUB_WORKSPACE)as amissing_tool/config bug class (not a retryable permission issue) so the harness surfaces it immediately instead of burning the full attempt duration (this run spent 19m30s before giving up).Success criteria / verification
permission denied by workflow tool permissions: read($GITHUB_WORKSPACE)denial.guard.tool_denials_exceededreferencing the workspace root across scheduled workflow runs for 7 days post-fix.Related to [aw-failures] [aw] Failure Investigator Report — 2026-08-02 (6h) #49835