Shell snapshot drops Nix `PATH` entries while preserving `__ETC_PROFILE_NIX_SOURCED=1`, causing commands to disappear in `bash -lc`

Open 💬 2 comments Opened Mar 28, 2026 by garhbod

What version of Codex CLI is running?

codex-cli 0.116.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.12.74+deb13+1-amd64 x86_64 unknown

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

_No response_

What issue are you seeing?

In Codex 0.116.0, commands installed via Nix are available to the parent Codex process, but unavailable to tool commands executed through bash -lc.

The shell snapshot appears to serialize an inconsistent environment:

  • it preserves NIX_PROFILES
  • it preserves __ETC_PROFILE_NIX_SOURCED=1
  • but it rewrites PATH to only system directories

Because of that, later shell startup does not restore Nix paths: /etc/profile.d/nix.sh runs, but its delegated script exits early because __ETC_PROFILE_NIX_SOURCED is already set.

What steps can reproduce the bug?

  1. Start Codex in a Nix-based shell environment where the parent process PATH includes Nix profile bins.
  2. Run a tool command through Codex such as:
command -v rg
  1. Observe that it fails.
  2. Inspect the generated shell snapshot and compare its PATH to the parent process environment.

What is the expected behavior?

Commands available in the parent Codex environment should remain available in tool shell commands.

At minimum, if the snapshot preserves __ETC_PROFILE_NIX_SOURCED=1, it should also preserve the corresponding Nix-modified PATH.

Actual

The parent process has the correct Nix PATH, but the generated shell snapshot contains a reduced PATH. As a result, commands installed in the Nix profile are not found from bash -lc.

Example symptom:

command -v rg
# exits non-zero

Additional information

Evidence

Parent sandbox process environment includes Nix paths:

PATH=/tmp/codex-arg0/...:/nix/store/...-ripgrep-15.1.0/bin:/home/<user>/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/local/bin:/usr/bin:/bin:...
NIX_PROFILES=/nix/var/nix/profiles/default /home/<user>/.nix-profile
__ETC_PROFILE_NIX_SOURCED=1
SHELL=/home/<user>/.nix-profile/bin/fish

Generated shell snapshot contains:

declare -x NIX_PROFILES="/nix/var/nix/profiles/default /home/<user>/.nix-profile"
declare -x PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
declare -x SHELL="/home/<user>/.nix-profile/bin/fish"
declare -x __ETC_PROFILE_NIX_SOURCED="1"

Then bash -x -lc true shows shell init loading Nix startup, but it short-circuits immediately:

+ . /etc/profile.d/nix.sh
++ . /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh
+++ '[' -n 1 ']'
+++ return

So the shell snapshot has already made the environment inconsistent before command execution begins.

Likely root cause

The shell snapshot generator is reconstructing or sanitizing PATH incorrectly while preserving related Nix environment variables verbatim.

Suggested fix

One of:

  1. Preserve the actual inherited PATH in the shell snapshot.
  2. Do not preserve __ETC_PROFILE_NIX_SOURCED unless the snapshot also preserves the matching Nix PATH.
  3. Recompute the environment in a way that keeps Nix init state internally consistent.

Workaround

A local shell workaround is to prepend the Nix profile bin explicitly in user startup files, but this looks like a Codex environment snapshot bug rather than a user shell configuration problem.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗