codex - 💡(How to fix) Fix Nested Codex does not reuse inherited arg0 helper aliases after helper setup failure [1 comments, 2 participants]

What version of Codex CLI is running?

codex-cli 0.120.0

What subscription do you have?

pro

Which model were you using?

gpt-5.4 xhigh

What platform is your computer?

Linux 5.15.167.4-microsoft-standard-WSL2 x86_64 x86_64 Ubuntu 24.04.4 LTS

What terminal emulator and version are you using (if applicable)?

WSL2 Ubuntu on Windows TERM=xterm-256color

What issue are you seeing?

Nested Codex invocations can emit a PATH setup warning, or lose the preferred helper paths, when the child process cannot create a fresh arg0 helper directory even though the parent Codex process already provided valid helper aliases on PATH.

Codex uses arg0-dispatched helper aliases such as:

• apply_patch
• applypatch
• codex-execve-wrapper
• codex-linux-sandbox

These aliases point back to the main Codex executable. A parent Codex process can create and prepend this helper directory to PATH, but a nested Codex process may run in a more restricted environment where creating a new helper directory fails.

Current behavior treats the helper setup failure as final and proceeds with a warning:

WARNING: proceeding, even though we could not update PATH: ...

In my WSL2 environment, this warning is reproducible when helper setup cannot write under the selected CODEX_HOME:

$ mkdir -p /tmp/codex-issue-home
$ CODEX_HOME=/tmp/codex-issue-home codex --version
WARNING: proceeding, even though we could not update PATH: Refusing to create helper binaries under temporary dir "/tmp" (codex_home: "/tmp/codex-issue-home")
codex-cli 0.120.0

The same warning appears when launching the Linux sandbox path:

$ CODEX_HOME=/tmp/codex-issue-home codex sandbox linux echo
WARNING: proceeding, even though we could not update PATH: Refusing to create helper binaries under temporary dir "/tmp" (codex_home: "/tmp/codex-issue-home")

The bug is not that Codex refuses to create fresh helper aliases under /tmp; that part appears intentional. The issue is that after fresh helper setup fails, a nested child process does not try to reuse a complete helper set that was already inherited on PATH.

What steps can reproduce the bug?

The practical failure shape is:

1. Parent Codex creates arg0 helper aliases.
2. Child Codex starts inside a restricted environment.
3. Child cannot create a fresh helper directory.
4. Parent helper aliases are still on PATH.
5. Child warns or falls back instead of reusing those aliases.

A synthetic repro is:

1. Start from a Codex process that has valid helper aliases on PATH.
2. Launch a nested Codex process with CODEX_HOME set to an existing directory where fresh helper setup is refused or unavailable.
3. Observe that the child still emits the helper setup warning instead of validating and reusing the inherited helper aliases.

The aliases that matter are:

• apply_patch
• applypatch
• codex-execve-wrapper
• codex-linux-sandbox

They should all resolve to the same Codex executable as the child process.

What is the expected behavior?

Expected behavior:

If fresh arg0 helper setup fails, Codex should check whether PATH already contains a complete, trustworthy helper directory from the current Codex executable.

It should only reuse the existing helper directory if every required alias resolves to the currently running executable:

• apply_patch resolves to the current Codex executable
• applypatch resolves to the current Codex executable
• codex-execve-wrapper resolves to the current Codex executable
• codex-linux-sandbox resolves to the current Codex executable on Linux

If that validation fails, Codex should keep the current warning behavior.

Additional information:

Root-cause hypothesis: arg0_dispatch() currently calls prepend_path_entry_for_codex_aliases(). If that fails, it warns and returns None.

For nested invocations, this misses a valid recovery path: the parent process may already have created the helper aliases and prepended them to PATH.

Potential fix:

1. On Unix, when prepend_path_entry_for_codex_aliases() fails, scan existing PATH entries.
2. Look for a directory containing the expected arg0 helper aliases.
3. Canonicalize each alias.
4. Reuse the directory only if every alias points to the current executable.
5. Otherwise preserve the existing warning or fallback behavior.

I tested a local patch with this behavior.

Validation:

• CODEX_SKIP_VENDORED_BWRAP=1 cargo test -p codex-arg0
• CODEX_SKIP_VENDORED_BWRAP=1 cargo clippy -p codex-arg0 --all-targets -- -D warnings
• Built patched codex-cli and verified:
  • missing CODEX_HOME without reusable aliases still prints the warning
  • missing CODEX_HOME with trusted aliases on PATH exits successfully without the warning

Additional information

No response