v0.71.5 dropped --ignore-scripts from compiled npm install steps for claude-code / codex CLIs (supply-chain regression)

[jbaruch]

Summary

gh aw compile in v0.71.5 emits npm install -g @anthropic-ai/claude-code@<version> (and the equivalent @openai/codex@<version> for the codex engine) WITHOUT the --ignore-scripts flag in the generated lock files. v0.71.0 emitted npm install --ignore-scripts -g @anthropic-ai/claude-code@<version>. Comparing two compiled .lock.yml files from the same source markdown:

- run: npm install --ignore-scripts -g @anthropic-ai/claude-code@2.1.112
+ run: npm install -g @anthropic-ai/claude-code@2.1.126

Why this matters

The npm install step runs on the host runner BEFORE the awf firewall sandbox starts. Without --ignore-scripts, postinstall scripts in the dependency tree of @anthropic-ai/claude-code (or @openai/codex) execute with full host-runner access — including all secrets the workflow has loaded for itself (ANTHROPIC_API_KEY / OPENAI_API_KEY / CODEX_API_KEY / TESSL_TOKEN / GITHUB_TOKEN). A compromised transitive dependency in either CLI's tree could exfiltrate those secrets between npm-install and firewall-start, with no network egress restriction yet in place.

This is the exact supply-chain attack class --ignore-scripts was added to mitigate. The v0.71.0 lock files had it; the v0.71.5 lock files do not.

Reproduction

gh extension install githubnext/gh-aw --pin v0.71.0
gh aw compile review-anthropic.md
grep "npm install.*claude-code" review-anthropic.lock.yml
# → npm install --ignore-scripts -g @anthropic-ai/claude-code@2.1.112

gh extension remove gh-aw
gh extension install githubnext/gh-aw --pin v0.71.5
gh aw compile review-anthropic.md
grep "npm install.*claude-code" review-anthropic.lock.yml
# → npm install -g @anthropic-ai/claude-code@2.1.126

The flag drop is in the compiled-template path, not in the source markdown — the source has the same engine: claude block in both runs.

Fix

Restore --ignore-scripts to the npm install steps in the compiled-template generation for both the claude and codex engines. This is a per-engine compile-template change, no source-markdown impact for consumers.

Workaround we're shipping

In jbaruch/coding-policy-evals PR #12 we re-add the flag via a post-compile sed on the four affected lock files. We'll drop the workaround once a gh-aw release with the flag restored ships.

sed -i 's|npm install -g @anthropic-ai/claude-code|npm install --ignore-scripts -g @anthropic-ai/claude-code|g; s|npm install -g @openai/codex|npm install --ignore-scripts -g @openai/codex|g' .github/workflows/*.lock.yml

Affected versions

Confirmed in v0.71.5 (latest stable). v0.71.6 and v0.72.0 are pre-release; haven't checked whether the regression persists there.

Related context

Discovered while bumping jbaruch/coding-policy-evals from v0.71.0 to v0.71.5 to pick up working AWF binaries (the v0.25.28 release v0.71.0 pinned was yanked from github/gh-aw-firewall, breaking install on a 404). Now we're between two regressions — older gh-aw is broken on AWF download, newer gh-aw is broken on supply-chain hardening — and have to patch one. Patching --ignore-scripts back is the smaller surface; we'd like to retire the workaround when this is fixed upstream.

[jbaruch]

Update: my workaround broke Claude Code CLI startup

Adding --ignore-scripts back via post-compile sed (as I described above) does not work — Claude Code CLI v2.1.126 requires postinstall scripts to function. The agent step fails with:

ERR_CONFIG: Claude execution failed: no structured log entries were produced. This usually indicates a startup or configuration error before tool execution.

Either postinstall did not run (--ignore-scripts, some pnpm configs)
Or reinstall without --ignore-scripts / --omit=optional.

So the v0.71.5 removal of --ignore-scripts wasn't a regression — it was forced by @anthropic-ai/claude-code@2.1.126's new postinstall dependency (and presumably the same on the codex side at v0.128.0).

This reframes the issue. There's no straightforward "restore the flag" fix because the flag now breaks the install. The supply-chain attack surface I described is real, but --ignore-scripts is no longer a viable mitigation as long as both CLIs require postinstall to set themselves up.

Possible upstream paths

• claude-code / codex: stop requiring postinstall, or provide a setup-via-script alternative that runs inside the awf sandbox after firewall-start. Out of gh-aw's hands but worth raising with the CLI maintainers.
• gh-aw: install the CLIs INSIDE the awf sandbox rather than on the host runner. Would shift the install (including its postinstall scripts) inside the firewall boundary, restoring the supply-chain hardening even with postinstall enabled. This is the architectural fix. Probably non-trivial.
• Shorter-term: at minimum, document the supply-chain exposure window in gh-aw's docs / generated lockfile comment so consumers running gh-aw know about it.

What I'm shipping

Reverted my patch. Lock files match v0.71.5's compiled output (no --ignore-scripts, claude-code/codex install on host). Reframing this issue as "supply-chain exposure window" rather than "regression". Worth a separate tracking issue for the install-in-sandbox path?

[pelikhan]

We are looking into this.

[lpcox]

🔗 AWF tracking issue: https://github.com/github/gh-aw-firewall/issues/github/gh-aw-firewall#2708

Generated by Firewall Issue Dispatcher · ● 1.2M · ◷