macOS: Codex CLI update leaves existing Terminal process chains unable to access Desktop (TCC)

Summary

After updating the globally installed Codex CLI on macOS, existing Terminal/Codex process chains lose access to ~/Desktop with Operation not permitted, even though the relevant macOS TCC entries still show as allowed.

This has happened repeatedly after Codex updates on this machine. The latest occurrence was immediately after updating to @openai/codex / codex-cli 0.149.1.

The failure is specific to Desktop TCC, not normal Unix permissions or the Codex workspace sandbox:

• ls ~/Desktop fails.
• ls ~/Downloads still works.
• TCC rows for Terminal, /bin/zsh, /bin/ls, tmux, and the native Codex executable remain authorized.
• Opening another window inside the already-running Terminal instance still fails.
• Launching a genuinely new Terminal.app instance with open -n immediately restores Desktop access without changing file permissions.

The 0.149.1 npm native executable also fails strict code-signature verification on this macOS version. I cannot prove that this is the TCC root cause, but it makes the release-signing issue in #37725 directly relevant.

Environment

• macOS 26.5.2 (25F84)
• Apple Silicon / arm64
• Terminal.app + zsh
• Codex CLI 0.149.1
• Install method: global npm package (@openai/codex)
• Native executable:

/opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin/codex

Steps to reproduce

1. Grant Terminal and the Codex CLI process chain access to Desktop / Full Disk Access.
2. Start long-running Terminal and Codex sessions and confirm ls ~/Desktop works.
3. Update the global Codex package while those process chains exist:

``sh
npm install -g @openai/codex@latest
``

1. From an existing Terminal/Codex process chain, run:

``sh
/bin/ls "$HOME/Desktop"
``

1. Open a normal new window from the existing Terminal.app process and repeat the command.
2. Launch a separate Terminal.app instance and repeat:

``sh
open -n -b com.apple.Terminal /path/to/a/zsh-command-file.command
``

Actual behavior

Existing process chain and normal new Terminal window:

ls: /Users/<user>/Desktop: Operation not permitted

Python fails identically:

PermissionError: [Errno 1] Operation not permitted: '/Users/<user>/Desktop'

~/Downloads remains readable.

The relevant TCC rows still report auth_value=2 (allowed), including:

kTCCServiceSystemPolicyDesktopFolder | /bin/ls | allowed
kTCCServiceSystemPolicyDesktopFolder | /bin/zsh | allowed
kTCCServiceSystemPolicyDesktopFolder | /opt/homebrew/bin/tmux | allowed
kTCCServiceSystemPolicyDesktopFolder | .../aarch64-apple-darwin/bin/codex | allowed
kTCCServiceSystemPolicyDesktopFolder | com.apple.Terminal | allowed
kTCCServiceSystemPolicyAllFiles      | com.apple.Terminal | allowed

A genuinely new Terminal.app instance can immediately list Desktop. A new Terminal-owned tmux server also works. Therefore the already-running responsible process chain appears to retain stale or invalid TCC attribution after the Codex executable is replaced.

Code-signature evidence for 0.149.1

On the exact installed npm executable:

$ codesign --verify --strict --verbose=4 <native-codex-binary>
<native-codex-binary>: invalid signature (code or signature have been modified)
In architecture: arm64

Metadata:

Identifier=codex
TeamIdentifier=2DC432GLL2
CDHash=2dc305c9661e74a6f38c37bf8eebdae89c37f6e8
SHA-256=f0d8762236594359b60cfbe17f4c7e945a3ce8d1c91e74778838c968d250fb6c

This may be the macOS 26 verifier/toolchain incompatibility discussed in #37725 rather than local corruption. Either way, the invalid signature persists in 0.149.1 and coincides with a real TCC access regression after update.

Expected behavior

• Updating Codex should not invalidate previously granted Desktop access for the active CLI/Terminal process chain.
• Official macOS release binaries should pass strict code-signature verification on the current macOS release.
• If macOS necessarily requires a fresh responsible process after an update, the updater should detect this and clearly prompt for a safe relaunch instead of leaving existing sessions with unexplained Operation not permitted errors.
• The recovery flow should not require quitting all live Terminal windows and disrupting unrelated long-running work.

Workaround

Launching a separate Terminal instance works:

open -n -b com.apple.Terminal /path/to/a/zsh-command-file.command

Merely choosing New Window in the already-running Terminal.app instance does not work because it reuses the stale app process.

Related issues

• #37725 — the closest match: invalid strict code signature in the macOS arm64 CLI release; reproduced here on 0.149.1 with TCC impact.
• #34083 — Codex helpers intermittently lose protected-volume permissions despite Full Disk Access.
• #26185 — macOS permissions do not persist reliably across Codex sessions/restarts, although that report concerns Computer Use permissions.
• #21228 — separate TCC attribution/prompt failure for child CLIs launched by Codex Desktop.

No credentials, tokens, private filenames, or private file contents are included in this report.