Second iOS device sends commands to first device's agent (hardcoded localhost:8100 client) #507

Summary

When two real iOS devices are used with the same daemon and their agents are started at different times, the second device silently sends all of its commands to the first device's agent. Device info, screenshots, taps and the MJPEG stream for device B actually come from / act on device A until the daemon exits.

Verified on two real USB iPhones (iPhone 11 Pro and iPhone 12 Pro Max) on 1.0.13, and present in 1.0.19 (latest) and on main at 7e9699e.

Steps to reproduce

1. Connect two real iOS devices with different screen sizes (375x812 and 428x926 in the test).
2. Wait for the daemon to discover both. Call StartAgent on device A and wait until it succeeds.
3. Then call StartAgent on device B.
4. Ask device B for its device info or a screenshot.

Expected

Device B reports its own size (375x812, 1124x2436 px screenshots).

Actual

Device B reports device A's size (428x926, 1284x2778 px screenshots). Its commands are answered by device A's agent, so nothing ever fails visibly - the answers are just for the wrong device. The wrong binding persists until the daemon exits, because device objects are cached.

Root cause

1. Every real iOS device is created with a hardcoded client for localhost:8100:

   mobilecli/devices/ios.go

   Line 160 in 7e9699e

   device.deviceKitClient = devicekit.NewDeviceKitClient("localhost:8100")

2. StartAgent first checks that default client and returns early when anything answers:

   mobilecli/devices/ios.go

   Lines 503 to 505 in 7e9699e

   	if _, err := d.deviceKitClient.GetStatus(); err == nil {
   	return nil
   	}

3. A device's own agent forward takes the first free port in 8100-8299, which is 8100 for the first device:

   mobilecli/devices/ios.go

   Line 577 in 7e9699e

   port, err := findAvailablePortInRange(portRangeStart, portRangeEnd)

So when device B starts later, the GetStatus() check succeeds against device A's already-running agent on 8100, StartAgent returns early, and B never gets its own forwarder or client.

This only shows when the agents start at different times, which is why it can appear intermittent.

Affected versions

• 1.0.13
• 1.0.19 (latest)
• main (7e9699e)

Related

mobile-next/mobile-mcp#253 (closed 2025-09-05 with "multiple iOS devices work now") reported a similar symptom earlier. This appears to be a separate remaining path - the default localhost:8100 client means the second device never sets up its own forward when the agents start at different times - so opening this as a new ticket as requested there.

A fix is being prepared: stop creating the default localhost:8100 client, only trust GetStatus through the device's own running forwarder, fail safe when no agent client exists for the device yet, plus Go regression tests. Happy to send it as a PR.