[BUG] iOS Simulator panel helper (claude-ios-sim) crashes on launch on macOS 27 beta — seatbelt profile blocks Metal's new per-bundle shader-cache directory

Confirmed — this workaround fully fixes it on a fourth machine. Outstanding diagnosis; the per-bundle-ID cache directory being new in the 27 beta is the piece everyone else (myself included) was missing.

Environment: Claude Desktop 1.24012.1, macOS 27.0 beta (26A5388g), M4 Pro, Xcode 27 beta 27A5228h selected, iOS 27.0 runtime 24A5380i.

Ran exactly the published command:

C_DIR=$(getconf DARWIN_USER_CACHE_DIR)
mkdir -p "$C_DIR/com.anthropic.claude.ios-sim/com.apple.metal/archiveUsage.db" \
         "$C_DIR/com.anthropic.claude.ios-sim/com.apple.metalfe" \
         "$C_DIR/com.anthropic.claude.ios-sim/com.apple.gpuarchiver"

$C_DIR/com.anthropic.claude.ios-sim did not exist beforehand, matching your prediction. After creating it and killing the helper so it respawned:

• attach — works (as before)
• screenshot — works, returns a live frame. Previously failed 100% of the time across ~20 attempts
• tap — works, the app responded and switched tabs

No new crash reports since. This is the whole panel restored, not just the stream.

Two data points that may help scope it:

• Your C/<bundleID>/ non-existence caveat is important. I had already tried precreating ~/Library/Caches/com.anthropic.claude.ios-sim/com.apple.metal, ~/Library/Caches/com.apple.metal and com.apple.metalfe — all no effect, because they're the wrong tree entirely. It is specifically $(getconf DARWIN_USER_CACHE_DIR), i.e. the C/ folder, not ~/Library/Caches. Worth stressing for anyone skimming, since the two are easy to conflate.
• $C_DIR/com.apple.metal (the non-per-bundle path) already existed here with populated per-GPU subdirs — so the presence of the old-style cache is not sufficient and doesn't mask the bug.

Also confirms your suggested fix #1 is the right shape: I'd independently narrowed it to claude-ios-sim.sb granting file-write* on only CORESIM_HOME, CORESIM_LOGS, DARWIN_TMP and /private/var/tmp with no param for the Darwin user cache dir — but without your disassembly of getCacheMainFolder/MTLGetShaderCachePath I had the mechanism only as an unverified hypothesis and the wrong directory. Adding a DARWIN_CACHE param alongside the existing DARWIN_TMP looks like a one-line profile change.

For anyone on a newer Xcode 27 seed: you may hit #80180 / #79991 first — SimulatorKit.framework moved to Contents/SharedFrameworks, so attach fails before any Metal code runs, and this crash stays hidden until that's worked around too:

ln -s ../../SharedFrameworks /Applications/Xcode.app/Contents/Developer/Library/PrivateFrameworks

Both were needed here to get a working panel.

Follow-up: I bisected the workaround, and only one of the three directories is actually required.

Method — after each change, pkill -f claude-ios-sim so the helper respawned, then a screenshot call:

| Directories present under $C_DIR/com.anthropic.claude.ios-sim/ | Result |
|---|---|
| (nothing — bundle dir absent) | crash |
| bundle dir only, no children | crash |
| com.apple.metal only | works |
| all three (com.apple.metal/archiveUsage.db, com.apple.metalfe, com.apple.gpuarchiver) | works |

So com.apple.metalfe, com.apple.gpuarchiver, and the archiveUsage.db leaf are not needed, and the minimal workaround collapses to:

mkdir -p "$(getconf DARWIN_USER_CACHE_DIR)/com.anthropic.claude.ios-sim/com.apple.metal"

Note the bundle dir alone crashing is the interesting row: it shows the failing mkdir is specifically copyCacheMainFolder("com.apple.metal", create=true) creating the com.apple.metal child, not the per-bundle dir itself. Matches your getCacheMainFolder trace exactly.

Metal never writes anything into it. After several successful attach/screenshot/tap cycles:

$ find "$C_DIR/com.anthropic.claude.ios-sim" -type f | wc -l
       0

The directory stays completely empty. That confirms your "Metal handles unwritable cache files gracefully; only the missing directory is fatal" point — writes are still denied by the profile and nothing degrades. Useful for scoping the real fix: the helper doesn't need write access to the cache tree at all in practice, so suggested fix #2 (launcher mkdir -ps the directory before spawning) is sufficient on its own and is strictly narrower than widening the seatbelt profile. If you'd rather not grant file-write* on a new subtree, you don't have to.

One caveat for anyone reproducing the bisect: the crash only reappears while the directory is genuinely absent, so rm -rf the bundle dir between trials — a stale com.apple.metal from an earlier successful run masks it, same as the caveat in your original repro.

Confirmed the minimal workaround on an independent machine — the single com.apple.metal directory is sufficient here too.

Environment: macOS 27.0 (26A5388g), xcode-select → /Applications/Xcode.app (stable, SimulatorKit.framework present in PrivateFrameworks, so the #80180 symlink was not needed), iPhone 17 on iOS 27.0.

Method: /bin/rm -rf the bundle dir between trials (per your caveat), recreate the directory under test, pkill -f claude-ios-sim, then attach + screenshot.

| State of $C_DIR/com.anthropic.claude.ios-sim/ | Result |
|---|---|
| (bundle dir absent) | crash — reproduced 3× |
| bundle dir only, no children | crash |
| com.apple.metal only | works — attach, screenshot, tap all fine |

So mkdir -p "$(getconf DARWIN_USER_CACHE_DIR)/com.anthropic.claude.ios-sim/com.apple.metal" is the whole fix on this machine, and the com.apple.metalfe / com.apple.gpuarchiver / archiveUsage.db entries from the original workaround are redundant.

Two confirmations worth adding:

• tap really actuates, it's not just the stream coming back. Tapping Settings on the home screen launched the app and the next screenshot showed the Settings root — so the whole input path is restored, not only the video frames.
• Metal writes nothing into the directory. After several successful attach/screenshot/tap cycles, find "$C_DIR/com.anthropic.claude.ios-sim" -type f | wc -l → 0. Same as your finding. This makes launcher-side mkdir (suggested fix #2) sufficient on its own; the seatbelt profile does not need a new file-write* subtree at all.

Crash signature in the failing rows is unchanged: EXC_CRASH/SIGABRT, abort() called, __exceptionPreprocess in the last exception backtrace — matching the original report.

Confirming on another machine — and on app 1.24012.9, newer than the builds reported above, so this is still present in the latest desktop build. The minimal workaround alone fully restores the panel.

Environment

• Claude Desktop 1.24012.9
• macOS 27.0 beta 26A5353q (earlier seed than the ones above)
• Xcode 26.6 selected (xcode-select -p → /Applications/Xcode.app); Xcode 27.0 beta installed but not selected — no SimulatorKit symlink needed here, consistent with the seed-scoping note above
• Simulator: iPhone 17 Pro on the iOS 26.5 runtime (iOS 27.0 24A5355p runtime also installed)

Symptom as it appears in the UI (for anyone searching): the panel loops "Attach simulator" → device list → black frame → back to the attach screen, indefinitely. First observed 2026-07-27; control-plane MCP calls were also unreliable across sessions (panel died mid-session and would not re-attach).

Applied only the minimal form:

mkdir -p "$(getconf DARWIN_USER_CACHE_DIR)/com.anthropic.claude.ios-sim/com.apple.metal"
pkill -f claude-ios-sim

After the helper respawned: attach succeeds, the live view streams real frames, and screenshot/tap work again.

Confirming the minimal (single-directory) form of the workaround fixes it here too.

Environment:

• macOS 27.0 beta (26A5388g)
• Apple M5
• Xcode 26.6 (17F113) selected via xcode-select; Xcode-beta.app also installed, not selected
• Simulator: iPhone 17 Pro, freshly booted

Before applying anything, I had a crash report from earlier today (claude-ios-sim-2026-07-28-123454.ips) with the identical signature — EXC_CRASH/SIGABRT, abort(), and the same __NSPlaceholderArray initWithObjects:count: → +[NSArray arrayWithObjects:count:] → -[_MTLDevice recordBinaryArchiveUsage:]_block_invoke → -[_MTLBinaryArchive loadFromURL:error:] → CIKernelLibrary → CIContext initWithMTLDevice:options: chain reported above.

Applied only the bisected minimal form:

​``bash
mkdir -p "$(getconf DARWIN_USER_CACHE_DIR)/com.anthropic.claude.ios-sim/com.apple.metal"
​``

No pkill needed — the next attach picked it up immediately. Result: attach succeeded, screenshot returned live frames through a full simulator boot to the home screen, no new .ips since. Adds a fifth confirmation and a new chip (M5, not previously reported in this thread).