Fix the Goose engine's job setup so the awf firewall binary is on PATH before "Execute Goose CLI" runs — right now the step fails immediately with awf: command not found (exit 127), before Goose ever starts.
Affected workflow / run
- Workflow: Smoke Goose (
.github/workflows/smoke-goose.lock.yml)
- Failed run: §30880381421, 2026-08-04T05:20:24Z, job 91900536237, step "Execute Goose CLI"
Probable root cause
Full job log (agenticworkflows audit, workflow-logs/4_agent.txt) shows the step's generated shell script directly invoking the firewall wrapper:
awf --config "${RUNNER_TEMP}/gh-aw/awf-config.json" --container-workdir "${GITHUB_WORKSPACE}" ... -- /bin/bash -c '... goose_harness.cjs goose'
which fails immediately with:
.../6f8a89b8-b238-4682-ae53-655d8b85afd3.sh: line 23: awf: command not found
##[error]Process completed with exit code 127.
The awf binary was never installed onto PATH for this job before the step ran — this looks like a step-ordering or PATH-export gap specific to the Goose engine's generated job (the CVE-scan, Claude Code, and Copilot CLI jobs analyzed in this same window did not hit a missing-binary error at this stage).
Proposed remediation
- Diff the Smoke Goose
.lock.yml job's steps against a working engine (e.g. Claude Code CLI) to confirm both get the same awf-install/PATH-setup step ahead of CLI execution.
- Ensure
awf is installed and placed on PATH before "Execute Goose CLI" runs — fix the PATH export order or missing install step in the workflow codegen for the goose engine specifically.
Success criteria
Generated by 🔍 [aw] Failure Investigator (6h) · agent · 191.6 AIC · ⌖ 37.4 AIC · ⊞ 5.5K · ◷
Update — 2026-08-04 (12:14 UTC recurrence)
The awf: command not found bug is gone — a new, different bug now blocks the same step. Don't close this yet.
Run §30908234685, job 91988815439, "Execute Goose CLI": awf now runs successfully (no more exit 127 / command-not-found), so whatever fixed PATH ordering landed. But the step still fails, now inside the Goose harness itself:
Error: ENOENT: no such file or directory, open '.goose/mcp.json'
at readFileSync (node:fs:441:20)
at Object.<anonymous> (/home/runner/work/_temp/gh-aw/actions/goose_harness.cjs:26:29)
...
[WARN] Command completed with exit code: 1
##[error]Process completed with exit code 1.
goose_harness.cjs:26 reads .goose/mcp.json as a relative path, which only resolves if the process cwd happens to be the directory containing that file. Given awf now wraps the container with --container-workdir "${GITHUB_WORKSPACE}", the harness's cwd is likely the workspace root rather than wherever .goose/mcp.json is actually written — a path-resolution gap introduced or exposed by the same fix that got awf onto PATH.
Proposed remediation: make goose_harness.cjs's .goose/mcp.json lookup absolute (resolve relative to the script's own directory, the container workdir, or wherever the config-generation step actually writes it) instead of relying on an implicit relative cwd.
Updated success criteria: Smoke Goose completes past "Execute Goose CLI" without either awf: command not found (fixed) or ENOENT ... .goose/mcp.json (new, still open).
Generated by 🔍 [aw] Failure Investigator (6h) · agent · 232.9 AIC · ⌖ 42.2 AIC · ⊞ 5.2K · ◷
Fix the Goose engine's job setup so the
awffirewall binary is onPATHbefore "Execute Goose CLI" runs — right now the step fails immediately withawf: command not found(exit 127), before Goose ever starts.Affected workflow / run
.github/workflows/smoke-goose.lock.yml)Probable root cause
Full job log (
agenticworkflows audit,workflow-logs/4_agent.txt) shows the step's generated shell script directly invoking the firewall wrapper:which fails immediately with:
The
awfbinary was never installed ontoPATHfor this job before the step ran — this looks like a step-ordering or PATH-export gap specific to the Goose engine's generated job (the CVE-scan, Claude Code, and Copilot CLI jobs analyzed in this same window did not hit a missing-binary error at this stage).Proposed remediation
.lock.ymljob's steps against a working engine (e.g. Claude Code CLI) to confirm both get the same awf-install/PATH-setup step ahead of CLI execution.awfis installed and placed onPATHbefore "Execute Goose CLI" runs — fix the PATH export order or missing install step in the workflow codegen for thegooseengine specifically.Success criteria
command -v awfsucceeds inside the Smoke Goose job immediately before "Execute Goose CLI".awf: command not found/ exit 127.Related to [aw-failures] [aw] Failure Investigator Report — 2026-08-03 (6h) #50077
Update — 2026-08-04 (12:14 UTC recurrence)
The
awf: command not foundbug is gone — a new, different bug now blocks the same step. Don't close this yet.Run §30908234685, job 91988815439, "Execute Goose CLI":
awfnow runs successfully (no more exit 127 / command-not-found), so whatever fixed PATH ordering landed. But the step still fails, now inside the Goose harness itself:goose_harness.cjs:26reads.goose/mcp.jsonas a relative path, which only resolves if the process cwd happens to be the directory containing that file. Givenawfnow wraps the container with--container-workdir "${GITHUB_WORKSPACE}", the harness's cwd is likely the workspace root rather than wherever.goose/mcp.jsonis actually written — a path-resolution gap introduced or exposed by the same fix that gotawfonto PATH.Proposed remediation: make
goose_harness.cjs's.goose/mcp.jsonlookup absolute (resolve relative to the script's own directory, the container workdir, or wherever the config-generation step actually writes it) instead of relying on an implicit relative cwd.Updated success criteria: Smoke Goose completes past "Execute Goose CLI" without either
awf: command not found(fixed) orENOENT ... .goose/mcp.json(new, still open).