# Reported issues for AutoMobile Pod holds 24 of 457 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user. Back to [AutoMobile](/mcp/automobile). ## Most discussed ### iOS: Implement ScreenCaptureKit simulator window capture ## Overview Create screen capture for iOS Simulator using macOS ScreenCaptureKit API. This captures the simulator window and streams raw frames to the MCP server. ## Prerequisites - #1034 ✅ iOS research complete - iOS device capture helper (for shared frame protocol) ## Background ScreenCaptureKit (macOS 12.3+) provides low-latency window capture, making it ideal for capturing iOS Simulator windows. See [iOS Screen Streaming Design Doc](docs/design-docs/ios/screen-streaming.md) for details. [Read the thread](https://github.com/kaeawc/auto-mobile/issues/1096) · 2026-01-30 · closed · 6 comments ### feat(voiceover): support VoiceOver Magic Tap (two-finger double-tap) Part of #3916 (seamless navigation whether or not a screen reader is enabled). ## Summary The iOS VoiceOver **Magic Tap** — the two-finger double-tap that triggers an app's primary/context action (answer/end a call, play/pause media, start/stop recording, etc.) — is not supported. There is no `requestMagicTap` command on the iOS CtrlProxy client or in the runner protocol. ## Reference - Parity design doc Gap 5: `docs/design-docs/mcp/a11y/voiceover-talkback-parity.md:84-92`. - No `requestMagicT [Read the thread](https://github.com/kaeawc/auto-mobile/issues/3935) · 2026-07-18 · open · 3 comments ### fix(ios): SDK in-app hierarchy (:8766) merged into observes of unrelated foreground apps — ~2.5MB hierarchies ## Summary When an iOS app embedding the AutoMobile SDK is running (its in-app hierarchy server bound on port 8766), the SDK hierarchy gets merged into **every** `observe` — including observes whose **foreground app is a different, non-SDK app**. The result is a ~**2.5 MB / ~4000-node** view hierarchy returned for a screen that should be small (e.g. iOS Settings), an **~80× size blowup**. Terminating the SDK app drops the same observe back to ~71 KB. This is both a **correctness** concern (hie [Read the thread](https://github.com/kaeawc/auto-mobile/issues/2540) · 2026-06-25 · closed · 3 comments ### feat(ios): AXBridge — invoke custom accessibility actions ## Summary Enable invoking `UIAccessibilityCustomAction` on iOS Simulator elements via the macOS AX bridge. This is the primary motivation for AXBridge — XCUITest has no API for this. ## Verified Behavior Custom actions appear inline in an element's action list with the format: ``` Name:\nTarget:0x0\nSelector:(null) ``` Invoking works via `AXUIElementPerformAction(element, actionName)` — just the action name string, no need for the full `Name:...\nTarget:...` format. ## Proof o [Read the thread](https://github.com/kaeawc/auto-mobile/issues/2267) · 2026-05-21 · open · 3 comments ### Bug: launchApp not correctly observing app state after launch ## Description The `launchApp` MCP tool is not correctly returning the app state observation after launching an app, causing AI agents to make redundant `observe` calls immediately after launch. ## Current Behavior When `launchApp` is called, it successfully launches the app but the observation data returned may be stale, incomplete, or not reflecting the actual app state. This causes AI agents (like Claude) to immediately follow up with an explicit `observe` call to get the current screen st [Read the thread](https://github.com/kaeawc/auto-mobile/issues/537) · 2026-01-09 · closed · 3 comments ### Re-cut Android control-proxy artifact to deliver DataStore MCP commands (#5573) ## Summary [PR #5594](https://github.com/kaeawc/auto-mobile/pull/5594) (closed [#5573](https://github.com/kaeawc/auto-mobile/issues/5573)) wired the Jetpack DataStore inspection chain end-to-end in source — TS wire types + client + MCP tools (`listDataStores`/`getDataStore`), plus the `android/control-proxy/**` command handlers (`list_data_stores`/`get_data_store`) and `StorageSubscriptionManager` methods. Because the runner change lives in `android/control-proxy/**`, the daemon still download [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5596) · 2026-08-24 · closed · 2 comments ### Android: recover System UI ANRs without releasing device ownership # Android: recover System UI ANRs without releasing device ownership ## Problem An Android emulator can show a System UI ANR dialog, such as: > System UI isn't responding When this occurs, the device may still appear booted and some automation checks may continue to succeed, even though the UI is not reliable for test execution. AutoMobile should treat this as a recoverable device-health failure rather than continuing with the affected emulator or immediately releasing it for another sessio [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5427) · 2026-08-21 · closed · 2 comments ### Reduce MCP output token cost for agentic runs (inert --actions-no-observe, element subtree bloat, pretty-printed JSON) Three things inflate MCP output token cost, which compounds significantly in agentic runs since the full observation is re-read from cache every turn: 1. **`--actions-no-observe` is a no-op** - it parses into `ServerConfig` but the interaction-tool response path never reads it, so `tapOn`/`inputText`/etc. always return the full post-action observation. Stripping `elements`/`viewHierarchy` from action results (leaving `observe` intact) cut a `tapOn` result from ~5.6k to ~0.4k tokens. 2. **`elem [Read the thread](https://github.com/kaeawc/auto-mobile/issues/3141) · 2026-07-05 · closed · 2 comments ## Most recent ### bug(mcp): enabled dynamic tool can remain absent from host discovery ## Summary A successful `setToolEnabled` call can leave a default-off tool unavailable to the host's callable tool catalog. In the observed run, `openLink` remained absent after it was enabled, discovery was refreshed, and the MCP connection was re-established. ## Reproduction 1. Connect an MCP client to AutoMobile and establish an active device/routing session. 2. Call `setToolEnabled` with `{ "toolName": "openLink", "enabled": true, "sessionUuid": "" }`. 3. Confirm that the [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5980) · 2026-08-30 · closed · 0 comments ### feat: intentionally crash a target app for resilience testing ## Summary Add an explicit AutoMobile capability to intentionally crash a specified target application. This should create a genuine application crash suitable for exercising crash detection, diagnostic capture, recovery, and resilience-test flows. ## Why Force-stopping an app is not equivalent to a crash: it bypasses the OS crash path and may not produce the logs, reports, or lifecycle signals that consumers need to validate. Test authors need a deterministic way to cause a real crash withou [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5977) · 2026-08-30 · closed · 0 comments ### listDeviceImages tool omits capabilityInventory for iOS while the devices/images/ios resource includes it ## Summary #5782 added a versioned `capabilityInventory` to device-image responses. It is present on the `automobile:devices/images/ios` **resource** but missing from the `listDeviceImages` **tool** response for iOS. Android has it in both, so the tool/resource pair disagree only on iOS. A caller that discovers images through the tool (the documented `listDevices` → `listDeviceImages` → `getApple` flow) cannot see iOS capabilities at all. ## Repro Tool — iOS has none: ```bash bun dist/src/i [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5965) · 2026-08-30 · closed · 0 comments ### tapOn effect.screenChanged false-negatives on Android in-app navigation (post-tap observation captured before the transition settles) ## Summary `tapOn` reports `effect.screenChanged: false` for taps that demonstrably navigate to a new activity on Android. The `effect` field shipped in #5943 is meant to tell a client whether a tap did anything; today it produces a false negative for ordinary in-app navigation, which makes it unsafe to branch on. iOS is unaffected — it takes the `viewHierarchy` hash path and reports correctly. ## Repro (API 31, `am-api31-ga-arm64`) ```bash bun dist/src/index.js --cli homeScreen --platform a [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5964) · 2026-08-30 · closed · 0 comments ### Orphaned Android CtrlProxy adb forwards (tcp: → tcp:8765) are never reconciled and removal failures are swallowed ## Summary Host-side `adb forward tcp: → tcp:8765` entries created for the Android **CtrlProxy** transport are never reconciled. Their only removal path is `AndroidCtrlProxyClient.close()` (and the pre-setup remove inside `setupPortForwarding`), both of which run `adb forward --remove` **best-effort and swallow every failure**. There is no daemon-level GC/sweep for these entries — in direct contrast to the video path, which got exactly this treatment in #4753 (`sweepOrphanForwards` / `rec [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5962) · 2026-08-30 · closed · 1 comment ### tool-output resource leaks filesystem error detail (host path) to client (CWE-209) Follow-up from PR https://github.com/kaeawc/auto-mobile/pull/5926 (issue #5917). ## Problem The `automobile:tool-output/{artifactId}` resource returns the raw filesystem failure detail to the MCP client in its error message (CWE-209, information disclosure). In `src/server/toolOutputResources.ts`, the read-failure path passes the underlying error string as `detail` to `notAvailable(...)`, which appends it to the client-facing message: ```ts // line ~143 } catch (error) { const reason = err [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5933) · 2026-08-30 · closed · 0 comments ### Soak: kqueue fd leaks 1/30s for daemon lifetime (worker-per-health-check); AVD stops booting after 145 start/kill cycles Weekend soak / leak hunt, 2026-08-30 03:06–07:30 UTC, on `39ba23f29` (local build, macOS 24.6.0, bun 1.3.14). Driver cycled `getAndroid` → `setActiveDevice` → `observe` ×3 → `homeScreen` → `killDevice` on `am-api30-ga-arm64` while a second loop cycled daemon connect/disconnect every 15s, sampling daemon RSS/fd/socket counts and orphan PIDs every 2 minutes. **174 cycles run. 145 succeeded; every cycle from #146 on failed.** Two distinct defects fell out. --- ## 1. Unbounded kqueue fd leak — on [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5930) · 2026-08-30 · closed · 0 comments ### Flake: iOS videoRecording start-stop integration times out on 'videoRecording start' (MCP -32001) in XCTestRunner Simulator Tests ## Symptom The `XCTestRunner Simulator Tests` → **Run videoRecording MP4 integration test** step (`scripts/ios/video-recording-start-stop-integration.sh`, `test/integration/iosVideoRecordingStartStop.integration.test.ts`) intermittently fails when the `videoRecording start` MCP call times out: ``` error: Error: Command failed: auto-mobile --cli videoRecording --action start --platform ios \ --deviceId --outputName issue-2628-ios-video-recording --qualityPreset low --fps 15 --maxDurati [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5921) · 2026-08-30 · closed · 0 comments ### Harden non-finite transport provenance: flag lives in caller-controllable arguments namespace ## Context Follow-up from the review of PR [#5909](https://github.com/kaeawc/auto-mobile/pull/5909) (which closed #5863, itself a follow-up to #5854/#5860). PR #5909 scopes non-finite sentinel **revival** by transport provenance: the daemon client stamps an internal `__autoMobileNonFiniteEncoded` flag inside a tool call's `arguments`, and the MCP CallTool handler (`reviveNonFiniteArguments`, `src/utils/nonFiniteJson.ts`) decodes only flagged requests. This matches the design proposed verbatim [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5919) · 2026-08-30 · closed · 0 comments ### Harden tool-output MCP resource: session-fence exemption + artifact provenance (follow-up to #5882) Follow-up from [#5882](https://github.com/kaeawc/auto-mobile/issues/5882) / PR [#5908](https://github.com/kaeawc/auto-mobile/pull/5908), which added the `automobile:tool-output/{artifactId}` MCP resource so spilled tool-output artifacts (e.g. `observe {"raw": true}`) are fetchable in-band. Two harden-later items were deliberately deferred to keep that PR scoped to the core `observe` acceptance criterion. ## 1. `executePlan` artifact URIs are unreadable on a terminally-fenced connection `execut [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5917) · 2026-08-30 · closed · 1 comment ### Error messages name the problem but omit the next step: selector keys, missing-vs-invalid platform, daemon build mismatch Filed by the MCP dogfood loop on `main` @ d8949029c. Three errors I hit in one session, each of which named the problem and then stopped short of the one fact needed to fix it. Grouping them because the change is the same shape in all three. ## 1. Selector rejection does not list the valid keys ``` tapOn { selector: { contentDesc: "Add alarm" } } -> MCP error -32603: Invalid parameters for tool tapOn: selector Unrecognized key: "contentDesc" ``` The skeleton labels the element `'Add alarm'` f [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5916) · 2026-08-30 · closed · 0 comments ### observe --project skeleton still ships layoutWarnings + performanceAudit: only 38% of the payload is the skeleton Filed by the MCP dogfood loop on `main` @ d8949029c, driving `emulator-5554` (API 34) through the Clock app. ## What happened A `observe` skeleton response on an ordinary screen, broken down by key: ``` TOTAL 13917 5404 38% skeleton <- what I actually use 4522 32% layoutWarnings 1641 11% backStack 1107 7% performanceAudit 599 4% insets ... ``` The skeleton is 38% of the payload the skeleton projection produced. The other 62% is mostly things I never read [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5914) · 2026-08-30 · closed · 0 comments ### tapOn returns success:true for a tap that had no effect — client cannot distinguish a no-op tap from an effective one Filed by the MCP dogfood loop while completing a real end-user task ("set an alarm") on `emulator-5554` (API 34) against `main` @ d8949029c. ## What happened Tapping the Clock app's "Add alarm" FAB with `tapOn` returned success **twice** and the time picker never opened: ``` tapOn { platform: "android", deviceId: "emulator-5554", selector: { text: "Add alarm" } } -> { "success": true, "message": "Tapped on element (matched id=com.google.android.deskclock:id/fab text=\"Add alarm\"; 1 matc [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5910) · 2026-08-30 · closed · 0 comments ### Extend the skeleton-default + raw/project opt-out to all observation-producing action tools (follow-up to #5872) Follow-up from [#5872](https://github.com/kaeawc/auto-mobile/issues/5872) / [PR #5885](https://github.com/kaeawc/auto-mobile/pull/5885). #5872 made the embedded post-action `observation` default to the compact `skeleton` and added the `raw`/`project` opt-out control to `tapOn`, `inputText`, and `launchApp` — the three tools the issue named. In PR #5885 the skeleton default is deliberately **scoped to exactly those three tools** (`SKELETON_DEFAULT_ACTION_TOOLS` in `src/server/finalizeToolRespons [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5886) · 2026-08-29 · closed · 0 comments ### observe raw:true escapes to a host file path with no in-protocol way to fetch it ### Context Split from #5869, whose label-hoisting part shipped in [#5875](https://github.com/kaeawc/auto-mobile/pull/5875). This tracks the remaining acceptance-criterion item (3) from that issue, which is a distinct, larger surface. ### Problem (verbatim scope from #5869, authored by @kaeawc) `observe {"raw": true}` returns a host filesystem path: ```json {"artifact":{"path":"/Users/.../tool_outputs/…-observe-….json","format":"json","bytes":120774}} ``` AutoMobile's MCP surface has no too [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5882) · 2026-08-29 · closed · 0 comments ### tools/list blocks for the full 30s daemon-readiness budget, so its actionable error never reaches the client — the server appears connected with zero tools Filed by the MCP dogfood loop. This one cost me the entire session's tool surface: **Claude Code showed AutoMobile as connected with zero tools**, and nothing in the client surfaced why. ## What the client saw `~/Library/Caches/claude-cli-nodejs/-Users-jason-kaeawc-auto-mobile/mcp-logs-auto-mobile/`: ``` Successfully connected (transport: stdio) in 599ms Connection established with capabilities: {"hasTools":true,...,"serverVersion":{"name":"AutoMobile","version":"0.0.66"}} Failed to fetch too [Read the thread](https://github.com/kaeawc/auto-mobile/issues/5871) · 2026-08-29 · closed · 0 comments The remaining reports are on [the project's issue tracker](https://github.com/kaeawc/auto-mobile/issues).