codex fails to launch on macOS due to unsupported env -S shebang

Resolved 💬 7 comments Opened Apr 16, 2025 by dahifi Closed Apr 16, 2025
💡 Likely answer: A maintainer (tibo-openai, collaborator) responded on this thread — see the highlighted reply below.

On macOS(Apple Silicon), attempting to run the @openai/codex CLI installed via pnpm results in the following error:

/Users/USERNAME/Library/pnpm/codex: line 16: exec: NODE_OPTIONS=--no-deprecation: not found

📍 Root cause

The top of the shim script contains:

#!/usr/bin/env -S NODE_OPTIONS=--no-deprecation node

The -S flag is a GNU extension to env, and is not supported on macOS, which uses BSD coreutils by default. As a result, this shebang is not portable and fails with a confusing error.

✅ Proposed fix

Update the shebang in the codex launcher script to use a more portable invocation:

#!/bin/bash
NODE_OPTIONS=--no-deprecation exec node /absolute/path/to/dist/cli.js "$@"

Or, if relative resolution is preferred:

#!/bin/bash
NODE_OPTIONS=--no-deprecation exec node "$(dirname "$0")/../global/5/node_modules/@openai/codex/dist/cli.js" "$@"

This resolves the issue across macOS and Linux while keeping the environment flag behavior intact.

🔁 Workaround for users

Until this is fixed in the distributed package, users can create a wrapper script in ~/bin with:

#!/bin/bash
NODE_OPTIONS=--no-deprecation exec node /Users/USERNAME/Library/pnpm/global/5/node_modules/@openai/codex/dist/cli.js "$@"

And ensure ~/bin is at the front of their $PATH.

View original on GitHub ↗

7 Comments

tibo-openai collaborator · 1 year ago

Thank you for the detailed issue description, proposed fix looks good, please send a PR!

dahifi · 1 year ago

Not sure if the PR is any good, but wanted the workaround out there in the meantime.

slhck · 1 year ago

FWIW I am on macOS and it runs just fine:

➜ npm install -g @openai/codex
npm warn deprecated phin@2.9.3: Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.
npm warn deprecated lodash.isequal@4.5.0: This package is deprecated. Use require('node:util').isDeepStrictEqual instead.

removed 63 packages, and changed 326 packages in 10s

84 packages are looking for funding
  run `npm fund` for details

➜ head -n1 /Users/werner/.nvm/versions/node/v22.14.0/bin/codex
#!/usr/bin/env -S NODE_OPTIONS=--no-deprecation node

➜ codex --version
0.1.4161114

Where do you get that -S is "not supported on macOS"? Per the manpage, "The -P, -S and -v options were added in FreeBSD 6.0." — that was released in 2005.

➜ /usr/bin/env -S
/usr/bin/env: option requires an argument -- S
usage: env [-0iv] [-C workdir] [-P utilpath] [-S string]
           [-u name] [name=value ...] [utility [argument ...]]
dahifi · 1 year ago

Copilot is arguing that the npm package fails when parsed as a shebang in the generated wrapper script, that the "generated global binary (the shim) is interpreted differently than a direct node call or shell script."

The workaround is solid for me, and there are others already reporting similar issues.

jacob-israel-turner · 1 year ago

I had the same issue, and @dahifi's workaround seems to be working for me so far.

jonchurch contributor · 1 year ago

This should be closed now with https://github.com/openai/codex/pull/96, once a new version is released

pixelb · 1 year ago

Note the GNU implementation was modeled after FreeBSD, which implemented the -S options since FreeBSD 5.5 (2008).
It looks like your env(1) is trying to execute NODE_OPTIONS=--no-deprecation rather than taking it as a directive to set that env var. Testing on GNU, macOS 12.7.4, FreeBSD 15, and macOS 15.4 at least show the expected interpretation of an env var setting for any entry containing '='. You can test this with env -vS'FOO=bar true'

$ env -vS'FOO=bar true'
split -S:  ‘FOO=bar true’
 into:    ‘FOO=bar’
     &    ‘true’
setenv:   FOO=bar
executing: true
   arg[0]= ‘true’

It would be interesting to see output from env -vS'FOO=bar true' on a system that had this issue to see if they also have this operation