Symptom
On Daytona-backed runs, the Codex CLI pre-provisioned in the sandbox snapshot is older than the version the runner pins (@agentclientprotocol/codex-acp 1.1.7, bundling @openai/codex 0.145.0, pinned in services/runner/docker/Dockerfile.gh and Dockerfile.dev). During Codex harness QA (PR #5509, milestone 5) the older snapshot Codex rejected the current model generation (gpt-5.6 family), so a stale snapshot silently degrades which models a Daytona Codex run can use.
Why it happens
The local runner images pin the adapter at build time (decision D-005 in docs/design/codex-harness/decisions.md), so the daemon never fetches a floating version. The Daytona snapshot is built by a separate recipe that does not apply the same pin, so the two drift apart whenever the snapshot is rebuilt on a different date than the runner image.
Fix
Apply the same pinned install step (install-agent codex --agent-process-version 1.1.7, or whatever version the runner Dockerfiles pin at that time) in the snapshot build recipe, and treat the pin as one value with two consumers: bump the Dockerfiles and the snapshot recipe together.
Context
Follow-up recorded in docs/design/codex-harness/status.md and the final report on PR #5509. The snapshot recipe lives outside this repository, so this issue tracks the coordination, not a code change here.
https://claude.ai/code/session_01TNqjpdGV3SBZUazJj7AgA9
Symptom
On Daytona-backed runs, the Codex CLI pre-provisioned in the sandbox snapshot is older than the version the runner pins (
@agentclientprotocol/codex-acp1.1.7, bundling@openai/codex0.145.0, pinned inservices/runner/docker/Dockerfile.ghandDockerfile.dev). During Codex harness QA (PR #5509, milestone 5) the older snapshot Codex rejected the current model generation (gpt-5.6 family), so a stale snapshot silently degrades which models a Daytona Codex run can use.Why it happens
The local runner images pin the adapter at build time (decision D-005 in
docs/design/codex-harness/decisions.md), so the daemon never fetches a floating version. The Daytona snapshot is built by a separate recipe that does not apply the same pin, so the two drift apart whenever the snapshot is rebuilt on a different date than the runner image.Fix
Apply the same pinned install step (
install-agent codex --agent-process-version 1.1.7, or whatever version the runner Dockerfiles pin at that time) in the snapshot build recipe, and treat the pin as one value with two consumers: bump the Dockerfiles and the snapshot recipe together.Context
Follow-up recorded in
docs/design/codex-harness/status.mdand the final report on PR #5509. The snapshot recipe lives outside this repository, so this issue tracks the coordination, not a code change here.https://claude.ai/code/session_01TNqjpdGV3SBZUazJj7AgA9