Codex engine fails on self-hosted runner: vendored codex-x86_64-unknown-linux-musl binary does not support --dangerously-bypass-approvals-and-sandbox

[tomasmed]

Description

When running a workflow with engine: codex on a self-hosted Linux runner, the agent step
fails with:

error: unexpected argument '--dangerously-bypass-approvals-and-sandbox' found
tip: to pass '--dangerously-bypass-approvals-and-sandbox' as a value, use
'-- --dangerously-bypass-approvals-and-sandbox'
Usage: codex-x86_64-unknown-linux-musl exec [OPTIONS]

Steps to reproduce

1. Configure a self-hosted Linux runner (WSL2 on Windows)
2. Create a workflow with engine: codex and runs-on: ['self-hosted', 'Linux']
3. Trigger the workflow
4. The "Install Codex" step runs npm install -g @openai/codex@latest successfully
5. The agent container then calls codex exec --dangerously-bypass-approvals-and-sandbox
   against the vendored codex-x86_64-unknown-linux-musl Rust binary
6. That binary only supports --full-auto, not --dangerously-bypass-approvals-and-sandbox

Expected behaviour

Agent executes successfully using the installed Codex binary.

Actual behaviour

Binary rejects the flag and exits with code 2.

Environment

• gh-aw agent container: ghcr.io/github/gh-aw-firewall/agent:0.23.0
• Runner OS: Ubuntu (WSL2 on Windows 11)
• @openai/codex: latest (installed by gh-aw's own Install Codex step)
• The vendored Rust binary codex-x86_64-unknown-linux-musl exec --help shows
  --full-auto but not --dangerously-bypass-approvals-and-sandbox

Notes

The host-installed codex binary at /home/USER/.nvm/versions/node/v22.22.1/bin/codex
DOES support the flag — the issue is specific to the vendored musl binary used inside
the agent container.

[pelikhan]

@tomasmed how did you fix this? Update th codes binary path to pick up the installed version? You need to provide a tested fix strategy. A testing strategy would be nice too.

[tomasmed]

Still reproducible on my end. Just ran a clean /tmp/gh-aw wipe, fresh run, same error.

The fix strategy in #20161 seems correct. The root cause is clear from the logs — the agent container's PATH resolves codex-x86_64-unknown-linux-musl from the vendored system location before the npm-installed binary. On my runner, which codex returns /home/USER/.nvm/versions/node/v22.22.1/bin/codex which supports the flag correctly — but inside the container the vendored musl binary takes precedence.

But inside the container the vendored musl binary takes precedence and that binary only has --full-auto, not --dangerously-bypass-approvals-and-sandbox.

Suggested testing strategy for #20161:

1. On a self-hosted Linux runner with nvm-installed Node (common WSL2 setup), verify $(npm config get prefix)/bin is prepended correctly and resolves before /opt/hostedtoolcache
2. Confirm which codex inside the chroot resolves to the npm-installed binary, not the vendored musl one
3. Run a minimal engine: codex workflow with runs-on: ['self-hosted', 'Linux'] and verify the agent step passes the flag without error
4. Verify GitHub-hosted runners are unaffected (npm prefix /usr/local/bin already in PATH, so the change is a no-op there)

Happy to test the fix on my self-hosted WSL2 runner once #20161 is merged or if you want to share a test build.