macOS standalone: apply_patch fs helper re-exec through current symlink fails with EPERM

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

ChatGPT subscription

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Apple Silicon macOS 26.6.1 (Darwin 25.6.0 arm64)

What terminal emulator and version are you using (if applicable)?

Ghostty 1.3.1

Codex doctor report

The standalone installation was removed after diagnosis, so the full JSON report is no longer available. Before removal, the redacted summary reported:

Codex Doctor v0.147.0 · macos-aarch64
18 ok | 0 warn | 0 fail ok

What issue are you seeing?

With the official standalone installation, apply_patch cannot update or delete an existing file under the normal restricted/workspace-write sandbox. Its filesystem helper tries to re-execute Codex through an installer-managed symlink and macOS Seatbelt rejects the exec with status 71:

apply_patch verification failed: Failed to read file to update <workspace>/file:
fs sandbox helper failed with status exit status: 71:
sandbox-exec: execvp() of '<home>/.codex/packages/standalone/current/codex' failed: Operation not permitted

The managed paths were:

<home>/.local/bin/codex
  -> <home>/.codex/packages/standalone/current/bin/codex

<home>/.codex/packages/standalone/current
  -> <home>/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin

<home>/.codex/packages/standalone/current/codex
  -> bin/codex

When the persistent remote-control daemon was running, errors named standalone/current/codex. After remote control was disabled and a fresh local CLI session was started, errors named <home>/.local/bin/codex. Disabling remote control changed the visible executable path but did not fix the failure.

Creating a new file could succeed, while the update/delete verification path failed before reading the existing file.

The binary itself was healthy:

• Direct execution outside Seatbelt returned codex-cli 0.147.0.
• codesign showed a valid Developer ID signature from OpenAI OpCo, LLC.
• The binary had no quarantine attribute.
• Ownership and executable mode were normal.

After uninstalling the standalone package and installing the Homebrew cask at the same 0.147.0 version, an identical apply_patch create/update/delete smoke test passed completely under workspace-write.

What steps can reproduce the bug?

1. On Apple Silicon macOS, install the managed standalone package:

``sh
curl -fsSL https://chatgpt.com/codex/install.sh | sh
``

1. Start Codex through <home>/.local/bin/codex in a repository using the normal restricted/workspace-write sandbox.
2. Ask Codex to update or delete an existing file with apply_patch.
3. Observe the filesystem-helper sandbox-exec ... Operation not permitted failure shown above.

The failure was also isolated below apply_patch:

• Launching the standalone binary directly outside the sandbox succeeded.
• Launching standalone/current/codex inside a restricted codex sandbox profile failed with status 71, even after granting read access to the visible current directory and resolved release bin directory.
• Launching the fully resolved releases/0.147.0-aarch64-apple-darwin/bin/codex path with the resolved release package readable succeeded and printed codex-cli 0.147.0.

What is the expected behavior?

apply_patch should create, update, and delete files inside the declared writable workspace when Codex is installed with the official standalone installer, as it does with the Homebrew cask.

The filesystem helper should re-execute the active standalone binary without requiring danger-full-access.

Additional information

The relevant flow appears to be:

• codex-rs/exec-server/src/runtime_paths.rs: ExecServerRuntimePaths makes the configured executable absolute but does not resolve its symlink chain.
• codex-rs/exec-server/src/fs_sandbox.rs: the filesystem helper launches runtime_paths.codex_self_exe and derives helper read roots from that path.

Inference: resolving the executable to its real release path for helper execution, and granting the resolved standalone package/runtime root in the generated Seatbelt profile, should fix the mismatch. A macOS regression test should use the installer layout (.local/bin/codex -> standalone/current/bin/codex, with current pointing to a versioned release).

This is analogous to the Windows standalone junction/helper lookup problem in #30829, but it is a distinct macOS Seatbelt filesystem-helper re-exec failure.

codex doctor could also include a sandboxed filesystem-helper smoke test; it reported all checks healthy while existing-file apply_patch operations failed.