Aiden Extends Phone Bridge to Remote Mobile Agent Benchmarks

Major Update: We merged PR #636, PR #643, PR #655, and PR #656. This merged change set extends environment bridge mode so it can proxy Aiden App Phone Bridge traffic between a bridge Agent and a remote Agent, creating a more direct route for real-device benchmark relay workflows.

The problem we fixed

The bridge Agent remains the endpoint your Aiden App connects to for Phone Bridge traffic. When an environment bridge endpoint is configured, the bridge Agent can proxy eligible traffic to the remote Agent through that configured route.

Foreground traffic uses bidirectional WebSocket forwarding. This means the bridge can forward active Phone Bridge communication in both directions between the connected sides, rather than treating the session as a one-way command submission. The proxy also reports remote connection status, helping the Phone Bridge-facing side understand whether the remote route is connected.

Background traffic follows a different path. Commands use the configured environment bridge’s HTTP queue path, where they can be queued, polled, and routed toward the remote device environment. Available results return through the configured environment bridge route.

This is the core architectural improvement behind the remote Phone Bridge workflow: your Aiden App can address the bridge Agent while related traffic is relayed toward the remote Agent and its device environment.

What changes in Aiden command handling

The queue path now has clearer behavior when no work is waiting. Empty command polls return commands as an empty array, providing a defined no-command response for polling clients.

Clipboard writes also validate text before queueing. This adds input validation before clipboard-write content enters the background relay path. It does not establish that every accepted clipboard write has completed on a target device.

Input routing changes are specifically conditioned on an environment bridge endpoint being configured. Under that condition, iOS keyboard actions and enter_text skip local USB HID isolation and proceed through the remote input path. This is not a general change to local USB HID behavior when no environment bridge endpoint is configured.

Benchmark daemons can now relay Phone Bridge commands through the device environment Agent. That arrangement gives a mobile agent benchmark a route from the benchmark-side daemon through the device environment, instead of requiring the benchmark layer to act as the final device-control endpoint.

What you can do now through a real-device benchmark route

You can connect the Aiden App to the bridge Agent and exercise related command paths through a real-device benchmark route. The routed scope includes app-related interactions, URL capabilities, clipboard operations, calendar commands, contact commands, and local-notification capabilities.

For an Aiden App benchmark workflow, this means the bridge-facing connection can direct these command categories through the configured environment bridge and device environment Agent. The practical value is access to an additional routed exercise path for supported capabilities, not a claim that every capability has been validated across every benchmark setup.

Reviewed validation included Go tests and a manual clipboard_read round trip through benchmark relay mode. That manual result confirms one clipboard-read path was exercised through the relay route and returned through the expected flow.

The current boundary for routed commands and outcomes

This update is merged code with reviewed validation. It is not confirmation that the change is deployed to every device, benchmark environment, or Aiden App installation. It also does not establish complete benchmark coverage, universal iOS or Android compatibility, or a measured benchmark improvement.

Keep command handling states distinct. A queued acknowledgement indicates that the queue accepted or recognized a request. A routed command indicates that transport directed it through the configured environment bridge. Neither state alone proves that the remote Agent executed the command or that the target device completed the intended action.

A confirmed device-side outcome requires explicit returned evidence. You can use this new route to exercise supported capabilities through a real-device benchmark path, while treating each device result as separate from queue acceptance and command routing.