legacy-security: enable emits `sudo -E awf` but installs awf with --rootless, so the agent fails at startup with `sudo: awf: command not found`

[Calidus]

gh-aw version: v0.83.1 (v0.83.2 only bumps container versions, so it should reproduce there too)
AWF version: v0.27.38
Engine: claude · Runner: ubuntu-latest (GitHub-hosted)

Summary

Opting a workflow into legacy security mode per the migration notes in #45360 produces a lock file whose agent job cannot start: the AWF execution command uses sudo -E awf, but the install step installs the binary with --rootless into ~/.local/bin, which is not on sudo's secure_path. The agent job dies immediately with:

sudo: awf: command not found

and the run fails with ERR_CONFIG: Claude execution failed: no structured log entries were produced. Claude startup failed before structured logging.

Reproduction

1. Add the opt-in from feat: default to strict security mode, stop injecting sudo and --enable-host-access #45360 to any workflow frontmatter:

sandbox:
  agent:
    id: awf
    legacy-security: enable

2. gh aw compile with v0.83.1.

3. Inspect the generated .lock.yml — the two steps disagree:

# agent job, "Install awf" step:
run: bash "${RUNNER_TEMP}/gh-aw/actions/install_awf_binary.sh" v0.27.38 --rootless

# agent job, "Execute Claude Code CLI" step:
sudo -E awf --config ... --legacy-security --enable-host-access --allow-host-ports 80,443,8080 ...

4. Run the workflow. install_awf_binary.sh --rootless installs to ${HOME}/.local/bin (per the script's rootless branch); sudo resets PATH to secure_path, which doesn't include it. Startup fails.

Root cause

BuildAWFArgs/GetAWFCommandPrefix correctly switch to the legacy (sudo -E awf) invocation when LegacySecurity is set (#45360), but the install-step emission still passes --rootless unconditionally in the agent job. Notably, the same lock file's detection job installs without --rootless — the compiler already emits both forms; the agent job's install step just doesn't account for legacy mode.

Expected

When legacy-security: enable is set, the agent job should install awf without --rootless (i.e., to /usr/local/bin via sudo), matching the sudo -E awf invocation.

Context / impact

We have workflows whose egress requires host network access on the runner (the use case legacy-security exists for). Strict mode's rootless topology breaks them at runtime, and the documented opt-in is unusable due to this bug — the only workaround we found is pinning the compiler to a pre-v0.82.10 release.

[pelikhan]

@Calidus why do you still need this mode? could you run with "sudo: false"?

[Calidus]

@pelikhan sudo: false is the mode that breaks us, unfortunately — the requirement isn't sudo itself, it's host network access.

Our engine config points the agent's LLM traffic (ANTHROPIC_BASE_URL) at an internal gateway that's only reachable through a VPN interface on the runner host. Under rootless/network-isolation mode the failure is partial and looks like this:

• gh aw compile succeeds and the workflow starts normally
• The domain allowlist passes — firewall logs show CONNECT 200 TCP_TUNNEL to the gateway for the whole run, no denials
• LLM calls succeed for the first few minutes, then response data stops coming back; requests stall and eventually 502, and the agent times out

The same workflows compiled to the host-access invocation (sudo -E awf --enable-host-access ...) run reliably. So the rootless network topology can't sustain connections routed through the host's VPN interface — which is the use case I understood legacy-security: enable to exist for after #45360.

We're unblocked in the meantime — downgrading the compiler to v0.79.6 (gh extension install github/gh-aw --pin v0.79.6) resolved it, since that version still emits the host-access invocation. So no urgency on our end.

If there's a supported way to get host network egress (or route sandbox traffic through host interfaces) in rootless mode, I'd happily switch to it and drop legacy mode entirely — glad to test anything. Otherwise I mainly wanted to flag the install/invocation mismatch since it makes the documented opt-in fail at startup for anyone who reaches for it — but if the plan is to retire legacy mode anyway, a note in the docs pointing people at an alternative would work just as well for us.

[pelikhan]

@lpcox