Codex CLI v0.120.0 (Rust) hangs at _dyld_start on macOS 26.4.1 Tahoe — Gatekeeper/AppleSystemPolicy blocks Homebrew Cask binary

[g-taki]

Update (2026-04-12): Original diagnosis was incorrect — the issue is not about code signing format but about missing Apple notarization + macOS 26's persistent quarantine database. Not version-specific (both v0.119.0 and v0.120.0 work when downloaded directly). See my follow-up comment for revised root cause and fix.

What version of Codex is running?

codex-cli 0.120.0 (Rust rewrite, installed via Homebrew Cask)

What subscription do you have?

Plus

Which model were you using?

N/A — binary never launches

What platform is your computer?

macOS 26.4.1 Tahoe (Build 25E253), Mac mini, Apple Silicon

What issue are you seeing?

The Codex CLI binary installed via brew install --cask codex hangs indefinitely on launch. The process gets stuck at _dyld_start — the dynamic linker never loads a single library. No output, no error, no Gatekeeper dialog (accessed via SSH).

Diagnosis:

• sample shows 100% of samples stuck at _dyld_start (in dyld) + 0
• DYLD_PRINT_LIBRARIES=1 produces zero output — no libraries loaded
• spctl --assess --type execute returns: rejected (the code is valid but does not seem to be an app)
• com.apple.provenance xattr is present (SIP-protected, cannot be removed)
• The binary is validly signed but macOS AppleSystemPolicy silently kills it before dyld completes

Workaround:

Copying the binary to a new location strips com.apple.provenance, then ad-hoc re-signing makes it work:

cp /opt/homebrew/Caskroom/codex/0.120.0/codex-aarch64-apple-darwin /tmp/codex-clean
codesign --force --sign - /tmp/codex-clean
/tmp/codex-clean --version  # works: codex-cli 0.120.0

The original binary at the Caskroom path never works regardless of xattr -d com.apple.quarantine or codesign --force -s - in place.

What steps can reproduce the bug?

1. brew install --cask codex on macOS 26.4.1 Tahoe (25E253)
2. codex --help — hangs indefinitely, no output
3. Over SSH, no Gatekeeper dialog appears; the process is silently blocked

What is the expected behavior?

The binary should launch normally after Homebrew installation.

Additional information

• This is the same class of issue as macOS Sequoia 15.7.1 quarantine kills codex binary until xattr is cleared #5787 (quarantine/provenance on older versions) and is related to Codex app can enter an AppleSystemPolicy retry loop and drive syspolicyd/trustd high CPU on macOS #17225 / Codex Desktop triggers sustained syspolicyd/trustd CPU spikes on macOS #16767 (AppleSystemPolicy blocking Codex processes).
• EXC_BREAKPOINT (SIGTRAP) crash on launch — macOS 26.4.1 (25E253), M2, Electron 40 #17339 reports a similar dyld start crash on the same OS build (25E253) for the Desktop app.
• Other tools have hit the same macOS 26 Gatekeeper enforcement: [BUG] Claude CLI killed by kernel on macOS 26 beta - obsolete code signature format anthropics/claude-code#20407, UV Python SIGKILL Issue on macOS astral-sh/uv#16726 (fixed via post-build ad-hoc codesigning in CI).
• The uv project resolved this by adding codesign --force -s - to their release pipeline (PR fix: add ad-hoc code signing for Python binaries on macOS astral-sh/uv#17123). A similar fix in the Codex Rust build CI would resolve this permanently.

[etraut-openai]

Thanks for the bug report. Has this worked for you in previous version? I'm trying to determine if this was a regression in 0.120.0 specifically. If you install 0.119.0, does that work for you?

[g-taki]

Thanks for looking into this, @etraut-openai.

I did further testing today and the results change the diagnosis significantly:

Version testing:

• v0.119.0 downloaded directly from GitHub releases → works
• v0.120.0 downloaded directly from GitHub releases → also works
• v0.120.0 installed via brew install --cask codex → hangs

So this is not a regression between versions. Both work fine when downloaded directly.

Root cause (revised):

The issue is the interaction between Homebrew Cask and macOS 26's Gatekeeper:

1. Homebrew Cask downloads the tarball and macOS sets com.apple.quarantine on the extracted binary
2. spctl --assess --type execute returns rejected — the binary is properly signed (Developer ID) but not notarized
3. On macOS 26, the kernel blocks execution of quarantined + unnotarized binaries before dyld even starts
4. Crucially, xattr -d com.apple.quarantine does not fix it — macOS 26 persists the quarantine state in a system-level database (not just the xattr)
5. Copying the binary to a new path (new inode) bypasses the quarantine DB and works immediately — no re-signing needed

# This works without any re-signing:
cp /opt/homebrew/Caskroom/codex/0.120.0/codex-aarch64-apple-darwin /tmp/codex
/tmp/codex --version  # codex-cli 0.120.0

Suggested fix:

Submit the release binaries to Apple's notary service (xcrun notarytool submit). Once notarized, Gatekeeper will allow execution even with quarantine. This would fix Homebrew Cask installs on macOS 26 permanently.

Workaround for users:

Use the official install script instead of Homebrew Cask — it downloads directly to ~/.local/bin/ without triggering Homebrew's quarantine:

curl -fsSL https://github.com/openai/codex/releases/download/rust-v0.120.0/install.sh | sh

I'll also correct my original issue description — the earlier hypothesis about "obsolete code signature format" was wrong. The signing is fine; the missing piece is notarization.

[iwinux]

[iwinux]

Interesting. I re-install it via Homebrew today (the same v0.120.0) and it runs without error. Assuming you haven't silently replaced the binary, it might be a glitch at the Apple side?

BTW: you should warn users NEVER run xattr -d com.apple.quarantine when such issue happens :)

[cuber]

Confirming this still reproduces on codex-cli 0.122.0 / macOS 26 Tahoe (Darwin 25.3) / Apple Silicon, installed via brew install --cask codex.

One correction to the workaround: cp does not strip com.apple.provenance on my system — the xattr is still present on the copied file at /tmp. What actually fixes the hang is the ad-hoc resign alone:

cp /opt/homebrew/Caskroom/codex/0.122.0/codex-aarch64-apple-darwin /tmp/codex-clean
codesign --force --sign - /tmp/codex-clean
mv /tmp/codex-clean /opt/homebrew/Caskroom/codex/0.122.0/codex-aarch64-apple-darwin

After this, codex --version works at the original Caskroom path even though com.apple.provenance is still on the inode. So the trigger seems to be the combination of the original signature + provenance, not the xattr's presence.

[iwinux]

Here comes the the weird part: it's not 100% reproducible, even with the same macOS version + Codex CLI version:

• Device A: "could not verify ..." error
• Device B: runs just fine
• codex binary installed via brew install --cask codex has the same SHA256.