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.
[aw-failures] [P1] PR Sous Chef: Start DIFC Proxy step fails with no captured root cause #52502 (PR Sous Chef DIFC Proxy): NOT the same failure as this window's PR Sous Chef run — that one failed at a different step (Process Safe Outputs, not Start DIFC Proxy) with a fully-visible root cause (cross-repo resolve_pull_request_review_thread rejected for scrapy/scrapy, not in the allowed-repos list). Isolated/low severity, treated as expected security-boundary behavior rather than a bug — no sub-issue filed, flagging here for visibility only.
audit-diff on the Go Logger Enhancement failure vs its last success (§31768069259) shows 0 firewall/network anomalies and 18 vs 693 GitHub API rate-limit core points consumed — confirms the failure is a task/tooling stall, not an infra or connectivity regression.
New sub-issues filed under this report: see linked sub-issues list on this issue.
Crush DNS regression (new):agent-stdio.log shows the reflect probe resolving baseUrl=(host.docker.internal/redacted) correctly, then the actual chat-completions POST failing with dial tcp: lookup api-proxy on 172.17.0.0:53: no such host. The same workflow failed the prior 4 consecutive days (08-11 → 08-14) with a *different* signature, spawnSync crush ENOENT(tracked as #52571, closed by PR #52576 merged 2026-08-15T05:21:29Z). This run is the first scheduled run after that merge — the failure mode changed in the same code path, indicating PR #52576 traded one bug for another rather than fully fixing the Crush/api-proxy path.audit-diff` vs the last success (08-10, §31372099754) shows no firewall/domain blocks, ruling out a policy rejection.
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
Update — 2026-08-15 06:00-07:00 UTC investigation (6h)
Fix the two new P1s below first — they're isolated so far but both have zero graceful-degradation, meaning the very next occurrence looks identical.
Failure cluster table
Evidence and existing-issue correlation
--continue disabled permanentlyharness bug on attempt 2 (failure_reason=harness_retry_path_invalid) — same secondary bug documented in [aw-failures] [P0] Bun runtime segfault crashing Claude Code CLI — now hitting 2 workflows #51984.Process Safe Outputs, notStart DIFC Proxy) with a fully-visible root cause (cross-reporesolve_pull_request_review_threadrejected forscrapy/scrapy, not in the allowed-repos list). Isolated/low severity, treated as expected security-boundary behavior rather than a bug — no sub-issue filed, flagging here for visibility only.audit-diffon the Go Logger Enhancement failure vs its last success (§31768069259) shows 0 firewall/network anomalies and 18 vs 693 GitHub API rate-limit core points consumed — confirms the failure is a task/tooling stall, not an infra or connectivity regression.New sub-issues filed under this report: see linked sub-issues list on this issue.
Fix roadmap
--continueharness bug together since they compound; fix the Crush cache-miss 401 and the Go Logger timeout-loop guard (new sub-issues).References:
Update — 2026-08-15 11:00-13:00 UTC investigation (6h)
Fix the new Crush harness DNS regression first — it's a fresh P0 with zero graceful degradation, and it landed the same morning as the fix for #52571.
Failure cluster table
api-proxyhostname for chat completionsauthentication_failed)Evidence and existing-issue correlation
agent-stdio.logshows the reflect probe resolvingbaseUrl=(host.docker.internal/redacted) correctly, then the actual chat-completions POST failing withdial tcp: lookup api-proxy on 172.17.0.0:53: no such host. The same workflow failed the prior 4 consecutive days (08-11 → 08-14) with a *different* signature,spawnSync crush ENOENT(tracked as #52571, closed by PR #52576 merged 2026-08-15T05:21:29Z). This run is the first scheduled run after that merge — the failure mode changed in the same code path, indicating PR #52576 traded one bug for another rather than fully fixing the Crush/api-proxy path.audit-diff` vs the last success (08-10, §31372099754) shows no firewall/domain blocks, ruling out a policy rejection.authentication_failedHTTP 403 on the very first request, still never reaching the credit-limit guardrail this test exists to validate.truncated_error_logs(no captured##[error]line) — this is another instance of the log-capture-truncation defect tracked in [aw-failures] [P0] Failure-Investigator log capture grabs post-job cleanup tail, not the actual error #52501, still unfixed, still forcing directagent-stdio.log/auditpulls to get real evidence.New sub-issues filed under this report: see linked sub-issues list on this issue.
Fix roadmap
References: