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 Avenger Claude-CLI startup failure now — it's the only P0 gap with zero tracking coverage this cycle.
Executive summary
13 failed runs across 11 workflows in the last 6h (2026-08-25 13:11–18:32 UTC). One (Daily Credit Limit Test) is an intentionally-broken canary and is excluded below.
1 new P0 gap: Avenger — Claude Code CLI fails to start with ERR_CONFIG: ... no structured log entries were produced on 3 of its last 8 runs (~38% failure rate this window). No existing issue names Avenger. Filed as sub-issue #aw_avn1 below.
1 new P1 gap: Daily Fact — hard-blocked by KVM kernel module is not loaded on the docker-sbx runtime check. Single occurrence this window; not filed as a separate issue due to this cycle's issue budget — track it if it recurs.
No existing issue was closed: the only commit touching these workflow paths since 2026-08-20 (a4a5a5f, a repo-wide constants rename) is unrelated to any tracked failure signature, so all prior P0/P1 tracking issues stay open as-is.
Generic Copilot CLI exit 1. Dead Code Removal's ##[error] annotation is a false positive — it's the workflow's own deadcode-analysis output ("unreachable func: ..."), not the real crash cause
intentional-failure: true canary that tests max-daily-ai-credits: 1 enforcement — failing is the expected/correct outcome
Not a bug
Evidence
Avenger (cluster 1) — audit-diff between the representative failure (§32878935559) and the nearest successful run (§32884912368, 61 min later) shows zero firewall/domain drift and zero anomalies — ruling out an egress/network-policy regression as the cause. Recent run history shows the failure is intermittent (4 of the last 15 scheduled runs failed), alternating with clean successes, consistent with a race or transient resource contention in CLI startup rather than a permanent misconfiguration. Two of the three failed runs additionally logged: WARNING: Squid access.log not found under /tmp/gh-aw/sandbox/firewall/logs; the MCP gateway started but produced no auditable egress traffic — the firewall sidecar starts but never produces logs before the harness gives up.
Daily Fact (cluster 5) — the Check KVM availability for docker-sbx step fails outright with ##[error]KVM kernel module is not loaded, before the agent CLI ever starts. This is a runner-capability gap (nested virtualisation not enabled/available on the assigned runner), not an application bug.
No open issue was closed — the only commit touching any of these workflow files since 2026-08-20 (a4a5a5f) is an unrelated repo-wide constants rename with no targeted fix content.
Fix roadmap
P0 — Avenger startup failure: see sub-issue #aw_avn1.
P1 — Daily Fact KVM gap: runner pool serving docker-sbx/cloud-hypervisor sandboxes needs KVM/nested-virtualisation verified or gated before scheduling this workflow; file a tracked issue if it recurs next cycle.
P2 — Code Scanning Fixer / Dead Code Removal Agent: both need richer failure-log capture (current tails only show harness boilerplate or the agent's own tool output); no fix action until a real error signature is captured.
Sub-issues created
#aw_avn1 — Avenger: Claude Code CLI fails to start with ERR_CONFIG (no structured log entries)
Fix the Avenger Claude-CLI startup failure now — it's the only P0 gap with zero tracking coverage this cycle.
Executive summary
Daily Credit Limit Test) is an intentionally-broken canary and is excluded below.Avenger— Claude Code CLI fails to start withERR_CONFIG: ... no structured log entries were producedon 3 of its last 8 runs (~38% failure rate this window). No existing issue names Avenger. Filed as sub-issue #aw_avn1 below.Daily Fact— hard-blocked byKVM kernel module is not loadedon thedocker-sbxruntime check. Single occurrence this window; not filed as a separate issue due to this cycle's issue budget — track it if it recurs.a4a5a5f, a repo-wide constants rename) is unrelated to any tracked failure signature, so all prior P0/P1 tracking issues stay open as-is.Failure cluster table
ERR_CONFIG: Claude execution failed: no structured log entries were produced— Claude CLI startup/config failure before structured loggingexited with code 1, clean firewall, no distinguishing messagenode/gotoolchain missing →LanguageServerManagerInitialisationError##[error]KVM kernel module is not loaded. docker-sbx requires a KVM-capable runner with nested virtualisation enabled.##[error]annotation is a false positive — it's the workflow's own deadcode-analysis output ("unreachable func: ..."), not the real crash causeintentional-failure: truecanary that testsmax-daily-ai-credits: 1enforcement — failing is the expected/correct outcomeEvidence
Avenger (cluster 1) —
audit-diffbetween the representative failure (§32878935559) and the nearest successful run (§32884912368, 61 min later) shows zero firewall/domain drift and zero anomalies — ruling out an egress/network-policy regression as the cause. Recent run history shows the failure is intermittent (4 of the last 15 scheduled runs failed), alternating with clean successes, consistent with a race or transient resource contention in CLI startup rather than a permanent misconfiguration. Two of the three failed runs additionally logged:WARNING: Squid access.log not found under /tmp/gh-aw/sandbox/firewall/logs; the MCP gateway started but produced no auditable egress traffic— the firewall sidecar starts but never produces logs before the harness gives up.Daily Fact (cluster 5) — the
Check KVM availability for docker-sbxstep fails outright with##[error]KVM kernel module is not loaded, before the agent CLI ever starts. This is a runner-capability gap (nested virtualisation not enabled/available on the assigned runner), not an application bug.Existing issue correlation
LanguageServerManagerInitialisationErrortraceback. Left open.Execute Claude Code CLIstep; log tail didn't capture the distinguishing error text, so kept mapped to the existing pair rather than treated as a new gap. Left open.audit-diffshows no firewall/domain change, so this is not the same root cause. Kept separate as a new gap (cluster 1).engine: {id: copilot}path, notcopilot/*model brokering on Codex/Claude, so it does not match this pattern. No match found this window.a4a5a5f) is an unrelated repo-wide constants rename with no targeted fix content.Fix roadmap
docker-sbx/cloud-hypervisorsandboxes needs KVM/nested-virtualisation verified or gated before scheduling this workflow; file a tracked issue if it recurs next cycle.Sub-issues created
References: