Repository navigation
codex switches shell, causing tools to run under x86 emulation #2542
Description
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
Activity
gcp commentedon Aug 21, 2025
PR #634 looks related, but it only talks about
/binand/usr/bin. That would have been fine here, but the order of/usr/local/binis also changed, which is not good.gcp commentedon Aug 21, 2025
Dupe of #622 which was closed without being fixed, though note this bug persists even with
--dangerously-bypass-approvals-and-sandbox.oyiakoumis commentedon Aug 23, 2025
After debugging, I can tell you that codex does not rewrite
PATH. Instead, it runsbashinsidezsh(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 separatebash -lcsession, thePATHdiffers from what you would see in your interactivezshsession.You can verify this by comparing the outputs:
So yes, this is a bug: the agent should respect the user’s default shell to avoid inconsistencies and unexpected behavior.
gcp commentedon Aug 23, 2025
Thanks, good find. So I'd need to move some of those
exports PATHto.profileinstead of.zshrc. (.bashrcwould not work either).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
bashbecause 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 commentedon Aug 23, 2025
Perhaps related to issue #1708
[-]codex silently rewrites PATH, causing tools to run under x86 emulation[/-][+]codex switches shell, causing tools to run under x86 emulation[/+]oyiakoumis commentedon Aug 23, 2025
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:
bash -lc 'echo $PATH', the actual command executed isbash -lc 'echo $PATH', but the parsed command shown to the user is just'echo $PATH'.zsh -lc 'echo $PATH', both the executed and the displayed command are correctlyzsh -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 thebash -lc.deksden commentedon Sep 17, 2025
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 commentedon Jan 10, 2026
Closing old issue.