Repository navigation
engine.command skips the AWF firewall install, so the hand-pinned binary drifts from the config gh-aw writes #58340
Description
This issue was posted by Claude Code using claude-opus-5 on behalf of David.
Ask: install the AWF binary whenever the firewall is enabled, independent of the engine. It is a firewall concern, not an engine concern, and today engine.command drops it.
ClaudeEngine.GetInstallationSteps returns early as soon as EngineConfig.Command != "" (claude_engine.go#L113-L117), before it reaches BuildNpmEngineInstallStepsWithAWF (nodejs.go#L130) — the only thing that emits the AWF install, and already gated on isFirewallEnabled. A workflow with engine.command plus the firewall on therefore compiles to a lock whose agent job has no install_awf_binary.sh, while its detection job (which gh-aw launches itself) has one.
The workaround is a hand-written pre-steps: entry, and nothing lets it track gh-aw:
install_awf_binary.shrequires the version argument — there is no default.github/gh-aw-actions/setupexposes noawf-versionoutput.GH_AW_INFO_AWF_VERSIONis step-levelenvon gh-aw's own steps, so apre-steps:entry cannot read it.
So the pin is a literal that any gh-aw upgrade silently invalidates. On v0.86.2 gh-aw bundles AWF v0.27.44 and writes apiProxy.providers into awf-config.json; our still-pinned v0.27.42 binary rejected it and every agent job died before the model started:
[ERROR] Error loading --config: Invalid AWF config at .../awf-config.json:
- config.apiProxy.providers is not supported
Failing run · our fix, which bumps the literal and adds a CI check that the pin equals the compiled GH_AW_INFO_AWF_VERSION.
#51271 fixed the sibling case (non-npm behavior-defined engines) but deliberately preserved the custom-command skip, so this path is untouched.
Reproduce, and the alternative fix
A workflow whose engine is claude with command set and the firewall enabled. grep -c install_awf_binary <name>.lock.yml counts only the install gh-aw emits for the detection job; the agent job has none of its own.
If keeping the skip is deliberate, exposing the bundled version would be enough for us — a job-level GH_AW_INFO_AWF_VERSION, or an awf-version output on github/gh-aw-actions/setup — so the pre-step can reference it instead of a literal.
Activity
docs: link the upstream tracking issue for the AWF install skip
dsfaccini commentedon Sep 4, 2026
A second, smaller ask on the same generated-lock surface, since it is what actually pins us to v0.86.2 and blocks the upgrade that would carry any fix to the above.
Emit
# zizmor: ignore[github-env]on theSet runtime pathsstep, the way the generator already does onConfigure GH_HOST for enterprise compatibility.v0.87.10 and v0.88.2 generate:
zizmor's
github-envaudit reports that athighin any workflow withworkflow_runorpull_request_target. It flags everyecho "VAR=${expansion}" >> $GITHUB_ENVand deliberately does not try to prove the expansion is trusted — see the trigger gate at github_env.rs#L390-L395 and the literal-args filter at #L111-L131. #57775 removed the${{ }}interpolation and cleared the CodeQL alert, but the write itself still trips this separate audit.The generator already handles the identical shape one step away:
Measured by compiling our 13 locks with each version and running zizmor: 0 high at v0.86.2, 1 high at v0.87.10, 1 high at v0.88.2 — one finding, in our single
workflow_runworkflow. A repo-level ignore would work but blanket-suppresses the audit across every generated lock, including writes you might add later; the inline comment keeps it live.