fix(runner): seed the pinned Codex adapter under HOME overrides and bound ACP init

[mmabrouk]

The symptom

On a self-hosted stack, a Codex session sat at "running" for 17.6 minutes with no output and no error. The runner kept heart-beating the turn, the agent service's read timed out, and the API watchdog finally settled the execution as lost after 15 minutes. The user had no error to read and nothing to retry.

The deployment followed the documented subscription scheme: the runner container runs as the operator's own uid with HOME=/tmp.

The cause

Two things, and the second is what made the first fatal.

The runner image bakes a pinned Codex ACP adapter (@agentclientprotocol/codex-acp 1.1.7, patched) under $HOME/.local/share/sandbox-agent, with ENV HOME fixed so the build and the runtime agree. The harness daemon resolves that directory from $XDG_DATA_HOME, else $HOME/.local/share. Overriding HOME moves the directory, the daemon finds no adapter there, and it cold-installs one instead: it downloads the native codex binary from GitHub "latest", npm-installs the floating latest codex-acp (1.12.0 today, unpatched and drifting), and then verifies it by running codex-acp --help with stdin set to /dev/null.

That probe never returns. It hangs on every version tested (1.1.7, 1.11.0, 1.12.0), and it exits in two seconds only when stdin is a closed pipe. The daemon puts no timeout on it.

Nothing on the runner's side had a deadline either, so initialize never answered and the stage recorded [timing] stage=create_session ms=1059706.

The baked tree was also mode 0700, so a container running as any other uid could not have read the pin even if it had looked there.

The fix

The runner seeds the pin itself. At boot, before any daemon starts, it computes the daemon's data directory the same way the daemon does and copies the baked bin/agent_processes and bin/codex into it, then rewrites the launcher's exec path to the copy. It skips when the data directory is the baked location, skips when anything is already installed there, and logs one line either way. A missing or unreadable pin is a warning, never a crash.

Both images make the pin readable by any uid, so the seed can read what it is copying.

Opening the ACP session is bounded. AGENTA_RUNNER_ACP_INIT_TIMEOUT_MS (default 120000) caps the handshake and fails the run with a typed error naming the harness ("Codex harness did not initialize within 120s"), which settles the turn on the same path a harness crash takes. A load that times out does not degrade into a create, because that would spend the budget twice on a harness that is not answering. This bounds the handshake only, never the model's own time.

Sandbox teardown is bounded too. The first end-to-end test of the timeout found that the failed run still could not answer its caller: with an ACP request in flight, the local provider's teardown does not return, so the run hung anyway. Each provider teardown call now gets 30 seconds, after which teardown moves on and logs that it did.

Verification

Built the gh image from this branch and ran it as --user 1004:1004 -e HOME=/tmp.

The boot log:

[adapter-seed] seeded the pinned Codex adapter into the daemon data dir: /home/node/.local/share/sandbox-agent/bin/agent_processes -> /tmp/.local/share/sandbox-agent (947ms)

The seeded adapter is the pin, and the launcher points at the copy:

  "version": "1.1.7",
exec '/tmp/.local/share/sandbox-agent/bin/agent_processes/codex/node_modules/.bin/codex-acp' "$@"

A daemon started by hand inside that container answered initialize in 219ms with agentInfo.version 1.1.7, where the old image hung indefinitely.

For the negative case, the seeded launcher was replaced with sleep 999 and the budget lowered to 3000ms. The run now fails instead of hanging:

{"ok":false,"error":"Codex harness did not initialize within 3s."}
[sandbox-agent] [timing] stage=create_session ms=3000 ... mode=create
[sandbox-agent] sandbox delete did not finish within 30000ms sandbox=local/...; continuing teardown without it

The run returned in 33.3 seconds, against a request that never returned at all before the teardown bound.

Runner suite: 186 files, 3149 tests, all passing. tsc --noEmit clean.

One note for anyone rebuilding the image from main: the build currently fails at the agent-tools layer with E: Version '2.100.0*' for 'gh' was not found, because that version left GitHub's apt repo. It is unrelated to this change, and the fix (#6895) has landed on release/v0.118.3 but not on main. The QA image here was built with that pin bumped locally, and the bump is not part of this branch.

Note for reviewers

The 120s default is a trade-off worth a second opinion. Claude Code is installed at runtime by design (licensing), so a genuinely cold Claude install on a slow link now has 120 seconds to finish the handshake before the run fails. The variable exists to raise it.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}