Codex.app prepends bundled Resources directory to PATH, causing bundled Node to break native addons on macOS

What version of the Codex App are you using (From “About Codex” dialog)?

v0.119.0-alpha.28

What subscription do you have?

Plus

What platform is your computer?

macOS 26.3.1 Darwin 25.3.0 arm64 Apple Silicon Shell: zsh Homebrew Node: v24.4.1 at /opt/homebrew/bin/node

What issue are you seeing?

Codex.app added this line to my ~/.zshrc:

```sh
export PATH="/Applications/Codex.app/Contents/Resources:$PATH"

That directory contains the desired codex CLI, but it also contains a bundled node binary. Because the whole Resources directory is prepended to PATH, normal shell commands resolve bare node to Codex's bundled Node instead of my Homebrew Node:

which node
# /Applications/Codex.app/Contents/Resources/node

Codex's bundled Node is Developer-ID signed with hardened runtime enabled:

TeamIdentifier=2DC432GLL2
CodeDirectory flags=0x10000(runtime)

That Node cannot load common third-party native .node addons installed by npm. For example, @next/swc-darwin-arm64 fails with:

Error: dlopen(.../node_modules/@next/swc-darwin-arm64/next-swc.darwin-arm64.node, 0x0001):
code signature ... not valid for use in process:
mapping process and mapped file (non-platform) have different Team IDs
code: 'ERR_DLOPEN_FAILED'

The same native addon loads successfully with Homebrew Node:

/opt/homebrew/bin/node -e "require('./node_modules/@next/swc-darwin-arm64/next-swc.darwin-arm64.node'); console.log('ok')" # ok

So the issue is not the addon install, npm cache, quarantine attributes, or project dependencies. The issue is that Codex's private hardened-runtime Node is being exposed as the user's general-purpose node.

What steps can reproduce the bug?

```md

1. Install Codex.app on macOS.
2. Observe that ~/.zshrc contains:

```sh
export PATH="/Applications/Codex.app/Contents/Resources:$PATH"

1. Open a new zsh shell.
2. Run:

which node
node -p "process.version + ' ' + process.execPath"

Actual result:

/Applications/Codex.app/Contents/Resources/node
v24.14.0 /Applications/Codex.app/Contents/Resources/node

1. In a Next.js project with dependencies installed, run:

node -e "require('./node_modules/@next/swc-darwin-arm64/next-swc.darwin-arm64.node')"

Actual result: native addon fails to load with a hardened-runtime Team ID mismatch.

1. Run the same command with Homebrew Node:

/opt/homebrew/bin/node -e "require('./node_modules/@next/swc-darwin-arm64/next-swc.darwin-arm64.node'); console.log('ok')"

Actual result: loads successfully.

What is the expected behavior?

``md
Installing Codex.app should make the codex CLI available without changing the user's general-purpose node`.

The installer should not prepend the entire app Resources directory to PATH. It should expose only the intended CLI binaries, for example by
symlinking or shimming codex and codex_chronicle into ~/.local/bin or another standard bin directory.

Expected:

```sh
which codex
# ~/.local/bin/codex or another dedicated CLI shim

which node
# /opt/homebrew/bin/node, ~/.nvm/.../node, or the user's configured Node

Additional information

```md
Workaround:

```sh
# Remove this line from ~/.zshrc:
# export PATH="/Applications/Codex.app/Contents/Resources:$PATH"

mkdir -p ~/.local/bin
ln -s /Applications/Codex.app/Contents/Resources/codex ~/.local/bin/codex

After opening a new shell:

which node
# /opt/homebrew/bin/node

which codex
# ~/.local/bin/codex

This affects Node-based development workflows that use native addons, including Next.js/SWC, Vitest/Rolldown, Lightning CSS, and similar packages. The failure mode is misleading because it looks like a codesigning or npm install problem, but the root cause is PATH shadowing by Codex.app's bundled Node.