[aw-failures] Daily Issues Report Generator — 100% failure (5+ days): copilot CLI exits in ~30s with zero token usage, unclassif [Content truncated due to length] #36325

Problem statement

Daily Issues Report Generator (.github/workflows/daily-issues-report.lock.yml, copilot engine) has failed 5 consecutive scheduled runs (100% failure) from 2026-05-28 through 2026-06-01. Every failure is in the agent job at the Execute GitHub Copilot CLI step. This is a 4th fully-blocked (0% success) agent not covered by #36279 (which tracks AI Moderator, Q, and Deployment Incident Monitor).

Affected workflow and run IDs

Probable root cause

The copilot CLI starts, MCP servers register (safeoutputs: 6 tools), and the GitHub DIFC guard runs — then the process exits non-zero without performing any model inference. Evidence from run 26767564843:

1. No token usage data found, skipping summary — zero tokens consumed; the agent never reached an inference turn.
2. MCP gateway issued Shutdown signal received, initiating graceful shutdown +30.7s — the session lasted only ~30s.
3. All gh-aw failure classifiers returned false: Effective tokens rate-limit error: false, Agentic engine timeout: false, Inference access error: false, MCP policy error: false, Model not supported error: false; Detection reason: empty.

This is therefore an unclassified early copilot-CLI exit — distinct from the effective-tokens exhaustion in #35661 (no tokens are spent here) and from a timeout (it exits in ~30s, well under the 30-min GH_AW_TIMEOUT_MINUTES). The signature is identical across all 5 runs (audit-diff of 26767564843 vs 26646767762 shows no drift), indicating a stable, systemic block specific to this workflow rather than a transient outage. The pre-agent fetch issues data step is not the cause — it logs a handled warning but successfully saves issues-2026-06-01.json before the agent runs.

Note: because the per-run failure reporter hit its daily cap (Daily per-category issue cap reached for agent_failure (5/5)), these failures produced no auto-tracking issue, which is why they went uncovered.

Effective tokens: (none)
Configured max effective tokens: 25000000
Effective tokens rate-limit error: false
Agentic engine timeout: false
Inference access error: false
MCP policy error: false
Model not supported error: false
Agent conclusion: failure

server:handlers Initiating gateway shutdown +30.7s
cmd:root Shutdown signal received, initiating graceful shutdown +30.7s
No token usage data found, skipping summary

Proposed remediation

1. Retrieve the raw copilot CLI stderr/exit code for run 26767564843 (the GH Actions step log truncates it; check the aw_info.json / agent artifact for the non-zero exit and any auth/premium-access message). The ~30s zero-token exit most likely indicates a copilot CLI startup/auth/config rejection specific to this workflow.
2. Compare this workflow's compiled prompt/config against a healthy copilot workflow that runs in the same schedule window (e.g. CLI Consistency Checker on its successful days) to isolate the workflow-specific trigger.
3. As an interim measure consistent with [deep-report] [quick-win] Triage 3 fully-blocked (0% success) agents wasting scheduled runs #36279, disable this schedule until fixed so it stops consuming scheduled runs with zero output.
4. Framework gap: add a classifier for zero-token early CLI exit so this failure mode is labeled (today it falls through all five detectors with an empty Detection reason), and raise/segment the agent_failure daily issue cap so genuinely-new fully-blocked agents are not silently swallowed once the cap is reached.

Success criteria / verification

• Daily Issues Report Generator produces a successful run (>0% success, non-zero token usage and a posted discussion), or its schedule is disabled with the root cause documented here.
• A gh-aw run that exits with zero tokens before any inference turn is classified with a non-empty Detection reason (verify on a re-run or unit test of the classifier).

Parent: #36279. Related: #35661 (effective-tokens exhaustion — a different mechanism; this one spends no tokens).

Generated by 🔍 [aw] Failure Investigator (6h) · opus48 2M · ◷

• expires on Jun 8, 2026, 8:25 PM UTC

2026-06-02 — second workflow hit by the same zero-token early-CLI-exit class

Broaden this issue and ship the zero-token early CLI exit classifier (remediation #4) — the failure mode is no longer Daily-Issues-Report-only; Daily News just hit it with a precise exit code 127 (command-not-found) signature.

The copilot CLI step exits 127 (command not found) with zero turns and zero token usage — the engine never ran inference. This sharpens the root-cause hypothesis in this issue: the ~30s zero-token exits are most likely the copilot binary / a command on the invocation PATH not resolving, not an auth/premium rejection.

[entrypoint] Executing command: /bin/bash -c ... export PATH="${RUNNER_TEMP}/gh-aw/mcp-cli/bin:$PATH" && GH_AW_TOOL_CACHE=...
[WARN] Command completed with exit code: 127
Process exiting with code: 127

Action: (1) capture the copilot CLI invocation that returns 127 and confirm which binary is missing on PATH; (2) implement the zero-token early CLI exit detector from remediation #4 — both this run and the Daily-Issues-Report runs currently fall through all detectors with an empty Detection reason. Re-investigation parent run: §26825214886.

Generated by 🔍 [aw] Failure Investigator (6h) · opus48 2M · ◷