Phone Control (drive an Android phone from Omniscio)

What it is

What it is

An optional, in-development feature that lets Omniscio drive a connected Android phone over the local Android Debug Bridge (adb). It has two surfaces, both off the same feature flag:

1. Agent tools — with the feature on, any Omniscio session gets a set of mobile_* tools (tap, swipe, type, take a screenshot, list/launch/install apps, press buttons, open a URL) via the bundled @mobilenext/mobile-mcp MCP server. An agent can then operate the phone as part of a task.
2. The "Phone" panel — a desktop sidebar panel (Developer Tools group) where you drive a connected device yourself: pick the device, watch its screen live, wake it, and launch any installed app by clicking.

Where to find it

Once revealed, a Phone row appears under the Developer Tools sidebar group. The reveal switch is Settings → Lab → Phone Control.

How it behaves

Enabling it

It ships hidden and off by default. Reveal it via Settings → Lab → Phone Control (phoneControlEnabled) or the env flag AMC_SHOW_PHONE_CONTROL=1. Once on, a Phone row appears under the Developer Tools sidebar group, and agent sessions start getting the mobile_* tools.

First-enable setup is automatic. The moment you turn it on, Omniscio provisions the runtime with no manual install: it detects an existing adb (Android platform-tools) and the mobile-mcp runtime, and if either is missing it downloads them once into its own data folder. Until the runtime is present, the agent tools stay dormant (a session never gets a phone tool whose runtime isn't ready).

Connecting a phone

• USB: plug the phone in and turn on USB debugging (Developer options), then accept the "Allow USB debugging" prompt on the phone.
• Wireless: pair over adb (host:port) and use the panel's connect action; the panel remembers the link and reconnects it if it drops.

The Phone panel

• Device picker — every connected device (adb devices); pick which one the panel drives.
• Live screen — a screenshot of the selected device, re-captured every couple of seconds, shown as a phone-shaped image.
• Wake — wakes the device's screen.
• Apps — the device's third-party (user-installed) apps; click Launch to open one.
• Refresh — re-scan for connected devices.

The panel does no background work when it's closed — the polling is tied to the open panel.

Wireless auto-reconnect

A wireless adb link drops silently (the device just disappears). The panel remembers every wireless address you successfully connected to this session and, on its device poll, quietly re-issues adb connect for any that dropped — so a flaky Wi-Fi link self-heals without you re-typing the address. USB devices are never "reconnected" this way (they don't need it).

Android vs iPhone

Phone Control drives Android locally on Windows, macOS, and Linux. iPhone is not supported locally — Apple restricts iPhone automation to a Mac, so there is no local iPhone path from a Windows PC. A paid Mobile Next Cloud route (drive a real iOS/Android device in the cloud) is a possible future addition, not part of this version.

Safety & scope

• Desktop-only. Both surfaces shell out to a local adb binary, so the panel and the agent tools are refused over the mobile/web bridge — you use them from the desktop app.
• Off by default, behind the in-development gate; every phone command refuses to run unless the feature is on.
• No shell, strict input. Device ids, package names, and addresses are validated against a strict character allowlist and passed to adb as separate arguments (never through a shell), so a hostile device or app name can't inject a command.
• No secrets, no telemetry. The MCP entry writes no credentials into the session config, and the mobile-mcp server's usage telemetry is disabled.

Related

• agent-tools.md — the tool surface an agent session gains when Phone Control is on.
• drive-amc-cockpit.md — the other tool that drives a real UI from a session, pointed at the app itself.