iOS Simulator panel crashes repeatedly with SIGABRT in Metal screen-capture path

Description

During a session driving the built-in iOS Simulator tool (mcp__Claude_Code_iOS_Simulator__control), the simulator panel repeatedly crashed and entered a restart loop. Every screenshot and attach call returned:

Claude Code iOS Simulator is restarting after a crash. Try again in 1s. The simulator restarts itself; retry this call.

Retrying (including with waits of 5-10s between attempts) did not reliably recover — in several cases attach came back reporting a different simulator device than the one that was actually booted/targeted.

Crash details

Found matching crash reports in ~/Library/Logs/DiagnosticReports/, named claude-ios-sim-*.ips. Key details from one:

• "bug_type": "309", "exceptionType": {"type": "EXC_CRASH", "signal": "SIGABRT"}
• "termination": {"code": 6, "namespace": "SIGNAL", "byProc": "claude-ios-sim"}
• Faulting thread stack (top frames):

``
__pthread_kill
pthread_kill
abort
__abort_message
demangling_terminate_handler()
_objc_terminate()
std::__terminate(void (*)())
__cxxabiv1::failed_throw(...)
__cxa_throw
objc_exception_throw
-[__NSPlaceholderArray initWithObjects:count:]
+[NSArray arrayWithObjects:count:]
__39-[_MTLDevice recordBinaryArchiveUsage:]_block_invoke
_dispatch_client_callout
_dispatch_once_callout
``

So the crash is an uncaught Obj-C exception thrown while constructing an NSArray inside _MTLDevice recordBinaryArchiveUsage: — looks like a Metal binary-archive bookkeeping call is being passed a malformed/nil array somewhere in the claude-ios-sim helper's rendering path, not in the target app or simulator OS itself.

Workaround used

I bypassed the panel entirely by driving the simulator directly via xcrun simctl:

• xcrun simctl io <udid> screenshot <path> for visual verification instead of the tool's screenshot action
• The tool's own tap/text actions for input still worked reliably even while screenshot/attach were crash-looping (input injection and the screen-capture/render path appear to be separate subsystems)

Environment

• macOS, Xcode 26.6 (Build 17F113)
• Multiple iOS 26.5 simulators available (iPhone 17, 17 Pro, 17 Pro Max, 17e, Air)
• This occurred while a native Xcode build (expo run:ios) was also running concurrently in the background, in case load/contention is a relevant factor

Impact

Not a hard blocker — screenshots/input via simctl directly are a reliable workaround — but the panel's own screenshot/attach path was unusable for the entire session once it started crash-looping, and attach returning the wrong device (not the one that was actually booted) is a separate, potentially confusing correctness issue worth checking into as well.