ACP UI now supports iOS and Android, allowing you to connect a native mobile interface to any ACP-compatible agent running on a desktop or server. This solves the poor remote-control experience of mobile agent access. Keywords: ACP, WebSocket, Copilot CLI.
Technical Specifications at a Glance
| Parameter | Details |
|---|---|
| Project Name | ACP UI |
| Positioning | Cross-platform agent client with newly added iOS/Android support |
| Primary Language | Not explicitly stated in the source; the repository is a GUI application project |
| Communication Protocols | ACP, WebSocket |
| Typical Target Agents | Claude, Codex, Copilot, Gemini, OpenCode |
| Desktop Support | Windows / macOS / Linux |
| Mobile Support | iOS / Android |
| Relay Tools | @rebornix/stdio-to-ws, Microsoft Dev Tunnels |
| Open Source Repository | https://github.com/formulahendry/acp-ui |
| GitHub Stars | Not provided in the source |
| Core Dependencies | Node.js, Copilot CLI, Dev Tunnels |
ACP UI Extends Remote Agent Access to Native Mobile Experiences
The author has already built three types of ACP clients: a VS Code extension, a cross-platform desktop UI, and WeChat ACP for WeChat. The key value of this update is that ACP UI now directly extends to iOS and Android.
This means developers no longer need to rely on chat-style shells or constrained web containers. Instead, they can use a more native app-like interface on mobile to connect to any remote agent. For scenarios such as mobile inspection, remote task triggering, or lightweight interaction, this upgrade is highly practical.
This update matters because it connects your own agent to mobile
The core point is not simply that “AI works on a phone,” but that “your phone can connect to your own agent.” As long as the target agent supports ACP, you can connect to it through a unified protocol without being locked into a single vendor client.
Compared with mobile apps that support only local models or fixed services, ACP UI behaves more like a protocol entry point. The desktop side runs the agent, while the mobile side only connects, monitors, and operates it. The architecture is cleaner and better suited for team reuse.
The Android Demo Confirms That Remote Copilot CLI Access Works
AI Visual Insight: This image shows ACP UI actively running on an Android device. The left side contains the conversation or connection navigation area, while the right side shows the main agent interaction panel. The key signal is that the phone does not run Copilot CLI directly. Instead, it connects over the network to an agent process running on a Windows host, proving that the “mobile frontend + desktop agent” split architecture already works in practice.
Based on the source article, the demo environment uses a Redmi Android phone connected to Copilot CLI running on a Windows machine. This shows that the ACP UI mobile client does not depend on a specific cloud service. It can consume any remotely exposed ACP/WebSocket endpoint.
The connection path can be summarized in three layers
The first layer is the local agent process, such as copilot --acp. The second layer is the protocol bridge that converts stdio into WebSocket. The third layer is the ACP UI mobile client, which acts as the visual client that initiates the connection.
npx @rebornix/stdio-to-ws "copilot --acp" --port 3000 --persist --grace-period -1This command wraps Copilot CLI, which normally communicates over standard input and output, into a WebSocket service that can be accessed remotely.
Using stdio-to-ws Is the Key Step for Mobile Access
Many CLI agents expose only a stdio interface by default. That works well for local IDE integrations, but it is not suitable for direct mobile access. The value of @rebornix/stdio-to-ws is that it converts the CLI process into a network-accessible bridge service.
Here, --port 3000 specifies the listening port, --persist keeps the service running continuously, and --grace-period -1 reflects a long-lived session strategy that works well when mobile devices need to reconnect at any time.
You can expose the port with Dev Tunnels when the host has no public IP
If your computer does not have a publicly reachable IP address, the author recommends using Microsoft Dev Tunnels to expose local port 3000 externally. This is the second key step that enables a phone to access a desktop agent across networks.
devtunnel host -p 3000This command maps local port 3000 to an externally accessible tunnel address so that mobile devices can connect directly.
If you want anonymous access from Android for quick testing, you can use the following command:
devtunnel host -p 3000 --allow-anonymousThis command allows tunnel access without requiring an explicit sign-in. It is useful for fast validation, but you should evaluate your security strategy before using it in production.
The source article gives the tunnel URL format as `https://
-3000..devtunnels.ms`. When using it in ACP UI, you must change `https` to `wss` so the client connects over secure WebSocket. ## Entering the WebSocket Endpoint on Mobile Completes the Connection  **AI Visual Insight:** This image shows the ACP UI settings screen, with the WebSocket endpoint input field highlighted as the most important area. It shows that client onboarding is highly protocol-driven: the user only needs to enter a `wss://` endpoint to bind a remote agent, without understanding the underlying CLI, stdio transport, or port-forwarding details on the phone. On the settings page, the developer only needs to enter the final `wss://…devtunnels.ms/` address. This design keeps the complexity on the host side and reduces the mobile connection flow to a standard endpoint configuration. “`text wss:// -3000..devtunnels.ms/ “` This is the final WebSocket address format that the mobile client should use. The only essential change is rewriting the tunnel’s `https://` URL as `wss://`. ### The engineering value of this approach lies in protocol unification, not platform stacking ACP UI, VS Code ACP, and WeChat ACP all point to a more important trend: as long as an agent is ACP-compatible, the client form factor can vary freely. IDEs, desktop GUIs, WeChat, and native mobile apps are fundamentally just different interaction shells for ACP. For teams, this reduces the cost of multi-endpoint integration. For individual developers, it gives existing CLI agents stronger remote control capabilities without requiring business logic rewrites. ## Remote Control and Lightweight Operations Are the Best Current Use Cases This type of mobile access is especially suitable for temporarily checking agent status, remotely triggering tasks, handling lightweight commands during a commute, or performing basic interactions when opening a laptop is inconvenient. However, this does not mean a phone replaces desktop development. Complex code review, multi-file editing, and deep debugging remain much better suited to a desktop environment. The correct positioning of ACP UI is to extend agent reachability from desktop to mobile. ## FAQ ### 1. Which agents can ACP UI connect to? In theory, any target agent that supports ACP can be connected. The source article explicitly mentions mainstream agents such as Claude, Codex, Copilot, Gemini, and OpenCode. ### 2. Why convert stdio to WebSocket? Because many CLI agents expose only stdio by default, and a phone cannot consume that kind of interface directly. After conversion with `@rebornix/stdio-to-ws`, the mobile client can connect remotely through a standard WebSocket interface. ### 3. Can I still access an agent on my computer from my phone if I do not have a public IP? Yes. Use Microsoft Dev Tunnels to expose the local port, then change the generated address from `https://` to `wss://` and enter it into the ACP UI settings page to complete the connection. ## Core Summary This article reconstructs the ACP UI mobile release details and explains how it connects a native mobile interface to remote AI agents through WebSocket. It also provides a practical Android access workflow using `stdio-to-ws` and Microsoft Dev Tunnels.