[BUG] iOS Simulator tool: tap actions silently fail or land out of order while screenshot stays reliable

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title

iOS Simulator tool: tap frequently fails to register or lands several taps late, while screenshot stays reliable

Environment

• macOS 26.7 (build 25G229)
• Xcode 26.2 (also had Xcode 27.0 installed side-by-side)
• iOS Simulator runtime 26.3.1
• Device: iPhone 17 Pro (simulator)
• Claude Code desktop app, using the mcp__Claude_Code_iOS_Simulator__control tool (attach, tap, screenshot, text actions)

Summary

During a long simulator-testing session, the tap action became highly unreliable: most taps silently failed to register in the app, while screenshot continued to work correctly and consistently. This persisted across multiple detach/attach cycles, full simulator reboots (xcrun simctl shutdown + boot), restarting the CoreSimulatorService background daemon, and restarting the claude-ios-sim helper process.

Observed behavior

• A tap call returns success (Tapped at (x, y) on <device>), but the subsequent screenshot shows no change in the UI.
• Occasionally, a tap would appear to "catch up" several actions later — e.g. tapping a list item would open a previously tapped row instead of the one just requested, suggesting taps were being queued and delivered out of order / with significant lag, rather than uniformly dropped.
• Separately, the text action reliably triggered the React Native Dev Menu (the app's shake-gesture debug menu) instead of typing into a focused text field — happened consistently across multiple attempts on different screens.
• screenshot itself failed intermittently with captureFailed after simulator reboots, recoverable by killing and letting the claude-ios-sim helper process respawn (via macOS pkill -f claude-ios-sim then calling attach again).

What I ruled out

1. Target size/precision — taps failed even on large, isolated, unambiguous targets (e.g. a full-width "Back" button in the nav bar), not just small/adjacent UI elements.
2. Conflict with the standalone Simulator.app — I had manually opened the stock Simulator.app (from Xcode's own Applications folder) pointed at the same device UDID, wondering if a second GUI window might help. Taps were still unreliable with it open. When I then quit that Simulator.app process, the next tap call from the Claude tool immediately failed with tap failed: clientDisposed — indicating the tool's HID client was coupled to (or dependent on) that separate process's lifecycle at that moment. Re-attaching afterward reset the connection, but tap reliability did not improve with Simulator.app closed either.

Suspected trigger (not confirmed causal)

Earlier in the same session, I had killed and let respawn CoreSimulatorService and the claude-ios-sim helper process multiple times while working around an unrelated Xcode-version conflict (an iOS 27.0 vs 26.2 SDK/runtime mismatch). Tap reliability degraded sometime after that, though I could not pin down an exact reproducible trigger — it's possible one of those restarts left the HID injection channel (as opposed to the screen-capture channel, which kept working) in a bad state that only a full Claude desktop app restart would clear (a full app restart did restore screenshot and attach functionality once, but tap reliability remained poor afterward).

Impact

Made autonomous UI testing/navigation in the simulator effectively unusable for the rest of the session — had to hand off all tap interactions to the human user, who could interact with the same simulator panel reliably via direct mouse clicks (real OS input, not the tool's synthesized HID injection).

Suggested investigation areas

• Whether the tool's HID tap-injection path can get desynchronized from the screen-capture path (they're clearly using different underlying mechanisms, since only one degraded).
• Whether CoreSimulatorService restarts mid-session can leave the tap-injection client in the tool's helper process (claude-ios-sim) in a stale state that isn't detected/recovered automatically (only screenshot failures triggered an obvious recoverable error; tap failures were silent).
• Whether attaching a second, independent client (standalone Simulator.app) to the same device UDID as the tool's own client can cause the kind of coupling seen in the clientDisposed error.

What Should Happen?

For a "What should happen?" field, keep it short and factual:

tap actions should reliably register in the simulator every time they're sent, and should apply immediately/in order — not fail silently, and not queue up and land several taps late. Tap reliability should match the reliability already seen with screenshot, which worked consistently throughout the same session.

Error Messages/Logs

Steps to Reproduce

Here's a "Steps to Reproduce" section:

1. Attach the iOS Simulator tool to a booted simulator device and confirm tap + screenshot work normally.
2. Over the course of the session, restart the CoreSimulatorService background daemon multiple times (pkill -f CoreSimulatorService) — e.g. to recover from a device-not-found issue. Each restart shuts down booted simulators.
3. Each time, reboot the simulator (xcrun simctl boot <udid>) and re-run attach.
4. Continue using tap and screenshot for app testing/navigation.
5. At some point after several such cycles, tap calls return success but produce no visible change — screenshot right after shows the UI unchanged.
6. Retrying the same tap repeatedly sometimes eventually registers, sometimes with a multi-tap delay (a tap opens a screen corresponding to an earlier tap, not the most recent one) — suggesting taps queue and deliver late/out of order rather than drop outright.
7. Restarting the claude-ios-sim helper process (pkill -f claude-ios-sim, then attach again) doesn't restore tap reliability, though it reliably fixes screenshot failures (captureFailed) when those occur.
8. Fully quitting/reopening the Claude desktop app restores screenshot/attach cleanly, but tap reliability remains degraded afterward.

Note: I wasn't able to reduce this to a minimal, deterministic repro — it degraded gradually over a long session rather than from one clear trigger. The CoreSimulatorService restarts (step 2) are the most likely suspect since that's the main unusual thing done beforehand, but this isn't confirmed causal.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.2553.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_