codex switches shell, causing tools to run under x86 emulation

Resolved 💬 8 comments Opened Aug 21, 2025 by gcp Closed Jan 10, 2026

💡 Likely answer: A maintainer (oyiakoumis, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.23.0

Which model were you using?

gpt-5-mini

What platform is your computer?

Darwin 24.6.0 arm64 arm

What steps can reproduce the bug?

This was observed because asking codex to run the build system failed with an error that the Rust compiler for x86_64 was not installed, despite the system being an Apple Silicon mac targeting itself.

This is typically caused by a calling tool being x86 - this will force macOS to run everything below it in the call-chain to run under emulation.

Asking codex to echo back what it observed revealed the culprit was python being x86. But the PATH has the ARM binary first, and checking PATH in the shell indeed reveals that we should never end up with the x86 one.

Asking codex to echo PATH shows that it is reordered before scripts are executed. In this case, this will cause many tool calls to run under Rosetta 2 emulation! if the user has some x86 tools installed. I believe this is a fairly typical setup for many mac developers using homebrew, see e.g. https://docs.brew.sh/FAQ#why-is-the-default-installation-prefix-opthomebrew-on-apple-silicon

Maybe this was some attempt at protecting the system? It's _not_ safe to do this as you can observe. Note this also happens in YOLO mode.

What is the expected behavior?

export | grep PATH
PATH=/Users/morbo/.local/bin:/opt/homebrew/sbin:/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/X11/bin:/Library/Apple/usr/bin:/Users/morbo/.cargo/bin:/Applications/iTerm.app/Contents/Resources/utilities:/Users/morbo/.lmstudio/bin

What do you see instead?

user
What do you believe the current PATH is?

thinking
Preparing environment variable output

I'm planning to print the current PATH environment variable. I'll call the shell command to get the result, presenting
it alongside a brief explanation. I'll make sure to format the command in monospace using backticks around the path.
The preamble message will be concise, just 1-2 sentences. Alright, let’s move forward with the shell function to get
this information!

codex
I'll run a quick shell command to print the current PATH environment variable.

✓ Completed
  └ ⌨️ echo "$PATH"

codex
- Command: echo "$PATH"
- Result: `/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/
codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/
com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/X11/bin:/Library/Apple/usr/bin:/Users/
morbo/.local/bin:/opt/homebrew/sbin:/opt/homebrew/bin:/Users/morbo/.cargo/bin:/Applications/iTerm.app/Contents/
Resources/utilities:/Users/morbo/.lmstudio/bin:/Users/morbo/.lmstudio/bin

That's the current PATH in this environment.

Additional information

_No response_

View original on GitHub ↗

8 Comments

gcp · 11 months ago

PR #634 looks related, but it only talks about /bin and /usr/bin. That would have been fine here, but the order of /usr/local/bin is also changed, which is not good.

gcp · 11 months ago

Dupe of https://github.com/openai/codex/issues/622 which was closed without being fixed, though note this bug persists even with --dangerously-bypass-approvals-and-sandbox.

oyiakoumis contributor · 11 months ago

After debugging, I can tell you that codex does not rewrite PATH. Instead, it runs bash inside zsh (which is the default shell on macOS).

When you ask the agent to run echo $PATH, it usually executes as:

bash -lc 'echo $PATH'

but the logs only display echo $PATH. Since this is running in a separate bash -lc session, the PATH differs from what you would see in your interactive zsh session.

You can verify this by comparing the outputs:

codex debug seatbelt -- echo $PATH        # shows your zsh PATH
codex debug seatbelt -- bash -lc 'echo $PATH'   # shows your bash PATH

So yes, this is a bug: the agent should respect the user’s default shell to avoid inconsistencies and unexpected behavior.

gcp · 11 months ago

Thanks, good find. So I'd need to move some of those exports PATH to .profile instead of .zshrc. (.bashrc would not work either).

So yes, this is a bug: the agent should respect the user’s default shell to avoid inconsistencies and unexpected behavior.

I'm not so sure about that. The problem is the agent may be trained or expecting the shell to have certain built-ins and behaviors, and it may specifically be calling bash because that's what it was trained with (see e.g. great GPT5 performance on https://github.com/SWE-agent/mini-swe-agent in https://www.swebench.com/bash-only.html).

Based on this, I'm not sure this is a bug, but it's certainly a potential pitfall. Claude Code doesn't seem to do this.

gcp · 11 months ago

Perhaps related to issue https://github.com/openai/codex/issues/1708

oyiakoumis contributor · 11 months ago

Based on this, I'm not sure this is a bug, but it's certainly a potential pitfall. Claude Code doesn't seem to do this.

You’re right, maybe not a real bug, but it feels like a pitfall. What’s odd is that the agent seems to randomly pick between bash and zsh.

What bothers me is the inconsistency in how commands are displayed. For example:

When I ask the agent to run bash -lc 'echo $PATH', the actual command executed is bash -lc 'echo $PATH', but the parsed command shown to the user is just 'echo $PATH'.
When I run zsh -lc 'echo $PATH', both the executed and the displayed command are correctly zsh -lc 'echo $PATH'.

I see that in the file codex-rs/core/src/parse_command.rs, there is a parsing specifically for bash commands that do remove the bash -lc.

deksden · 10 months ago

form me on macos on codex 0.36 - same bug. Codex can not run vitest, because architecture mismatch. weird! CC runs all stuff without any problem.

Codex team! Please fix it

v0.40 - same bug

etraut-openai contributor · 6 months ago

Closing old issue.