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 Crush CLI sandbox PATH gap in Daily Code Metrics — deterministic ENOENT on Execute Crush CLI, now 2 of the last 2 daily runs (2026-08-12, 2026-08-13), and it has zero existing tracking. New sub-issue filed below.
Take no action on Smoke Gemini — single 503 RetryableQuotaError after 10 built-in retry attempts (§31732491740); transient upstream Gemini outage, isolated occurrence, no code defect.
Failing run's own log: [crush-harness] spawnSync crush ENOENT, immediately after the harness logs `awf-reflect: provider=github mapped to endpoint provider=copilot baseUrl=(apiproxy/redacted) and the proxy sidecar reports all 4 listeners (openai/anthropic/copilot/gemini) started and passed key validation.
audit-diff against the last successful run (§31419941312, 2026-08-10) shows the failed run did reach api.githubcopilot.com and api.openai.com through the proxy (2 and 3 allowed calls) — so the sandbox network path is healthy. The failure is specifically the harness's spawnSync('crush', ...) call not finding the binary at execution time.
Conclusion: the binary is installed and verified on the runner host, but the sandboxed/chroot exec environment used by the Execute Crush CLI step does not have it on PATH (or doesn't have the install location bind-mounted). This is a harness/sandbox integration bug, not a network or install-script bug.
Log-capture truncation — pattern confirmed 3x more today (click to expand)
All 3 runs show truncated_error_logs[].tail_lines containing only post-failure git/cleanup/OTLP-teardown output (e.g. Post job cleanup., Cleaning up /tmp/gh-aw..., git config --local --unset-all) — never the actual ##[error] line from the failing step (Execute Claude Code CLI / Execute GitHub Copilot CLI). This is the exact defect #52501 already describes and proposes a fix for (anchor capture to the failing step's log offset, not the job's absolute tail). No new issue needed — this just adds 3 more confirming runs to that existing report.
Existing issue correlation
Cluster
Match
Action taken
Log-capture truncation
#52501 (high confidence — identical signature and remediation already proposed)
Left open, no duplicate filed; new run IDs noted above
Crush CLI ENOENT
No match across 22 open agentic-workflows issues
New sub-issue filed (P0)
Gemini 503
No match, and not warranted — single transient occurrence with exhausted retries
No issue filed
No open issues were found to be fixed or stale based on this window's evidence; none were closed.
Fix roadmap
P0: Fix the Crush CLI sandbox PATH/mount gap — see sub-issue below. Blocks Daily Code Metrics 2 days running.
P1: None new this window.
P2: Monitor Gemini API 503 rate — no fix needed unless it recurs across multiple runs.
Executive summary
ENOENTonExecute Crush CLI, now 2 of the last 2 daily runs (2026-08-12, 2026-08-13), and it has zero existing tracking. New sub-issue filed below.503 RetryableQuotaErrorafter 10 built-in retry attempts (§31732491740); transient upstream Gemini outage, isolated occurrence, no code defect.Failure cluster table
ENOENTin sandboxed exec503service-unavailable after 10 retriesEvidence
Crush CLI ENOENT — install/verify succeed, execution fails (click to expand)
agentic-workflows auditon both failing runs confirms the same signature and step position:Install Crush→ success,Verify Crush CLI installation→ success,Execute Crush CLI→ failure.[crush-harness] spawnSync crush ENOENT, immediately after the harness logs `awf-reflect: provider=github mapped to endpoint provider=copilot baseUrl=(apiproxy/redacted) and the proxy sidecar reports all 4 listeners (openai/anthropic/copilot/gemini) started and passed key validation.audit-diffagainst the last successful run (§31419941312, 2026-08-10) shows the failed run did reachapi.githubcopilot.comandapi.openai.comthrough the proxy (2 and 3 allowed calls) — so the sandbox network path is healthy. The failure is specifically the harness'sspawnSync('crush', ...)call not finding the binary at execution time.Execute Crush CLIstep does not have it onPATH(or doesn't have the install location bind-mounted). This is a harness/sandbox integration bug, not a network or install-script bug.Log-capture truncation — pattern confirmed 3x more today (click to expand)
All 3 runs show
truncated_error_logs[].tail_linescontaining only post-failure git/cleanup/OTLP-teardown output (e.g.Post job cleanup.,Cleaning up /tmp/gh-aw...,git config --local --unset-all) — never the actual##[error]line from the failing step (Execute Claude Code CLI/Execute GitHub Copilot CLI). This is the exact defect #52501 already describes and proposes a fix for (anchor capture to the failing step's log offset, not the job's absolute tail). No new issue needed — this just adds 3 more confirming runs to that existing report.Existing issue correlation
ENOENTagentic-workflowsissues503No open issues were found to be fixed or stale based on this window's evidence; none were closed.
Fix roadmap
503rate — no fix needed unless it recurs across multiple runs.Sub-issues created
ENOENT) despite passing host-level install/verify — see linked sub-issue.References