iOS physical-device support blocked on macOS 26 (Tahoe) — go-ios can't read /var/db/lockdown/RemotePairing/

[12mv2]

Summary

mobile-mcp's only iOS physical-device transport is go-ios (per src/ios.ts:34-41). On macOS 26 (Tahoe), go-ios fails to read /var/db/lockdown/RemotePairing/user_501/selfIdentity.plist — even with sudo + Full Disk Access granted to the calling terminal — which means mobile-mcp on physical iOS is broken on the current macOS for any user that's upgraded to Tahoe. Sim path remains fully functional.

Environment where reproduced

• macOS: 26.x (Tahoe, current shipping macOS as of April 2026), Apple Silicon, Darwin 25.2.0
• mobile-mcp: v0.0.52 (latest)
• go-ios: v1.0.211 (latest at time of report; /opt/homebrew/bin/ios replaced with the go-ios-mac.zip release asset since the npm wrapper is pinned at v1.0.188)
• Xcode: 26.4
• Device: iPhone 17 Pro on iOS 26.x, USB-connected, paired via Xcode

Repro

# Apple's tools see the device:
xcrun devicectl list devices
# → iPhone (state: connected)

# mobile-mcp's `mobile_list_available_devices` returns only sims, not the iPhone:
# (empty deviceList from go-ios's underlying `ios list`)

# Underlying go-ios fails:
sudo pkill -SIGSTOP remoted   # standard tunnel-vs-remoted workaround
sudo /opt/homebrew/bin/ios tunnel start --pair-record-path=default --userspace
# → fatal: NewPairRecordManager: failed to get self identity:
#   readSelfIdentity: could not read file:
#   open /var/db/lockdown/RemotePairing/user_501/selfIdentity.plist: operation not permitted

Granting iTerm Full Disk Access (System Settings → Privacy & Security → FDA, full Cmd+Q + relaunch) does not propagate to sudo'd subprocesses for that path on Tahoe. Apparently a TCC restriction beyond standard FDA — Apple's own xcrun devicectl works because it carries entitlements third-party binaries don't.

Why filing here too

go-ios upstream issue: danielpaulus/go-ios#710. Filing on the mobile-mcp side because:

1. Users hit the symptom here first. They install mobile-mcp, expect physical iOS to "just work" per the wiki, see "no devices detected." They're unlikely to find the go-ios-side bug report on their own.
2. PR feat: use mobilecli ios device #271 (mobilecli swap) is the most natural mitigation path — if mobilecli has a different code path for pair-record reads, it could bypass the Tahoe TCC wall. Worth knowing whether the maintainer expects that PR to land soon.
3. Documenting the sim/device gap on Tahoe in the README would save users the same ~30-50 min I spent before recognizing the wall.

Asks

1. Is there a known workaround using mobile-mcp + go-ios on Tahoe?
2. Is PR feat: use mobilecli ios device #271 (or any other Tahoe-aware iOS transport) on a near-term roadmap?
3. Could the wiki/README flag the macOS 26 (Tahoe) physical-device limitation prominently? Right now the iOS Real Device wiki implies USB+go-ios+WDA "just works."

Happy to test any candidate fix and report back. Thanks for the project — sim half of mobile-mcp has been incredibly useful for our regression harness even with device path wedged.

[gmegidish]

@12mv2 Thanks for the ticket. I cannot reproduce this issue. it works well for me.
can you please try with "npx mobilecli" to reproduce the issue? we can go on a slack huddle if you want, you can show me how you debugged this, and we can improve our documentation.