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
Two workflow runs failed in the 2026-05-10 ~01:35–07:36 UTC (6h) window; both already have auto-generated tracking issues. Each is a recurrence of an open parent failure cluster — no new P0 emerges, but the Go Logger Enhancement run revealed a new, actionable Go toolchain mismatch (go.mod requires Go 1.25.8, runner has 1.24.13 with GOTOOLCHAIN=local) that is worth tracking on top of the existing #31178 max-turns cluster.
##[error]ERR_CONFIG: Lock file '.github/workflows/schema-consistency-checker.lock.yml' is outdated! The workflow file '.github/workflows/schema-consistency-checker.md' frontmatter has changed. Run 'gh aw compile' to regenerate the lock file.
audit-diff vs the most recent successful baseline (§25593663016, 2026-05-09 06:05 UTC):
0 new domains, 0 status changes; the only delta is removal of api.anthropic.com:443 traffic (because the agent never started).
No firewall, MCP, or quota anomalies — purely a stale-lock failure that prevented the agent from booting.
This is a recurrence of the #31221 "agentic workflows out of sync" pattern. The auto-generated #31307 already provides the exact remediation (gh aw compile).
activation succeeded (15s); agent ran 16.8m and was terminated as failure (no result event emitted before kill).
247 turns across 56 tool types with tool_breadth=broad and resource_profile=heavy.
0 firewall blocks (143 requests, all allowed).
mcp_server_health clean (1 server mcpscripts, 6 calls, 0 errors).
11 anomalous event patterns flagged by template clustering.
Burned-turn pattern from agent-stdio.log (matches #31178):
This Bash command contains multiple operations. The following parts require approval: ls -la /tmp/gh-aw/cache-memory/go-logger/, cat /tmp/gh-aw/cache-memory/go-logger/processed-files.json, ...
ls in '/tmp/gh-aw/cache-memory' was blocked. For security, Claude Code may only list files in the allowed working directories: '/home/runner/work/gh-aw/gh-aw'.
mkdir in '/tmp/gh-aw/cache-memory/go-logger' was blocked.
Output redirection to '/tmp/gh-aw/agent/all_go.txt' was blocked.
find with '-exec' executes commands or modifies files — cannot be auto-allowed by a Bash(find:*) prefix rule
This Bash command contains multiple operations. The following part requires approval: go version
New finding — Go toolchain mismatch (not present in #31178):
go: go.mod requires go >= 1.25.8 (running go 1.24.13; GOTOOLCHAIN=local)
make: *** [Makefile:23: build] Error 1
The runner has Go 1.24.13 and GOTOOLCHAIN=local is set, suppressing the auto-upgrade path that go.mod's 1.25.8 directive would normally trigger. The agent eventually pivoted to the mcpscripts go MCP tool (which has the correct toolchain), but by then most of its time/turn budget was gone — and mcpscripts then hit a hard 60s subprocess timeout for go test ./pkg/workflow/:
Error [-32603]: calling "tools/call": Command failed: /home/runner/work/_temp/gh-aw/mcp-scripts/go.sh (signal: SIGTERM)
stdout:
go test ./pkg/workflow/ -count=1 -timeout 300s
The agent passed -timeout 300s to go test, but the mcpscripts go wrapper enforces a 60s wall-clock kill, so the test was always going to be SIGTERM'd. The wallclock job limit hit before recovery.
None. Both clusters have existing trackers and neither caused a service-wide outage.
P1 (this 6h window introduces new evidence)
Add Go toolchain handling to [aw-failures] Claude workflows hit max-turns burning every turn on Bash permission denials (Step Name Alignment, Design Decision Gate) #31178 follow-up. Either (a) bump runner Go to ≥ 1.25.8 in the Go Logger Enhancement workflow runtimes.go block, or (b) drop GOTOOLCHAIN=local so go.mod triggers an auto-download. Without this fix, every Go-touching agent workflow will keep failing on make build until the agent finds the mcpscripts go wrapper. (success criteria: a fresh Go Logger Enhancement run completes make build on the host without falling back to mcpscripts)
Raise the mcpscripts go.sh subprocess timeout above 60s for go test invocations, or document the cap in the workflow prompt so the agent doesn't pass -timeout 300s it can never use. (success criteria: a go test ./pkg/workflow/ -timeout 300s invocation via mcpscripts completes without SIGTERM)
Executive summary
Two workflow runs failed in the 2026-05-10 ~01:35–07:36 UTC (6h) window; both already have auto-generated tracking issues. Each is a recurrence of an open parent failure cluster — no new P0 emerges, but the Go Logger Enhancement run revealed a new, actionable Go toolchain mismatch (
go.modrequires Go 1.25.8, runner has 1.24.13 withGOTOOLCHAIN=local) that is worth tracking on top of the existing #31178 max-turns cluster.Failure clusters
Evidence
Cluster 1 — Schema Consistency Checker (lock-file drift)
auditof run25621677191:activationjob failed in 13s;agentwas skipped.audit-diffvs the most recent successful baseline (§25593663016, 2026-05-09 06:05 UTC):api.anthropic.com:443traffic (because the agent never started).This is a recurrence of the #31221 "agentic workflows out of sync" pattern. The auto-generated #31307 already provides the exact remediation (
gh aw compile).Cluster 2 — Go Logger Enhancement (agent timeout, mixed root cause)
auditof run25619824735:activationsucceeded (15s);agentran 16.8m and was terminated as failure (noresultevent emitted before kill).tool_breadth=broadandresource_profile=heavy.mcp_server_healthclean (1 servermcpscripts, 6 calls, 0 errors).Burned-turn pattern from
agent-stdio.log(matches #31178):New finding — Go toolchain mismatch (not present in #31178):
The runner has Go 1.24.13 and
GOTOOLCHAIN=localis set, suppressing the auto-upgrade path thatgo.mod's 1.25.8 directive would normally trigger. The agent eventually pivoted to themcpscripts goMCP tool (which has the correct toolchain), but by then most of its time/turn budget was gone — andmcpscriptsthen hit a hard 60s subprocess timeout forgo test ./pkg/workflow/:The agent passed
-timeout 300stogo test, but themcpscripts gowrapper enforces a 60s wall-clock kill, so the test was always going to be SIGTERM'd. The wallclock job limit hit before recovery.Existing issue correlation
/tmp/gh-aw/cache-memory/*denial signatureprintfallow-list)successin the audit; this is a known false-positive classcache_memory_miss)success; missing-data on cache keyProposed fix roadmap
P0
None. Both clusters have existing trackers and neither caused a service-wide outage.
P1 (this 6h window introduces new evidence)
runtimes.goblock, or (b) dropGOTOOLCHAIN=localsogo.modtriggers an auto-download. Without this fix, every Go-touching agent workflow will keep failing onmake builduntil the agent finds themcpscripts gowrapper. (success criteria: a fresh Go Logger Enhancement run completesmake buildon the host without falling back to mcpscripts)mcpscripts go.shsubprocess timeout above 60s forgo testinvocations, or document the cap in the workflow prompt so the agent doesn't pass-timeout 300sit can never use. (success criteria: ago test ./pkg/workflow/ -timeout 300sinvocation via mcpscripts completes without SIGTERM)P2
/tmp/gh-aw/cache-memory/*and chained commands) — Go Logger Enhancement is now the 3rd workflow caught by this.Sub-issues linked
References
audit-diff)Related to [aw-failures] [aw] Failure Investigator (6h) - Issue Group #30961