iOS Simulator control tool ignores requested device UDID when multiple sessions run concurrently on the same Mac

Bug: iOS Simulator control tool ignores the requested device UDID on multi-session machines — screenshot/input always targets one fixed device

Summary

On a Mac running multiple concurrent Claude Code sessions, the iOS Simulator control tool's attach/screenshot (and presumably tap/swipe) commands do not reliably target the device UDID passed to attach. attach reports success for the requested device, but the subsequent screenshot call returns an image of, and is explicitly labeled as, a different booted simulator — one that another concurrent session is actively driving.

Environment

• macOS 26.5.2 (build 25F84)
• Xcode 26.0.1 (build 17A400)
• Multiple Claude Code sessions running concurrently on the same machine (7 other interactive sessions active at the time, confirmed via ListAgents)
• 3 simulators booted simultaneously:
• iPhone 16 (iOS 18.6) — UDID 7469F529-B466-420A-9013-190DDC4F2257
• iPhone 17 Pro (iOS 26.0) — UDID 8AF2D592-BFFB-43CC-99CC-3736C8164499 (has my project's app installed)
• A freshly-created simulator, LSC-Verify (iOS 26.0) — UDID 44026D05-F380-4E41-8FBA-D20FC8F36B6B (created specifically to try to escape the contention below)

Steps to reproduce

1. Have ≥2 Claude Code sessions running on the same Mac, each with a different simulator booted and in active use (e.g. one session driving iPhone 16 with its own app).
2. In a second session, call attach with an explicit udid for a different, currently-idle simulator (e.g. iPhone 17 Pro).

• Result: tool reports success, e.g. "Simulator panel opened for iPhone 17 Pro (8AF2D592-...). Coordinate space for tap/swipe: 402x874 points (origin top-left)."

1. Immediately call screenshot.

• Expected: a screenshot of iPhone 17 Pro (idle home screen, or whatever app is installed there).
• Actual: the tool returns a screenshot of iPhone 16 instead, and the result's own caption explicitly says "Screenshot of iPhone 16 (7469F529-B466-420A-9013-190DDC4F2257)." — i.e. the tool itself reports the mismatch between the attached UDID and the captured device.

1. Repeated across many attempts over ~1 hour (different UDIDs passed to attach, including a brand-new simulator created solely for this purpose, plus manually clicking the correct Simulator.app window into focus on macOS) — screenshot always returned iPhone 16's content, each time showing a different unrelated app actively being driven by presumably another concurrent session (observed: a Chinese-vocabulary app, a different IELTS/exam-prep app's Settings and Profile screens, and a payment-confirmation screen from yet another app — none of which are my project).
2. A detach call earlier in the same investigation reported tracking 3 devices simultaneously across sessions, suggesting the underlying attach/track state may not be properly session-scoped.

Expected behavior

attach { udid: X } should cause all subsequent screenshot/tap/swipe/etc. calls in that session to target device X, independent of what other concurrent Claude Code sessions on the same machine are doing with other simulators.

Actual behavior

screenshot (and likely input commands) appear to follow some global/shared state — possibly "whichever Simulator.app window is currently frontmost on the OS" or a stale/shared tracked-device list — rather than the UDID this session explicitly attached to. This makes the tool effectively unusable for verifying an app visually whenever another Claude Code session on the same machine is concurrently using the Simulator.

Impact

Blocked an entire session's worth of intended visual QA (screenshot-based comparison against design references) for a Flutter app build. Had to fall back to code review only, with the user separately confirming correct rendering via their own IDE's embedded simulator panel (a different rendering surface, not affected by this bug — evidence that the app itself was fine and the bug is isolated to this tool's device targeting).

Suggested fix direction

Scope simulator attach/tracking state per Claude Code session (e.g. keyed by session/connection id) rather than relying on shared OS-level window focus or a single global "current device" pointer, so concurrent sessions on the same machine don't interfere with each other's simulator control.