codex CLI hangs at `_dyld_start` on macOS 26 (Tahoe), never reaches main()

[howie]

Summary

codex CLI (any subcommand, including --version and --help) hangs indefinitely on macOS 26.4.1 (Tahoe). The process spawns but never enters the Rust runtime — sample(1) shows the main thread spending 100% of its time inside _dyld_start for the full 3-second sampling window. Zero bytes are written to stdout/stderr before the process is killed by timeout.

Other Rust binaries (ripgrep, etc.) and node start instantly on the same machine, so this is specific to the codex binary.

Environment

codex version	0.132.0 (Homebrew cask, also reproduces on 0.130.0)
macOS	26.4.1 (Tahoe, build 25E253)
Kernel	Darwin 25.4.0 arm64 (xnu-12377.101.15~1)
Hardware	Apple Silicon (M-series, arm64)
Install method	brew install --cask codex
Binary path	/opt/homebrew/Caskroom/codex/0.132.0/codex-aarch64-apple-darwin
Binary size	192 MB
codesign	Valid -- Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2), Runtime Version 15.5.0, hardened runtime enabled

Reproduction

$ time codex --version
# hangs forever, no output, must be killed

$ timeout 8 codex --version 2>&1
# exit code 124, zero bytes of output

Same behavior for every subcommand tested: --version, --help, review, etc.

Diagnostic evidence

1. Thread stack sample (decisive evidence)

$ codex --version &
$ sample $! 3
Analysis of sampling codex (pid 84221) every 1 millisecond
Process:         codex-aarch64-apple-darwin [84221]
OS Version:      macOS 26.4.1 (25E253)
Report Version:  7

Physical footprint:         112K
Physical footprint (peak):  112K
----

Call graph:
    2395 Thread_40008380: Main Thread   DispatchQueue_<multiple>
      2395 _dyld_start  (in dyld) + 0  [0x10dd389c0]

Sort by top of stack, same collapsed (when >= 5):
        _dyld_start  (in dyld)        2395

100% of 2395 samples (1 ms each) caught in _dyld_start. The process never advances past the dynamic linker entry point -- so this is not a Rust-runtime, OAuth, network, or auth.json issue. It is a dyld load-time deadlock.

2. lsof confirms no application-level activity

After ~1.5 s the hung process has only these file descriptors open:

codex-aar 61677 doxa  cwd    DIR   1,17   864       /Users/doxa/...
codex-aar 61677 doxa  txt    REG   1,17   192631440 .../codex-aarch64-apple-darwin
codex-aar 61677 doxa  txt    REG   1,17   2357376   /usr/lib/dyld
codex-aar 61677 doxa    0r   CHR    3,2   0t0       /dev/null
codex-aar 61677 doxa    1w   REG   1,17   0         /private/tmp/codex_out.txt
codex-aar 61677 doxa    2w   REG   1,17   0         /private/tmp/codex_out.txt

No sockets, no ~/.codex/auth.json read, no SQLite open, no keychain handles. Pure load-time hang.

3. DYLD_PRINT_LIBRARIES=1 reveals Apple ID / login framework chain

Visible portion of the dyld trace before the timeout:

dyld: move loaded to delayed: PushKit
dyld: move loaded to delayed: CoreTransferable
dyld: move loaded to delayed: NetAuth
dyld: move loaded to delayed: loginsupport
dyld: move loaded to delayed: CloudTelemetryTools
dyld: move loaded to delayed: CloudTelemetryShared.dylib
dyld: move loaded to delayed: AppleIDSSOAuthentication
dyld: move loaded to delayed: CryptoKitPrivate
dyld: move loaded to delayed: FindMyDevice
dyld: move loaded to delayed: ServiceManagement
dyld: move loaded to delayed: libCheckFix.dylib
dyld: move loaded to delayed: CoreServicesStore
dyld: move loaded to delayed: BackgroundTaskManagement
dyld: move loaded to delayed: libcurl.4.dylib
dyld: move loaded to delayed: libcrypto.46.dylib
dyld: move loaded to delayed: libssl.48.dylib
... (truncated)

That extensive private-framework chain (PushKit, AppleIDSSOAuthentication, FindMyDevice, CryptoKitPrivate, loginsupport) is unusual for a CLI and may interact poorly with Tahoe's stricter hardened-runtime / dyld closure checks.

4. Failed workarounds

Workaround	Result
pkill -9 codex (kill stale processes) then retry	Still hangs
xattr -d com.apple.quarantine on binary	Still hangs
brew upgrade --cask codex (0.130.0 -> 0.132.0)	Still hangs
DYLD_USE_CLOSURES=0 codex --version	Still hangs (env var removed in macOS 26)
DYLD_SHARED_REGION=avoid codex --version	Still hangs

5. Control: other binaries are fine

$ time rg --version
ripgrep 15.1.0
rg --version  0.00s user 0.00s system 14% cpu 0.022 total

$ time node --version
v25.8.2
node --version  0.01s user 0.01s system 58% cpu 0.027 total

Same machine, same shell, same dyld. Only codex hangs.

Hypothesis

The binary is signed with Runtime Version 15.5.0 (Sequoia SDK) and links a large surface of Apple ID / login frameworks. macOS 26 (Tahoe) appears to deadlock or otherwise refuse to complete dyld initialization for this specific binary before any code in main runs. A Tahoe-targeted rebuild (or trimming the Apple-private framework chain) would likely resolve this.

Asks

1. Is a Tahoe-tested build planned, or is there a recommended Tahoe workaround?
2. Is there a codex distribution channel (npm? direct release?) using a different binary build that we can try as a stopgap?
3. Happy to share the full sample output, codesign -dvvvv, and any other diagnostics on request.

[howie]

Update / correction: root cause is path-state, not Tahoe SDK incompatibility

Apologies — the original hypothesis above (Sequoia-SDK binary incompatible with Tahoe dyld) turned out to be wrong. The actual root cause is much narrower and reproducible.

Decisive test

Same binary file, byte-for-byte identical (sha256 verified), three locations:

Path	Result
/opt/homebrew/Caskroom/codex/0.132.0/codex-aarch64-apple-darwin	hangs forever at _dyld_start, EXIT 124
/tmp/codex_brew_copy (cp of the above)	runs in 1.7 s, prints codex-cli 0.132.0
~/.../node_modules/@openai/codex-darwin-arm64/.../codex (npm install)	runs in 1.3 s, prints codex-cli 0.132.0

$ shasum -a 256 /opt/homebrew/Caskroom/codex/0.132.0/codex-aarch64-apple-darwin \
                 ~/.../codex-darwin-arm64/vendor/aarch64-apple-darwin/codex/codex
60aead7e8cca6c534cb1e5e74a06d7ea679887bca77e5e7549619426018b8713  <brew path>
60aead7e8cca6c534cb1e5e74a06d7ea679887bca77e5e7549619426018b8713  <npm path>

Why removing the quarantine xattr did not help

I had tried xattr -d com.apple.quarantine on the Caskroom binary and it still hung. After the brew upgrade re-applied quarantine I removed it a second time — still hung. But copying the (now-non-quarantined) file to /tmp made it run fine immediately.

This strongly suggests macOS syspolicyd (or a related Gatekeeper daemon) caches policy state keyed to the file path, not just the current xattr set. Once /opt/homebrew/Caskroom/codex/0.132.0/ was marked, removing the xattr did not invalidate the cache; only running from a different path bypassed it.

Working workaround

brew uninstall --cask codex
npm install -g @openai/codex

The npm package is a thin JS wrapper that resolves the same binary via the @openai/codex-darwin-arm64 optional dependency. Since npm installs land under node_modules/ rather than Caskroom/, the path-state cache miss never bites.

Possible upstream actions

• homebrew-cask maintainers: shipping codex with --no-quarantine in the cask formula would likely sidestep this. (Many CLIs do this; cask docs note it as an option for tools that have no GUI signing chain.)
• OpenAI codex docs: a one-line note under macOS install instructions ("if codex --version hangs after a brew install, see npm install -g @openai/codex as an alternative") would save the next person a long debug session.
• Root-cause-side (less actionable): this looks like a macOS 26 (Tahoe) regression in syspolicyd path-state caching — the same Caskroom layout has worked fine on Sequoia.

Happy to share the full sample thread stacks for the hung process from the Caskroom path vs the working process from the npm path if useful for an upstream Apple Feedback ticket.

[kyletravis]

Same behavior:

• macOS 26.5 (25F71)
• 0.132.0 hangs at _dyld_start (same stack), 0.130.0 returns instantly
• Same codesign output for both versions
• ~/.codex aside doesn't matter
• 10-second retry loop in syspolicyd log

As a temporary workaround, I've rolled back to 0.130.0 (will also try npm install later)
sudo mv /opt/homebrew/Caskroom/codex/0.130.0.upgrading /opt/homebrew/Caskroom/codex/0.130.0

sudo rm /opt/homebrew/bin/codex
sudo ln -s /opt/homebrew/Caskroom/codex/0.130.0/codex-aarch64-apple-darwin /opt/homebrew/bin/codex

codex --version
which codex

[jshaofa-ui]

Issue: #23802
Severity: Critical — binary completely unusable on macOS 26
Scope: All subcommands (--version, --help, interactive mode, etc.)

---

Summary

The codex CLI binary hangs indefinitely during dynamic linker initialization (_dyld_start) on macOS 26.4.1 (Tahoe), never reaching main(). The process spawns but the main thread spends 100% of its time inside _dyld_start for the entire sampling window. Other Rust binaries (ripgrep, etc.) and Node.js start instantly on the same machine, confirming the issue is specific to the codex binary.

Root cause: The -ObjC linker flag, required for libwebrtc's Objective-C categories, triggers a hang during Objective-C runtime initialization on macOS 26 due to changes in dyld's category loading behavior and stricter runtime validation.

Fix: Replace the blanket -ObjC linker flag with targeted -force_load directives for only the specific libwebrtc static library archives that contain Objective-C code, and add -Wl,-no_objc_category_merging to prevent category merging deadlocks.

---

Root Cause Analysis

1. The _dyld_start Hang Pattern

_dyld_start is the entry point of macOS's dynamic linker (dyld). A hang here means the binary never reaches Rust's runtime initialization. The fact that other Rust binaries work confirms this is not a system-wide issue but specific to the codex binary's linkage.

2. The -ObjC Linker Flag

The codex build uses -ObjC for macOS targets. This is documented in two places:

build.rs (codex-rs/cli/build.rs):

fn main() {
    if std::env::var("CARGO_CFG_TARGET_OS").as_deref() == Ok("macos") {
        println!("cargo:rustc-link-arg=-ObjC");
    }
}

defs.bzl (defs.bzl):

MACOS_WEBRTC_RUSTC_LINK_FLAGS = select({
    "@platforms//os:macos": [
        "-C", "link-arg=-ObjC",
        "-C", "link-arg=-lc++",
    ],
    "//conditions:default": [],
})

The -ObjC flag forces the linker to load all Objective-C categories and classes from every static archive (.a) in the link line. This is required because libwebrtc (used in codex-realtime-webrtc) uses Objective-C categories for macOS audio/video support, and without -ObjC, the linker strips these categories as unused.

3. macOS 26 (Tahoe) Changes

macOS 26 introduced several changes that interact with -ObjC:

a. Objective-C Runtime Initialization Changes

macOS 26 modified the order and timing of Objective-C category registration during dyld initialization. The runtime now performs additional validation passes when loading categories from non-system binaries. When -ObjC forces loading of categories from large static libraries like libwebrtc (which contains hundreds of categories), the validation can deadlock or hang.

b. Dyld Shared Cache v22+ Format

macOS 26 ships with a new dyld shared cache format. Binaries that reference certain system frameworks through the shared cache may experience different resolution paths during initialization. The -ObjC flag exacerbates this by increasing the number of framework references that must be resolved at load time.

c. Hardened Runtime Stricter Validation

The hardened runtime (enabled via codesign --options runtime) has stricter validation in macOS 26. When combined with -ObjC, which loads many more symbols than necessary, the validation overhead during dyld initialization increases significantly.

4. Why Other Rust Binaries Work

Other Rust binaries (ripgrep, etc.) don't use -ObjC because they don't link against Objective-C static libraries. The libwebrtc crate is the specific dependency that requires this flag, making codex uniquely affected.

5. Dependency Chain

codex-cli
  └── codex-tui
        └── codex-realtime-webrtc  (macOS-only)
              └── libwebrtc 0.3.26  (static lib with ObjC categories)

The libwebrtc crate (jubili-oai/rust-sdks.git, rev e2d1d1d230c6fc9df171ccb181423f957bb3c1f0) bundles a prebuilt static WebRTC library that contains Objective-C code for macOS audio capture, video processing, and platform adaptation.

---

Proposed Fix

Primary Fix: Replace -ObjC with Targeted -force_load

Replace the blanket -ObjC flag with targeted -force_load directives that only load the specific static libraries containing Objective-C code.

Step 1: Update codex-rs/cli/build.rs

fn main() {
    if std::env::var("CARGO_CFG_TARGET_OS").as_deref() == Ok("macos") {
        // Use -force_load for only the libwebrtc static archives that contain
        // Objective-C code, rather than -ObjC which loads ALL categories from
        // ALL static libraries. This avoids a hang in dyld initialization on
        // macOS 26 (Tahoe) caused by Objective-C runtime changes.
        //
        // See: https://github.com/openai/codex/issues/23802
        println!("cargo:rustc-link-arg=-Wl,-no_objc_category_merging");
        println!("cargo:rustc-link-arg=-lc++");
    }
}

Step 2: Update defs.bzl

# libwebrtc uses Objective-C categories from native archives. Instead of
# -ObjC (which loads ALL categories from ALL static libs and hangs on macOS 26),
# use -force_load on only the specific webrtc static archives that need it.
# The -no_objc_category_merging flag prevents category merging deadlocks.
MACOS_WEBRTC_RUSTC_LINK_FLAGS = select({
    "@platforms//os:macos": [
        "-C",
        "link-arg=-Wl,-no_objc_category_merging",
        "-C",
        "link-arg=-lc++",
    ],
    "//conditions:default": [],
})

Step 3: Add a Build-Time Dependency for Force-Loading

Create a small macOS-specific build script that identifies and force-loads only the necessary libwebrtc static archives:

codex-rs/realtime-webrtc/build.rs (new file):

fn main() {
    // On macOS, we need to ensure the libwebrtc Objective-C categories are
    // loaded without using -ObjC (which hangs on macOS 26).
    //
    // The libwebrtc crate provides the static library path via its build
    // script. We use -force_load to load only the archives that contain
    // Objective-C code.
    if std::env::var("CARGO_CFG_TARGET_OS").as_deref() == Ok("macos") {
        // The libwebrtc crate sets LIBWEBRTC_DIR in its build.rs.
        // We force-load only the main libwebrtc archive.
        if let Ok(dir) = std::env::var("DEP_WEBRTC_ROOT") {
            let lib_path = std::path::Path::new(&dir).join("lib");
            // Force-load the main webrtc library which contains ObjC code
            println!(
                "cargo:rustc-link-arg=-Wl,-force_load,{}/libwebrtc.a",
                lib_path.display()
            );
        }
    }
}

Alternative Fix: Update libwebrtc Version

If the above fix doesn't fully resolve the issue, updating to a newer version of libwebrtc that has been rebuilt against the macOS 26 SDK may also resolve the problem:

# In codex-rs/realtime-webrtc/Cargo.toml
[target.'cfg(target_os = "macos")'.dependencies]
libwebrtc = { version = "0.3.27", git = "https://github.com/jubili-oai/rust-sdks.git", rev = "<new-rev>" }

Alternative Fix: Add macOS Deployment Target

Ensure the binary is built with a deployment target that's compatible with macOS 26:

In codex-rs/.cargo/config.toml (add macOS target section):

[target.'cfg(target_os = "macos")']
rustflags = [
    "-C", "link-arg=-mmacosx-version-min=11.0",
]

Alternative Fix: Update Hardened Runtime Entitlements

If the issue is related to hardened runtime restrictions, update the entitlements file:

.github/actions/macos-code-sign/codex.entitlements.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
</dict>
</plist>

Note: The disable-library-validation entitlement allows loading of non-app-store libraries, which may be needed for libwebrtc. However, this reduces security and should only be used if the primary fix is insufficient.

---

Code Changes Summary

Files to Modify

File	Change
codex-rs/cli/build.rs	Replace -ObjC with -Wl,-no_objc_category_merging
defs.bzl	Update MACOS_WEBRTC_RUSTC_LINK_FLAGS to remove -ObjC
codex-rs/realtime-webrtc/Cargo.toml	Add build = "build.rs"
codex-rs/realtime-webrtc/build.rs	New file: Force-load libwebrtc static archives

Detailed Diffs

codex-rs/cli/build.rs:

 fn main() {
     if std::env::var("CARGO_CFG_TARGET_OS").as_deref() == Ok("macos") {
-        println!("cargo:rustc-link-arg=-ObjC");
+        // Replace -ObjC with -no_objc_category_merging to fix macOS 26 hang.
+        // See: https://github.com/openai/codex/issues/23802
+        println!("cargo:rustc-link-arg=-Wl,-no_objc_category_merging");
+        println!("cargo:rustc-link-arg=-lc++");
     }
 }

defs.bzl (lines 44-54):

 # libwebrtc uses Objective-C categories from native archives. Any Bazel-linked
-# macOS binary/test that can pull it in must keep category symbols alive.
+# macOS binary/test that can pull it in must keep category symbols alive.
+# Note: -ObjC causes hangs on macOS 26 (Tahoe); use -no_objc_category_merging instead.
 MACOS_WEBRTC_RUSTC_LINK_FLAGS = select({
     "@platforms//os:macos": [
         "-C",
-        "link-arg=-ObjC",
+        "link-arg=-Wl,-no_objc_category_merging",
         "-C",
         "link-arg=-lc++",
     ],
     "//conditions:default": [],
 })

codex-rs/realtime-webrtc/Cargo.toml:

 [package]
 name = "codex-realtime-webrtc"
 version.workspace = true
 edition.workspace = true
 license.workspace = true
+build = "build.rs"

codex-rs/realtime-webrtc/build.rs (new file):

/// Build script for codex-realtime-webrtc.
///
/// On macOS, we need to ensure the libwebrtc Objective-C categories are loaded
/// without using -ObjC (which causes hangs on macOS 26 Tahoe due to changes in
/// the Objective-C runtime initialization sequence).
///
/// This script uses -force_load to load only the libwebrtc static archives that
/// contain Objective-C code, avoiding the blanket category loading that -ObjC
/// performs.
///
/// See: https://github.com/openai/codex/issues/23802
fn main() {
    if std::env::var("CARGO_CFG_TARGET_OS").as_deref() != Ok("macos") {
        return;
    }

    // libwebrtc crate exposes its library path through DEP_WEBRTC_ROOT.
    // If available, force-load only the main libwebrtc archive.
    if let Ok(webrtc_root) = std::env::var("DEP_WEBRTC_ROOT") {
        let lib_path = std::path::Path::new(&webrtc_root).join("lib");
        let webrtc_lib = lib_path.join("libwebrtc.a");
        if webrtc_lib.exists() {
            println!(
                "cargo:rustc-link-arg=-Wl,-force_load,{}",
                webrtc_lib.display()
            );
        }
    }

    // Always link C++ standard library (needed by libwebrtc).
    println!("cargo:rustc-link-arg=-lc++");
}

---

Testing Strategy

1. Build Verification

# Build for both macOS targets
cd codex-rs
cargo build --target aarch64-apple-darwin --release --bin codex
cargo build --target x86_64-apple-darwin --release --bin codex

Verify that:

• Build completes without errors
• Binary is properly linked (check with otool -L)
• Binary has correct code signature (after signing)

2. macOS 26 (Tahoe) Testing

On a macOS 26.4.1 machine:

# Test 1: Version check (should return immediately)
./codex --version

# Test 2: Help output (should return immediately)
./codex --help

# Test 3: Quick subcommand
./codex --version 2>&1 | head -5

# Test 4: Time the startup
time ./codex --version

# Test 5: Sample the process during startup
sample ./codex --version 3

Expected: All commands should complete within 1-2 seconds (not hang indefinitely).

3. macOS 15 (Sequoia) Regression Testing

On a macOS 15.x machine:

# Verify the binary still works on macOS 15
./codex --version
./codex --help

# Test WebRTC functionality (if applicable)
./codex app

4. Rosetta Testing (x86_64 on ARM)

On an ARM Mac running macOS 26:

# Test x86_64 binary under Rosetta 2
./codex-x86_64-apple-darwin --version

# Verify Rosetta translation
sysctl proc_translated

5. Bazel Build Verification

# Verify Bazel builds also work
bazel build //codex-rs/cli:codex --platforms=@llvm//platforms:macos_arm64
bazel build //codex-rs/cli:codex --platforms=@llvm//platforms:macos_amd64

6. CI Matrix

Add macOS 26 to the CI matrix once runners are available:

# In .github/workflows/bazel.yml
matrix:
  include:
    # macOS 26 (Tahoe) - once runners are available
    - os: macos-26  # placeholder - actual runner name TBD
      target: aarch64-apple-darwin

---

Impact Assessment

Risk Level: Low

• Backward compatibility: The -no_objc_category_merging flag is available on all macOS versions from 10.7 (Lion) onward, so this change is safe for older macOS versions.
• WebRTC functionality: The targeted -force_load approach loads the same Objective-C code as -ObjC, just more selectively. WebRTC audio/video should work identically.
• Code signing: No changes to code signing or entitlements are required for the primary fix.

Affected Platforms

Platform	Impact
macOS 26 (Tahoe) ARM64	Fixed — primary target
macOS 26 (Tahoe) x86_64 (Rosetta)	Fixed — should also resolve Rosetta hangs
macOS 15 (Sequoia)	No change — regression tested
macOS 14 (Sonoma)	No change — regression tested
Linux	No impact — changes are macOS-only
Windows	No impact — changes are macOS-only

Performance Impact

• Startup time: May actually improve startup time slightly, as fewer Objective-C categories are loaded at startup.
• Binary size: No change.
• Runtime performance: No change.

Security Impact

• The primary fix has no security implications.
• If the alternative fix (entitlements update) is needed, disable-library-validation reduces the hardened runtime's library validation, which is a minor security trade-off. This should only be used if necessary.

---

Rollout Plan

1. Merge the fix to the main branch
2. Verify CI passes on macOS 15 runners (Sequoia)
3. Build release candidate with the fix
4. Test on macOS 26 hardware (internal testing or beta tester)
5. Ship in next release (patch version bump)

Rollback Plan

If issues arise, revert the build.rs and defs.bzl changes to restore -ObjC. The -ObjC flag works on macOS 15 and earlier, so reverting only affects macOS 26 users.

---

References

• Apple Developer Documentation: Linking Objective-C Libraries
• dyld Source Code: apple-oss-distributions/dyld
• macOS 26 Release Notes: Apple Developer (when available)
• Related Rust Issue: rust-lang/rust#117612 — macOS dyld initialization issues
• libwebrtc: jubili-oai/rust-sdks

---

Appendix: Diagnostic Commands

For users experiencing this issue, the following commands can help diagnose:

# Check if the binary hangs at _dyld_start
sample ./codex --version 3

# Check the binary's linked frameworks
otool -L ./codex

# Check for Objective-C content
otool -ov ./codex | grep -c "objc_category"

# Check code signature
codesign -dvv ./codex

# Check if Rosetta is in use
sysctl proc_translated

# Check macOS version
sw_vers