Skip to content

[aw-failures] GitHub Copilot CLI generic exit-1 crash across 7 workflows #55488

Description

@github-actions

Fix the crash first, then add exit-1 diagnostics — the Copilot CLI engine is exiting mid-run with zero error detail, and it's already spread to 7 unrelated workflows in one 5-hour window.

Problem statement

The native GitHub Copilot CLI engine (engine: copilot, distinct from the Codex/Claude "Copilot-brokered credential" bug tracked in #55412/#55413) is crashing mid-run with a bare ##[error]Agent execution exited with code 1 and no further diagnostic. Firewall logs are clean (no blocked requests, no auth-proxy involvement), and the crash happens after real tool activity — this is not a startup/auth failure, it's a genuine in-flight crash.

Affected workflows and run IDs

Probable root cause

Unknown and currently unlogged, same shape as the previously-seen "generic exit 1, no captured stdout/stderr reason" pattern noted in #54242 for Codex — except this is the Copilot CLI engine, a different binary/wrapper. The clean firewall trace and mid-run tool activity rule out auth/proxy and network causes. Two live hypotheses: (1) the Copilot CLI binary itself is crashing/OOMing on larger tool-call sequences, or (2) the harness's exit-code capture for this engine is swallowing the real stderr before it reaches the step summary — worth checking whether the wrapper script for engine: copilot captures stderr on non-zero exit the same way the Codex/Claude wrappers do.

Proposed remediation

  1. Add stderr/exit-reason capture to the Copilot CLI engine wrapper so future crashes surface something more specific than "exited with code 1" (compare to how [aw-failures] [P0] Cross-engine agent-CLI segfault (exit 139) — confirmed on Auto-Triage/Pi CLI, now spread to 8 workflows acros #54186 escalated once exit code 139 was confirmed instead of "generic exit code 1").
  2. Re-run one of the affected workflows (e.g. Linter Miner) with verbose/debug logging enabled for the Copilot CLI step to capture the actual crash reason.
  3. Check for a resource ceiling (memory/timeout) being hit after ~20+ tool calls, since Linter Miner's crash occurred right after a burst of bash/task activity.

Success criteria / verification

  • Next occurrence of this crash produces a specific error message (not bare exit code 1) in the step log.
  • Re-run of at least one previously-failing workflow (Linter Miner or Code Scanning Fixer) completes successfully under the same trigger conditions.
  • No recurrence across the 7 affected workflows over the following 24h monitoring window.

Generated by 🔍 [aw] Failure Investigator (6h) · claude · agent · 161.3 AIC · ⌖ 8.19 AIC · ⊞ 6.4K · ◷

  • expires on Aug 31, 2026, 11:15 AM UTC-08:00

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions