Fix it: bind the installed crush binary into the sandboxed exec environment
Install Crush and Verify Crush CLI installation pass on the runner host, but the sandboxed/chroot process that actually runs the agent can't find crush on PATH — a pure environment-wiring gap, not a broken install script.
Affected workflows and runs
| Run |
Date |
Workflow |
Failing step |
| §31731856180 |
2026-08-13 |
Daily Code Metrics and Trend Tracking Agent |
Execute Crush CLI |
| §31628722200 |
2026-08-12 |
Daily Code Metrics and Trend Tracking Agent |
Execute Crush CLI |
Comparator (last success): §31419941312 (2026-08-10).
2 of the last 2 runs of this workflow have failed with the identical signature — this is now a 100%-reproducible daily failure, not a flake.
Probable root cause
Job step order for both failing runs: Install Crush → success → Verify Crush CLI installation → success → ... → Execute Crush CLI → failure with:
[crush-harness] awf-reflect: provider=github mapped to endpoint provider=copilot baseUrl=(apiproxy/redacted)
[crush-harness] spawnSync crush ENOENT
[WARN] Sandbox command exited with code 1
The install and verify steps run in the normal runner shell (where crush resolves fine). Execute Crush CLI runs inside the chroot/sandboxed exec environment (same isolation used by the Claude/Copilot/Gemini engine harnesses — see [entrypoint] Chroot mode enabled - dropping CAP_SYS_CHROOT and CAP_SYS_ADMIN / Switching to awfuser in sibling engine logs). The crush binary's install path is evidently not on PATH inside that chroot, or not bind-mounted into it, so spawnSync('crush', ...) fails with ENOENT even though the binary exists and was verified moments earlier at the host level. Network/proxy path is confirmed healthy independently — audit-diff against the last successful run shows the failed run reaching api.githubcopilot.com and api.openai.com through the sidecar proxy without issue, so this is isolated to the exec-time binary resolution, not connectivity.
Proposed remediation
- Identify where
Install Crush places the binary (e.g. $RUNNER_TOOL_CACHE/.../bin or similar) and confirm whether that path is included in the chroot's bind-mounts / the sandboxed PATH construction used by the crush harness entrypoint (compare against how Claude/Copilot/Gemini engine binaries are made available inside the same sandbox — those succeed).
- If the crush harness builds its own sandboxed
PATH (distinct from the other engine harnesses), add the crush install directory to it, or bind-mount the resolved binary path explicitly before spawnSync.
- Add a preflight check inside the sandbox (not just on the host) that resolves
crush on PATH before invoking it, and fails fast with a clear "crush not found in sandbox PATH: (path)" message instead of a bare ENOENT.
Success criteria / verification
- Next scheduled run of Daily Code Metrics and Trend Tracking Agent completes
Execute Crush CLI successfully.
- A local reproduction (or CI dry run) of the crush harness inside the sandbox resolves
crush on PATH without the ENOENT.
Parent report: #52570
Related to #52570
Generated by 🔍 [aw] Failure Investigator (6h) · agent · 112.9 AIC · ⌖ 38.3 AIC · ⊞ 5.3K · ◷
Fix it: bind the installed
crushbinary into the sandboxed exec environmentInstall CrushandVerify Crush CLI installationpass on the runner host, but the sandboxed/chroot process that actually runs the agent can't findcrushonPATH— a pure environment-wiring gap, not a broken install script.Affected workflows and runs
Execute Crush CLIExecute Crush CLIComparator (last success): §31419941312 (2026-08-10).
2 of the last 2 runs of this workflow have failed with the identical signature — this is now a 100%-reproducible daily failure, not a flake.
Probable root cause
Job step order for both failing runs:
Install Crush→ success →Verify Crush CLI installation→ success → ... →Execute Crush CLI→ failure with:The install and verify steps run in the normal runner shell (where
crushresolves fine).Execute Crush CLIruns inside the chroot/sandboxed exec environment (same isolation used by the Claude/Copilot/Gemini engine harnesses — see[entrypoint] Chroot mode enabled - dropping CAP_SYS_CHROOT and CAP_SYS_ADMIN/Switching to awfuserin sibling engine logs). Thecrushbinary's install path is evidently not onPATHinside that chroot, or not bind-mounted into it, sospawnSync('crush', ...)fails withENOENTeven though the binary exists and was verified moments earlier at the host level. Network/proxy path is confirmed healthy independently —audit-diffagainst the last successful run shows the failed run reachingapi.githubcopilot.comandapi.openai.comthrough the sidecar proxy without issue, so this is isolated to the exec-time binary resolution, not connectivity.Proposed remediation
Install Crushplaces the binary (e.g.$RUNNER_TOOL_CACHE/.../binor similar) and confirm whether that path is included in the chroot's bind-mounts / the sandboxedPATHconstruction used by the crush harness entrypoint (compare against how Claude/Copilot/Gemini engine binaries are made available inside the same sandbox — those succeed).PATH(distinct from the other engine harnesses), add the crush install directory to it, or bind-mount the resolved binary path explicitly beforespawnSync.crushonPATHbefore invoking it, and fails fast with a clear "crush not found in sandbox PATH: (path)" message instead of a bareENOENT.Success criteria / verification
Execute Crush CLIsuccessfully.crushonPATHwithout the ENOENT.Parent report: #52570
Related to #52570