mirror of
https://github.com/openai/codex.git
synced 2026-04-24 06:35:50 +00:00
ddde50c611
## Why The Ubuntu GNU remote Cargo run has been regularly failing sandboxed `suite::remote_env` filesystem tests with `No such file or directory`, while the same cases pass under Bazel. The Cargo remote-env setup starts `target/debug/codex exec-server` inside Docker via `scripts/test-remote-env.sh`. That CLI builds `codex-linux-sandbox` and other arg0 helper aliases in a temporary directory, then passes those alias paths into the exec-server runtime. `arg0_dispatch_or_else` constructed `Arg0DispatchPaths` from that temporary alias guard, but then awaited the async CLI entry point without otherwise keeping the guard live. That allowed the guard to be dropped while the exec-server was still running, removing the helper alias directory. Later sandboxed filesystem calls tried to spawn the now-deleted `codex-linux-sandbox` path and surfaced as `ENOENT`. The relevant distinction I found is that `core/tests/common` stores the result of `arg0_dispatch()` in a process-lifetime `OnceLock<Option<Arg0PathEntryGuard>>` for test binaries. The Cargo remote-env setup exercises a real `codex exec-server` process instead, so it depends on the normal CLI lifetime behavior fixed here. ## What Changed - Keep the arg0 tempdir guard alive until `main_fn(paths).await` completes. - Keep the helper on the real `arg0_dispatch()` shape, where alias setup can fail and return `None` in production. - Add a regression test that uses an explicit guard, yields once, and verifies the generated helper alias path still exists while the async entry point is running. ## Verification - `cargo test -p codex-arg0` - `just argument-comment-lint -p codex-arg0` - `just fix -p codex-arg0`