Continuous permission errors since 0.59->0.60, 5.1-Codex-Max upgrade

Thanks for the bug report. Could you use the /feedback slash command to upload the session and report the thread ID here?

Thanks for the bug report. Could you use the /feedback slash command to upload the session and report the thread ID here?

019a9f00-2f7c-7f70-ac97-61fd627822eb

Same here. Unfortunately I can't share my session but on Ubuntu Linux 22.04 LTS, Codex 0.60.1. This worked fine until about recent hours. It seems to be related to the sandbox. The folder is in a git repo and is whitelisted and has been used with Codex for over a month. I am unable to reproduce it with a new test repo. Codex eventually found a workaround by escalating every single command and writing Python scripts instead of using patch, but this is far from ideal.

`

rename the API Migration folder to API_Migration

• Tried renaming documentation/API Migration → documentation/
Response_Migration, but the documentation folder itself is not writable (even as
owner). Evidence:

• mv and cp both failed with “Permission denied”.
• touch documentation/testfile fails with “Permission denied”.

I can proceed once the parent directory permissions/ACL allow creating/renaming
entries in documentation/. If you prefer, I can keep working inside the existing
API Migration folder until permissions are adjusted.
`

@zzhang1, what do you mean when you say the folder is "whitelisted"? Is it within the main working directory (where you launch codex)? Or are you configuring additional writable_roots in your codex.toml? Can you confirm that you are able to write to that directory yourself outside of the sandbox?

same here 019a9fe2-a6be-75e2-b84e-4deeefa4e39a

facing the same issue here 019a9fff-7753-7f23-85ef-d95519088b0c with a simple rg command.

same here 019a9fe2-a6be-75e2-b84e-4deeefa4e39a

https://github.com/openai/codex/issues/4620#issuecomment-3559735331

# Only run Homebrew shellenv in interactive shells,
# and only if brew actually exists.
if [[ $- == *i* ]] && [[ -x /opt/homebrew/bin/brew ]]; then
  eval "$(/opt/homebrew/bin/brew shellenv)"
fi

Fixed this for me.

> same here 019a9fe2-a6be-75e2-b84e-4deeefa4e39a The problem seems to be solved.

I fix this issue by explicitly specifying the terminal type in my .zprofile file.

# eval "$(/opt/homebrew/bin/brew shellenv)"
eval "$(/opt/homebrew/bin/brew shellenv zsh)"

so that shellenv.sh will not execute the code on line 18, as mentioned in #4620

@zzhang1, what do you mean when you say the folder is "whitelisted"? Is it within the main working directory (where you launch codex)? Or are you configuring additional writable_roots in your codex.toml? Can you confirm that you are able to write to that directory yourself outside of the sandbox?

Interestingly, it all started working again this morning with no changes from my end.

Apologies for the confusion on 'whitelisting,' I just meant that the folder was trusted, e.g.,

[projects."/home/zzhang1/project"]
trust_level = "trusted"

When it wasn't working, I was still able to write and delete files in any of the project folders myself as the same user used to run Codex. Nothing looked strange in permissions via lsattr. And Codex could even write to them if it ran Python scripts on the fly to modify files.

019aba6e-eaf4-7170-bac0-8e92096afbe3

Same problem for me. Unfortunately, none of the fixes above work for me.

019ac430-d584-74a3-b596-e284568e0ff5

Same for me 019ae384-456a-7bd0-bbdc-bc6e53064942

same here, any commands, like git diff, or git status - 019ae9fa-79c5-79e2-b29f-f6469731e2ae;
codex-cli 0.64.0, 5.1-codex-max, macOS, zsh, installed via homebrew, but when I run it and it asked for update it was 'Updating Codex via npm install -g @openai/codex@latest'

upd.:

even after full update - brew update && brew upgrade && brew upgrade --cask && brew cleanup:

==> Upgrading 2 outdated packages:
codex 0.57.0 -> 0.64.0
session-manager-plugin 1.2.707.0 -> 1.2.764.0
==> Upgrading codex
All dependencies satisfied.
==> Unlinking Binary '/opt/homebrew/bin/codex'
==> Linking Binary 'codex-aarch64-apple-darwin' to '/opt/homebrew/bin/codex'
==> Purging files for version 0.57.0 of Cask codex

it shows the same:
/opt/homebrew/Library/Homebrew/cmd/shellenv.sh: line 18: /bin/ps: Operation not permitted

This one hurts real bad.

I'm praying that this problem will be solved by openAI more quickly

After some digging, I came to the following conclusions:

The regression was introduced in PR #7786 ("feat: add shell snapshot for shell command"), merged in commit 29381ba5c2. The goal was to support "shell snapshots" that capture a user's full environment (aliases, environment variables) by running commands in a login shell (zsh -lc). This change inadvertently made all shell commands run as login shells by default.

The forced login shell sources the user's profile (~/.zprofile), which typically runs eval "$(/opt/homebrew/bin/brew shellenv)".

The Issue:

In older versions of Homebrew (specifically versions before Feb 2024), has a preference on running /bin/ps.
/bin/ps is a setuid binary.
The macOS sandbox-exec security policy correctly and strictly blocks setuid binaries to prevent privilege escalation.

Newer versions of Homebrew use lsof and thus users with an updated version of Homebrew don't experience this issue.
(@testyour - this is what we see in your case - /opt/homebrew/Library/Homebrew/cmd/shellenv.sh: line 18: /bin/ps: Operation not permitted, line 18 has /bin/ps only in older versions of Homebrew.)

• Old Homebrew: Versions before Feb 2024 (see commit 1383417) prefer to use /bin/ps to detect the shell.
• New Homebrew: Newer versions (see main) prefer lsof.

When users have the older version, brew shellenv invokes /bin/ps.
Shell initialization fails mid-way and prints Operation not permitted errors because ps is blocked. While the shell might not crash entirely, the environment (specifically PATH) is often not set up correctly, leading to "command not found" errors for tools like npm, git, or python, alongside the confusing permission error noise.

This behavior is expected to happen by default for all Mac users with Homebrew installations older than Feb 2024.
@zzhang1 mentioned it also happens for him on Ubuntu, which I didn't investigate.

@etraut-openai - We can disable the forced login shell and it would solve the issue - but it would defeats the purpose of the feature. (Change ShellCommandHandler::base_command to default use_login_shell to false instead of true).

But considering the community attention - I think it might be best to consider a cmdline flag to set use_login_shell=false and to prompt it when we detect this issue.
WDYT?

@Bronx83 appreciate you starting to dig in here. However, shell snapshots run _outside_ the sandbox, so they should, in theory, be a strict improvement here. Can you try reproducing this issue on 0.71.0?

@dylan-hurd-oai
You are absolutely correct that shell snapshots are intended to capture the environment so commands can run as non-login shells. However, although it bypasses Seatbelt sandbox, it does not bypass MacOS-Application-Sandbox.

The shell_snapshot feature introduced two components:

1. The Preparation (Always On): To support snapshots, the default shell behavior was changed to always use a login shell (use_login_shell = true). This change was applied globally in https://github.com/openai/codex/blob/a2c86e5d8830006cb30c9367d70f4f84ef3bb6cc/codex-rs/core/src/tools/handlers/shell.rs#L47 Regardless of whether the snapshot feature is enabled or disabled.
2. The Snapshotting (Disabled by Default): The actual capturing of the environment and rewriting of commands to use that capture.

While snapshots bypass the Codex-imposed Seatbelt sandbox (applied via sandbox-exec), they cannot escape the OS-level App Sandbox that the main Codex process runs in. Any child process spawned by Codex inherits this OS sandbox.

Flow when shell_snapshot is DISABLED (Default):

https://github.com/openai/codex/blob/a2c86e5d8830006cb30c9367d70f4f84ef3bb6cc/codex-rs/core/src/features.rs#L360

1. Codex runs the user command as a login shell (zsh -lc) inside the sandbox.
2. This triggers .zprofile, which runs brew shellenv --(which on older installs runs)--> ps
3. The App Sandbox blocks ps
4. Crashs command.

Flow when shell_snapshot is ENABLED

1. To create a snapshot, Codex runs a login shell (zsh -lc) to capture the environment.
2. This process runs inside the inherited App Sandbox.
3. The brew shellenv runs ps, which is blocked by the App Sandbox.
4. Snapshot creation fails.
5. Because it failed, Codex falls back to the default behavior: running the user command as a login shell.
6. Crashs command.

To reproduce on modern Homebrew version:

1. Add a suid executable to one of the loaded evironments, for example ~/.zprofile
2. Run codex and ask it to run a command:

<img width="1510" height="695" alt="Image" src="https://github.com/user-attachments/assets/36fec63c-0d80-4bb1-8db0-7c315ea39eed" />

To put it simply:

1. Constraint: Sandboxed apps (like Codex) cannot run SUID binaries (like ps).
2. Trigger: Old Homebrew versions run ps in their shellenv script (called by .zprofile).
3. Regression: We recently changed the default to force all shells to be login shells (-lc). This forces .zprofile to run for every command, exposing this crash to everyone with that setup.

Enabling shell_snapshot doesn't fix it because the snapshot creation process itself runs a login shell inside the sandbox, so it hits the same crash, fails, and falls back to the broken default behavior.

I am happy to discuss this over Zoom if needed.

Shell initialization warning causes unnecessary token consumption in automated/programmatic usage

I'm building thinkon (a thinking orchestration framework) that uses Codex CLI as an executor via codex exec --json --full-auto.

The recurring /bin/ps: Operation not permitted warning from Homebrew's shellenv.sh causes significant issues in programmatic usage:

Impact

1. Token waste: The LLM sees these warnings and spends reasoning tokens on them:

``json
{"type":"reasoning","text":"**Noting permission error but continuing**\n\nThe shell output shows a permission error..."}
``

1. Output pollution: Warning text gets mixed with actual command output:

``
Hello, Thinkon Do!/opt/homebrew/Library/Homebrew/cmd/shellenv.sh: line 18: /bin/ps: Operation not permitted
``

1. Inconsistent UX: Users with Homebrew see warnings; users without don't.

Token consumption evidence

For a trivial task (create a single text file):

• Input tokens: 31,596 (with 12,160 cached)
• Output tokens: 480
• Warning appeared 6 times in a single session

Reproduction

codex exec --json --full-auto -C /tmp/test --skip-git-repo-check - <<'EOF'
Create a file hello.txt with content "Hello World"
EOF

Environment

• macOS (Darwin 25.2.0, arm64)
• Codex CLI installed via npm
• Homebrew installed at /opt/homebrew
• Shell: zsh with default Homebrew initialization in .zprofile

Root cause

Codex uses /bin/zsh -lc (login shell) for command execution, which loads full shell initialization including Homebrew's shellenv.sh. The sandbox blocks /bin/ps which shellenv.sh calls.

Suggested solutions

1. Preferred: Use non-login shell (/bin/zsh -c) when possible, or provide an option to disable login shell
2. Alternative: Filter known harmless initialization warnings from command output before sending to LLM
3. Minimal: Document this as a known issue with the .zprofile workaround

Workaround (user-side)

Modify ~/.zprofile:

# Only run brew shellenv in interactive shells
if [[ $- == *i* ]]; then
  eval "$(brew shellenv)"
fi

But this workaround requires users to modify their system config, which breaks the expectation that "any machine with working Codex should just work."

@lexobe, you might want to try the experimental "shell snapshot" feature. Use the /experimental slash command to enable it.

This bug report has received no upvotes or new posts in over two months. We are still tracking other bug reports related to permission errors, but I think this one has been addressed, so I'm going to close it.