iOS Simulator panel: screenshot crash-loops on macOS 27.0, inspect unavailable

iOS Simulator panel: screenshot crash-loops on macOS 27.0, inspect unavailable

Summary

On macOS 27.0 (build 26A428), the Claude Code iOS Simulator integration cannot
capture the screen. attach, tap, and open_url all succeed, but every
screenshot call fails with:

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

and inspect returns:

'inspect' is not available right now. Use 'screenshot' instead.

Because the same capture pipeline feeds the live panel, the panel never renders
the app — it stays on the "Attach a simulator so Claude can see your app"
placeholder, even though attach reports Simulator panel opened for ....

Environment

| | |
|---|---|
| Claude Code | 2.1.269 |
| macOS | 27.0 (build 26A428) — pre-release |
| Hardware | Mac mini (2024), Apple M4 Pro, 24 GB |
| Architecture | arm64 (Darwin 27.0.0) |
| Xcode | 26.6 (17F113), xcode-select -p = /Applications/Xcode.app/Contents/Developer |
| Also installed | /Applications/Xcode-beta.app |
| iOS runtimes | 26.5 (23F77), 27.0 (24A5380i) |

Steps to reproduce

1. Boot any iOS simulator: xcrun simctl boot <udid>
2. attach to it via the Claude Code iOS Simulator tool — succeeds, returns

Simulator panel opened for ... Coordinate space for tap/swipe: 440x956 points

1. Call screenshot on that same device

Expected: a PNG of the simulator screen, and the panel renders the device.

Actual: the call fails with the "restarting after a crash" message, and the
panel continues to show the attach placeholder. Retrying reproduces it
indefinitely.

What works vs what fails

| action | result |
|---|---|
| attach | succeeds, every device, every time |
| tap | succeeds (verified — taps landed on real UI targets) |
| open_url | succeeds (deep link opened the app) |
| screenshot | crashes the service, every time |
| inspect | returns "not available right now" |

Input injection is fine; only capture is broken.

Variables ruled out

The crash reproduced identically across every variable that could be changed:

| variable | values tried | result |
|---|---|---|
| device | 3 distinct simulators | crash on all |
| iOS runtime | 26.5 and 27.0 | crash on both |
| screen size | iPhone 17 Pro (402x874 pt), iPhone 17 Pro Max (440x956 pt) | crash on both |
| scale parameter | omitted, 0.5, 0.4 | crash on all |
| Claude Code restart | full application restart | crash unchanged |
| device freshly booted | yes | crash unchanged |

The only constant is the host OS.

Note on simctl

xcrun simctl io <udid> screenshot <path> works perfectly throughout, including
immediately after a failed Claude screenshot call. So the simulator itself,
CoreSimulator, and the display are all healthy — the failure is specific to the
integration's own capture path.

Suspected cause

macOS 27.0 is pre-release, and this looks like a compatibility gap rather than a
configuration problem. A related-in-kind failure on the same machine: the
Command Line Tools ship MacOSX27.0.sdk, whose libSystem.B.tbd declares an
arm64e.x1 architecture that Xcode 26.6's tapi rejects with
ld: tapi error: malformed file ... unknown architecture. Tooling built before
macOS 27 breaks on macOS 27 artifacts; the capture service may be hitting the
same class of issue (e.g. a ScreenCaptureKit or CoreSimulator API change).

Impact

The integration is usable for automation (attach/tap/open_url) but not for its
primary stated purpose — letting the user watch the app and letting Claude
verify visually. Workaround is to drive the simulator through the Claude tool
and capture separately via xcrun simctl io ... screenshot, which is awkward
and leaves the panel blank for the user.

Suggested improvements regardless of the root cause

1. attach reporting Simulator panel opened for ... is misleading when the

panel cannot render — it confirms the request, not the result. A failure or
warning here would surface the problem immediately instead of after the first
screenshot.

1. The crash message says "Try again in 1s" and "The simulator restarts itself",

which reads as transient. When the failure is persistent, repeated retries are
the wrong advice; a distinguishable persistent-failure error would help.