iOS Simulator panel: stream dies and never recovers on stable macOS 26.6 — detach() reports success but attach() still says "already attached"

Summary

On a stable, non-beta macOS, the desktop iOS Simulator panel's video stream dies and never comes back. attach, tap, swipe and launch keep working, so the panel looks connected and is driveable, but the pane shows 0 fps and every screenshot fails with captureFailed. inspect also reports itself unavailable.

The part I think is new, and the reason this is worth reopening: detach reports success but does not actually clear the attached state, and the next attach short-circuits with "already attached" instead of renegotiating the stream. That closes off the only in-tool recovery path. Quitting and reopening the Claude desktop app restores capture immediately.

This is the same failure signature as #81864, which was closed as stale. That report was on macOS 27 beta territory and noted detach/attach did not help; it did not identify why, or that an app restart is a reliable fix. #81520, #80472 and #93949 are the macOS 27 beta BitmapStream crash-loops and are a different bug — in my case the helper never crashes.

Environment

| | |
|---|---|
| macOS | 26.6.2 (25G83) — release, not a beta |
| Claude desktop | 1.52386.6 |
| Claude Code | 2.1.270 |
| Xcode | 26.6 (17F113) |
| iOS runtime | 26.5 (23F77) |
| Device | iPhone 17 Pro simulator |

What distinguishes this from the known crash-loop bugs

The helper is healthy throughout:

$ pgrep -lf claude-ios-sim
<pid> .../sandbox-exec -f .../claude-ios-sim.sb ... claude-ios-sim
<pid> /Applications/Claude.app/Contents/Helpers/Claude iOS Sim.app/Contents/MacOS/claude-ios-sim

$ ls ~/Library/Logs/DiagnosticReports/ | grep -ic claude-ios-sim
0

No SIGABRT, no crash reports, no auto-restart. Only the encoder is dead.

Reproduction

Hit while driving an app through a long build session. The trigger appears to be changing device or app state out of band while the panel is attached:

1. Open the Claude desktop app with the simulator panel available.
2. From a shell, xcrun simctl boot '<device name>' — i.e. boot the device after the panel helper is already running.
3. attach — succeeds.
4. screenshot — works at this point.
5. From a shell, xcrun simctl terminate <bundle id>, xcrun simctl uninstall <bundle id>, xcrun simctl install <device> <app>.
6. screenshot — now fails with captureFailed, and the pane reads 0 fps. Taps and swipes still land correctly.

Step 5 is the likely culprit: the stream looks bound per-boot/per-session, and nothing renegotiates it when the device state changes underneath.

The recovery path is the actual bug

Verified in sequence, with nothing in between:

detach     → "Detached <device name> (<udid>)."          ← reports success
attach     → "Simulator panel already attached to <device name> (<udid>)."
screenshot → "screenshot failed: captureFailed"

detach claims to have detached, and attach immediately afterwards believes it is still attached. Whatever detach tears down, it is not the state attach checks, so attach returns early and never rebuilds the encoder session. From the tool surface there is then no way back.

Workaround

Quit and reopen the Claude desktop app. That respawns claude-ios-sim and capture works again on the first attach + screenshot, with no other change — same booted device, same installed app, same UDID. Confirmed in this session.

Two things that do not work: detach + attach (above), and having Simulator.app already open and rendering correctly — it was running and rendering fine the whole time the panel showed 0 fps.

xcrun simctl io <udid> screenshot <path> also keeps working throughout, which is a usable fallback for automated verification but does not help the human looking at the pane.

Suggested fixes

1. Make detach actually clear the attachment state, so attach renegotiates rather than short-circuiting. Even without a root-cause fix for the encoder, this restores an in-tool recovery path.
2. Failing that, have attach verify the stream is live before reporting "already attached", and rebuild it if not.
3. Ideally, re-establish the stream automatically when the attached device's boot session or installed app changes, since driving a simulator from a shell alongside the panel is a normal thing to do during a build.

Note on inspect

Throughout the same session, inspect returned 'inspect' is not available right now. Use 'screenshot' instead. — including after the app restart, when screenshot was working again. That may be unrelated, or may be the same capability-gating; flagging it since #93949 mentions inspect unavailability alongside the capture failure.