[Bug] iOS Simulator helper (claude-ios-sim) crash-loops on macOS 27 beta — uncaught NSException in Metal recordBinaryArchiveUsage via CoreImage

IPS Files.zip

Confirming the same crash loop on another machine, with one additional data point that narrows the cause to the helper's sandbox.

Environment

• Claude desktop app 1.24012.9 (macOS)
• macOS 27.0 beta, build 26A5388g, Apple Silicon (arm64)
• Xcode 26.6 (17F113)
• 23 claude-ios-sim crash reports in ~/Library/Logs/DiagnosticReports/Retired/, oldest 2026-07-25 — so this predates recent app updates

Same signature — SIGABRT, uncaught NSException (nil object in collection):

+[NSArray arrayWithObjects:count:]
__39-[_MTLDevice recordBinaryArchiveUsage:]_block_invoke  (dispatch_once)
-[_MTLBinaryArchive loadFromURL:error:]
+[CIKernelLibrary(Internal) internalBinaryArchiveWithName:device:]
CI::MetalContext::init
+[CIContext contextWithMTLDevice:options:]
FBSimulatorControl (frame capture)

Additional data point — unsandboxed CoreImage+Metal works fine on the same host. This minimal repro succeeds outside the helper:

import CoreImage
import Metal
let dev = MTLCreateSystemDefaultDevice()!
let ctx = CIContext(mtlDevice: dev)
let img = CIImage(color: .red).cropped(to: CGRect(x: 0, y: 0, width: 8, height: 8))
_ = ctx.createCGImage(img, from: img.extent)  // OK, no crash

So the Metal binary-archive load only fails inside the helper's seatbelt profile (Claude.app/Contents/Resources/claude-ios-sim.sb), which has no allowances for Metal shader-cache paths — consistent with the analysis in #80472. Likely the sandbox denial turns a path/archive lookup nil, and Metal's usage-recording puts that nil into an NSArray.

Also matches observed behavior precisely:

• Input injection (tap, text, swipe) works reliably the whole time — only screenshot/panel streaming (the CoreImage frame-conversion path) dies.
• From the panel UI this manifests as: click "Attach simulator" → panel briefly attaches → helper aborts on first frame → panel "glitches back" to the attach card. attach MCP calls report success right before the crash.

Possibly-duplicate reports of the same underlying bug: #80177, #80472, #82864, #81520.

Root cause confirmed and a one-rule fix verified locally (same machine as my comment above — macOS 27.0 beta 26A5388g, app 1.24012.9).

Root cause: the seatbelt profile (Resources/claude-ios-sim.sb) allows writes only to CoreSimulator dirs, DARWIN_TMP, and /private/var/tmp. On macOS 27 beta, CoreImage's Metal context creation loads a precompiled binary shader archive, and Metal needs the process's per-bundle shader-cache directory under DARWIN_USER_CACHE_DIR, i.e. /var/folders/…/C/com.anthropic.claude.ios-sim/. The profile denies creating it, the path comes back nil, and -[_MTLDevice recordBinaryArchiveUsage:] throws attempt to insert nil object → SIGABRT.

The bundle identity is the missing trigger: a bare binary running the same CoreImage/Metal code under the same profile passes (no per-bundle cache path), while the identical binary wrapped in an .app with CFBundleIdentifier=com.anthropic.claude.ios-sim crashes with the exact production stack. Repro:

# citest.swift: CIContext(mtlDevice:) + createCGImage — crashes bundled, passes bare
sandbox-exec -f claude-ios-sim.sb -D HELPER_BUNDLE=… -D XCODE_APP=… -D USER_HOME=$HOME \
  -D CORESIM_HOME=… -D CORESIM_LOGS=… -D DARWIN_TMP=… \
  Citest.app/Contents/MacOS/citest
# → NSInvalidArgumentException in -[_MTLDevice recordBinaryArchiveUsage:]_block_invoke

Fix (verified): one added rule, scoped to the helper's own bundle-id cache subtree:

(allow file-write*
  (regex #"^/(private/)?var/folders/[^/]+/[^/]+/C/com\.anthropic\.claude\.ios-sim(/|$)"))

With this appended to the shipped profile, the repro prints OK, Metal creates C/com.anthropic.claude.ios-sim/{com.apple.metal,com.apple.metalfe}, and the real helper stops crash-looping: MCP screenshot returns frames and the live panel attaches and streams. Also corroborates the sandbox analysis in #80472.

A (param …)-based variant would be cleaner than the regex if sidecarSandbox.ts passes DARWIN_USER_CACHE_DIR (sibling C/ of the current DARWIN_TMP param) as a new parameter.

Reproduced, with two additional data points.

Environment

• Claude Code CLI: 2.1.205 (MCP iOS Simulator tool, both attach and headless screenshot)
• macOS: 27.0 beta, build 26A5388g (same build as OP)
• Xcode: 27.0 beta 4 (27A5228h) selected via xcode-select — so this reproduces with the beta toolchain active as well, ruling out the selected-Xcode version as a factor
• Hardware: Apple Silicon
• Simulators: iOS 26.5 runtime device

Isolation

Crash-loops identically with exactly one booted simulator and no other capture processes running (we killed a coexisting serve-sim streamer and shut down a second booted device to eliminate both variables — no change).

Crash stack (from ~/Library/Logs/DiagnosticReports/claude-ios-sim-*.ips)

Same signature as OP, reached via the screenshot path:

claude-ios-sim   SimulatorBridge.screenshot(udid:)
FBSimulatorControl  FBSimulatorImage.image()
FBSimulatorControl  FBSurfaceImageGenerator.image()
CoreImage        -[CIContext initWithOptions:]
CoreImage        CI::MetalContext::init(...)
CoreImage        +[CIKernelLibrary(Internal) internalBinaryArchiveWithName:device:]
Metal            -[_MTLBinaryArchive initWithOptions:device:url:error:]
Metal            -[_MTLBinaryArchive loadFromURL:error:]
Metal            -[_MTLDevice recordBinaryArchiveUsage:]
CoreFoundation   +[NSArray arrayWithObjects:count:]   ← nil object
libobjc          objc_exception_throw
libc++abi        std::__terminate → SIGABRT

Suggested fix / workaround evidence

On this same OS build, the third-party serve-sim streamer works against the same devices: when the hardware H.264 path is unavailable it logs "H.264 was unavailable for this stream, so it fell back to MJPEG" and degrades gracefully. claude-ios-sim takes the CoreImage/Metal path unguarded, so the beta's broken Metal binary-archive load aborts the whole helper on every frame.

Wrapping the CIContext/screenshot render in an exception guard and falling back to a software renderer (kCIContextUseSoftwareRenderer) — or any non-Metal capture path — would keep the panel functional on beta OSes instead of crash-looping.