danger-full-access sandbox blocks Metal/GPU IOKit access, crashing MLX on macOS

[YuancFeng]

Environment

• codex-cli 0.118.0
• macOS 26.4 (25E246), Apple M4 Pro
• Python 3.14.2, MLX 0.31.0
• Config: sandbox = "danger-full-access", bypass-sandbox = true, CLI alias with --dangerously-bypass-approvals-and-sandbox

Description

When Codex spawns a Python subprocess that imports mlx.core (e.g., for local voice transcription via mlx-whisper), the process crashes with SIGABRT due to an uncaught NSRangeException:

*** -[__NSArray0 objectAtIndex:]: index 0 beyond bounds for empty array

The crash occurs in mlx::core::metal::Device::Device() during Metal GPU device enumeration. Metal's MTLCopyAllDevices() returns an empty array because the Seatbelt sandbox profile restricts IOKit access.

Root Cause

The Seatbelt profile compiled into the Codex binary only allows:

(allow iokit-open
  (iokit-registry-entry-class "RootDomainUserClient"))

This applies even in danger-full-access mode. Metal GPU enumeration requires IOKit access to GPU driver classes (e.g., AGXMetalG16X on Apple Silicon), which is not permitted.

Reproduction

Minimal reproduction without Codex, confirming the Seatbelt IOKit restriction is the root cause:

# This crashes with the identical NSRangeException:
sandbox-exec -p '(version 1)(allow default)(deny iokit-open)' \
  python3 -c "import mlx.core"

# This works fine (full IOKit access):
sandbox-exec -p '(version 1)(allow default)' \
  python3 -c "import mlx.core; print(mlx.core.default_device())"

Expected Behavior

danger-full-access mode (and --dangerously-bypass-approvals-and-sandbox) should grant unrestricted IOKit access, allowing Metal/GPU operations in child processes.

Suggested Fix

Add an unrestricted IOKit rule to the danger-full-access sandbox template:

(allow iokit-open)

Or, if a scoped approach is preferred:

(allow iokit-open
  (iokit-registry-entry-class "RootDomainUserClient")
  (iokit-registry-entry-class "AGXDeviceUserClient")
  (iokit-registry-entry-class "IOGPUDeviceUserClient"))

Crash Report (abbreviated)

Process:     Python
Parent:      codex
Exception:   EXC_CRASH (SIGABRT)
Reason:      *** -[__NSArray0 objectAtIndex:]: index 0 beyond bounds for empty array

Crash thread backtrace:
  CoreFoundation  -[__NSArray0 objectAtIndex:]
  libmlx.dylib    mlx::core::metal::Device::Device()
  libmlx.dylib    mlx::core::metal::device(mlx::core::Device)
  libmlx.dylib    mlx::core::metal::MetalAllocator::MetalAllocator()
  libmlx.dylib    mlx::core::allocator::allocator()
  libmlx.dylib    mlx::core::random::key(unsigned long long)
  core.cpython-314-darwin.so  [module init]

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #Metal devices are invisible inside sandbox on Apple Silicon, which causes false MLX failures #16931

Powered by Codex Action

[YuancFeng]

Thanks for flagging. #16931 describes the same symptom (Metal invisible inside sandbox), but this issue adds the root cause analysis: the Seatbelt profile only allows iokit-open for RootDomainUserClient, which blocks GPU driver classes needed by Metal. I also include a minimal sandbox-exec reproduction and a concrete fix suggestion.

Happy to close this if #16931 gets the fix merged, but keeping it open for now since it has more actionable detail.

[m13v]

the IOKit restriction goes deeper than just Metal device enumeration. CoreML model compilation (which WhisperKit, mlx-whisper, and most on-device inference frameworks trigger) also needs IOKit access to detect the Neural Engine and determine which execution providers to use. without it, the framework falls back to CPU-only inference, which is 5-10x slower than ANE on Apple Silicon.

we hit a related issue building local voice transcription. even after granting IOKit access, CoreML model compilation on first run spawns a background coremlcompiler process that itself needs IOKit and filesystem access to write the compiled .mlmodelc cache to the container's caches directory. if the sandbox restricts that write, you get a silent fallback to recompilation on every inference call, which pegs one core at 100% indefinitely.

the sandbox-exec reproduction is helpful. for anyone running into this before an upstream fix ships, you can pre-compile the MLX/CoreML model outside the sandbox and point the framework at the cached compiled version. this skips the IOKit-dependent compilation step entirely, though you still need the Metal device enumeration fix for actual GPU inference.

[m13v]

our on-device transcription service that handles WhisperKit CoreML model compilation caching, the ANE vs CPU fallback logic, and the pre-compiled model path approach I mentioned: https://github.com/m13v/fazm/blob/main/Desktop/Sources/TranscriptionService.swift

[viyatb-oai]

@YuancFeng thanks for reporting this! if you are in danger-full-access and approval_policy=never, Codex should not execute code under seatbelt. It completely bypasses sandbox construction and seatbelt should not be invoked. Can you share your config.toml? do you have any other settings enforced via /etc/codex/requirements.toml?

[YuancFeng]

@viyatb-oai Relevant config only:

approval_policy = "never"
bypass-approvals = true
bypass-sandbox = true
sandbox = "danger-full-access"

There is no /etc/codex/requirements.toml on this machine.

So the remaining question seems to be why a Codex-spawned Python child is still running under Seatbelt in this mode. If useful, I can provide:

1. the exact Codex command or workflow step that spawns the failing child,
2. sandbox denial or trace logs from that child,
3. the full child crash report,
4. a sysdiagnose privately rather than on the public issue.

[viyatb-oai]

please do! 1-3 should be enough.