You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The runner image pre-installs the Codex ACP adapter at build time to pin its version (decision D-005): Dockerfile.gh runs install-agent codex --agent-process-version 1.1.7 as user node with ENV HOME=/home/node, so the baked install lands in /home/node/.local/share/sandbox-agent.
When the container runs with a different uid and HOME, the sandbox-agent daemon looks in $HOME/.local/share/sandbox-agent, misses the baked pin, and installs the adapter from npm with the floating ^1.1.7 range. The local dev compose runs the runner as the host uid (1004:1004) with HOME=/tmp, so this happens on every fresh container: today that floating install resolved to codex-acp 1.7.0 (bundling @openai/codex 0.148.0) instead of the pinned 1.1.7 (@openai/codex 0.145.0).
The Dockerfile comment already names the hazard: "Without a fixed HOME an arbitrary runtime uid would miss the baked pin and reinstall." The fixed HOME does not survive a compose user: override.
Observed consequences (local OSS dev stack, 2026-09-01)
The unpinned 1.7.0 adapter's install-verify step (codex-acp --help) never exits. The first codex session after the runner restart hung forever in create_instance, and the session was stuck exactly as in (bug) An agent turn whose sandbox dies under it hangs for 30 minutes instead of failing #6418. Killing the hung --help process released a 15-minute-old create_instance call, and the turn then ran normally.
/tmp empties on every container replacement, so every deployment re-rolls the adapter version dice.
Expected: the runtime daemon uses the baked, pinned adapter regardless of the uid and HOME the orchestrator assigns, or the runner refuses to fall back to a floating npm install.
The runner image pre-installs the Codex ACP adapter at build time to pin its version (decision D-005):
Dockerfile.ghrunsinstall-agent codex --agent-process-version 1.1.7as usernodewithENV HOME=/home/node, so the baked install lands in/home/node/.local/share/sandbox-agent.When the container runs with a different uid and HOME, the sandbox-agent daemon looks in
$HOME/.local/share/sandbox-agent, misses the baked pin, and installs the adapter from npm with the floating^1.1.7range. The local dev compose runs the runner as the host uid (1004:1004) withHOME=/tmp, so this happens on every fresh container: today that floating install resolved to codex-acp 1.7.0 (bundling @openai/codex 0.148.0) instead of the pinned 1.1.7 (@openai/codex 0.145.0).The Dockerfile comment already names the hazard: "Without a fixed HOME an arbitrary runtime uid would miss the baked pin and reinstall." The fixed HOME does not survive a compose
user:override.Observed consequences (local OSS dev stack, 2026-09-01)
codex-acp --help) never exits. The first codex session after the runner restart hung forever increate_instance, and the session was stuck exactly as in (bug) An agent turn whose sandbox dies under it hangs for 30 minutes instead of failing #6418. Killing the hung--helpprocess released a 15-minute-oldcreate_instancecall, and the turn then ran normally./tmpempties on every container replacement, so every deployment re-rolls the adapter version dice.Verification snapshot
Expected: the runtime daemon uses the baked, pinned adapter regardless of the uid and HOME the orchestrator assigns, or the runner refuses to fall back to a floating npm install.