›_ Codex Issues
Codex Issues / #17473

Nested Codex does not reuse inherited arg0 helper aliases after helper setup failure

Open 💬 4 comments Opened Apr 11, 2026 by schrepa
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #17367

Powered by Codex Action

rocky-m · 1 month ago

I’m seeing this on macOS with Codex CLI 0.142.4.

Inside an active Codex-managed thread:

codex --version
codex help debug
codex debug prompt-input 'hi'

I get:

WARNING: proceeding, even though we could not create PATH aliases: Operation not permitted (os error 1)

--version and help commands still succeed after the warning, but:

codex debug prompt-input 'hi'

fails with:

Error: Operation not permitted (os error 1)

The outer thread’s sandbox allows writes only to the workspace, /tmp, and the session temp dir. ~/.codex is readable but not writable.

Based on the PATH entry and existing helper dirs, the failing target seems to be:

~/.codex/tmp/arg0/codex-arg0*/

Running codex debug --help outside the Codex-managed sandbox works without the warning, so this looks like nested Codex trying to create/refresh arg0 aliases instead of reusing the existing parent-provided aliases on PATH.

Nistrul · 17 days ago

Same warning, different trigger, and no nested Codex involved: Homebrew cask installs hit this on every upgrade.

brew upgrade --cask codex prints it three times, once per shell the cask generates completions for:

==> Linking Binary 'codex' to '/opt/homebrew/bin/codex'
WARNING: proceeding, even though we could not create PATH aliases: Refusing to create helper binaries under temporary dir "/private/tmp" (codex_home: AbsolutePathBuf("/private/tmp/homebrew-cask-sandbox20260811-93178-u2vsy/home/.codex"))

Reproduces without Homebrew on 0.147.0, exit code 0 in both cases:

$ mkdir -p /private/tmp/faux/home
$ TMPDIR=/private/tmp HOME=/private/tmp/faux/home codex --version
WARNING: proceeding, even though we could not create PATH aliases: Refusing to create helper binaries under temporary dir "/private/tmp" ...
codex-cli 0.147.0

codex completion zsh behaves the same way, and that is what the cask actually runs.

Homebrew sets both variables on purpose: HOME to a scratch directory so the child cannot read the user's real home, and TMPDIR to HOMEBREW_TEMP, which is /private/tmp on macOS. CODEX_HOME then resolves under the temp root and the prefix check refuses (line 343 on main today).

The difference from the nested case in this issue: there is no parent Codex here, so there are no inherited aliases to reuse. That remedy would not reach this trigger unless it were broadened.

A complementary change that would quieten the early-exit paths in both environments: skip alias preparation for narrowly recognised invocations such as --version and completion. Neither looks up apply_patch, and completion is what Homebrew calls. That would leave inherited-alias reuse to handle the nested commands that genuinely need aliases, like the codex debug prompt-input failure above.

banshee · 14 days ago

Additional confirmed Homebrew cask reproduction on Apple Silicon:

  • Codex CLI 0.147.0
  • Homebrew 6.0.17
  • macOS 26.5.2 (25F84)
  • arm64

During brew install --cask codex, the binary links successfully and installation completes, but completion generation prints the same warning three times:

==> Linking Binary codex to /opt/homebrew/bin/codex
WARNING: proceeding, even though we could not create PATH aliases: Refusing to create helper binaries under temporary dir "/private/tmp" (codex_home: AbsolutePathBuf("/private/tmp/homebrew-cask-sandbox20260813-8942-lo8och/home/.codex"))
WARNING: proceeding, even though we could not create PATH aliases: Refusing to create helper binaries under temporary dir "/private/tmp" (codex_home: AbsolutePathBuf("/private/tmp/homebrew-cask-sandbox20260813-8942-lo8och/home/.codex"))
WARNING: proceeding, even though we could not create PATH aliases: Refusing to create helper binaries under temporary dir "/private/tmp" (codex_home: AbsolutePathBuf("/private/tmp/homebrew-cask-sandbox20260813-8942-lo8och/home/.codex"))

The final installer message is:

codex was successfully installed!

This confirms the same non-nested Homebrew completion path described above. The installed binary works and codex --version reports codex-cli 0.147.0.