Problem
The base Codex entrypoint.sh (from PR #251) re-appends model, model_provider, and [model_providers.vllm] to config.toml on every container start. Since config.toml lives on a persistent PVC, multiple rollouts (e.g., the two-patch deployment flow in the MLflow tracing docs) can accumulate duplicate TOML keys, causing:
config.toml:4:1: duplicate key model
Codex refuses to load when this happens.
Workaround: Clear /workspace/.codex/config.toml and do a clean restart.
Root Cause
setup_model_provider() uses sed -i '/^model\s*=/d' to remove existing keys before re-inserting. The \s escape is a GNU sed extension, not POSIX BRE — on some container images it may not match, leaving the old keys in place while new ones are inserted at line 1.
Even when the sed works, the two-patch deployment flow triggers two rollouts in quick succession. If the first rollout's entrypoint writes config and the second rollout starts before the pod is fully replaced, the PVC-backed config can end up with duplicate entries.
Suggested Fix
Add an idempotency guard — check whether keys already exist with the correct values before writing:
if ! grep -q "^model = \"${model}\"" "${config_file}" 2>/dev/null; then
# remove old + insert new
fiOr use POSIX-compatible patterns: '/^model[[:space:]]*=/d' instead of '/^model\s*=/d'.
Context
Flagged by @Nehanth during clean-room testing of PR #284 (MLflow tracing). Not a blocker for tracing — this is a base-image issue.
References
Problem
The base Codex
entrypoint.sh(from PR #251) re-appendsmodel,model_provider, and[model_providers.vllm]toconfig.tomlon every container start. Sinceconfig.tomllives on a persistent PVC, multiple rollouts (e.g., the two-patch deployment flow in the MLflow tracing docs) can accumulate duplicate TOML keys, causing:Codex refuses to load when this happens.
Workaround: Clear
/workspace/.codex/config.tomland do a clean restart.Root Cause
setup_model_provider()usessed -i '/^model\s*=/d'to remove existing keys before re-inserting. The\sescape is a GNU sed extension, not POSIX BRE — on some container images it may not match, leaving the old keys in place while new ones are inserted at line 1.Even when the sed works, the two-patch deployment flow triggers two rollouts in quick succession. If the first rollout's entrypoint writes config and the second rollout starts before the pod is fully replaced, the PVC-backed config can end up with duplicate entries.
Suggested Fix
Add an idempotency guard — check whether keys already exist with the correct values before writing:
Or use POSIX-compatible patterns:
'/^model[[:space:]]*=/d'instead of'/^model\s*=/d'.Context
Flagged by @Nehanth during clean-room testing of PR #284 (MLflow tracing). Not a blocker for tracing — this is a base-image issue.
References