ACP UI: a cross-platform front end for the Agent Client Protocol
A modern, cross-platform client for the Agent Client Protocol (ACP) on desktop, mobile, and the web — connect to any ACP-compatible AI agent (Claude, Codex, Copilot, Qwen, Gemini, OpenCode, OpenClaw and more)
At a glance
- What is it?
- ACP UI is a Vue-based client that speaks ACP over stdio or WebSocket and puts a chat interface in front of Claude Code, Copilot, Gemini CLI and other agents. The hard part is not the UI; it is deciding whether a browser tab or a phone is the right place to run your coding agent.
- Who is it for?
- Adopt ACP UI if you want one chat surface across desktop, browser and phone for agents you already have installed, and if you accept that the web and mobile builds cannot spawn local stdio agents or touch the host filesystem. Skip it if your workflow depends on a single vendor's own client, or if you need a signed and notarized macOS build without touching the terminal.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 114 days ago.
- What is it written in?
- Mainly Vue, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ACP UI fills between agents and the terminal
Coding agents such as Claude Code, Gemini CLI and Codex CLI each ship their own command-line interface and their own way of holding a conversation. The Agent Client Protocol defines a common wire format for that conversation, so a client can talk to any agent that implements it. ACP UI is that client. It is a Vue application that presents sessions, streaming replies, tool call visualisations and permission prompts in a graphical window instead of a terminal scrollback.
The target user is someone who already runs one or more of these agents and wants a consistent interface across machines. The README lists eleven pre-configured agents, including GitHub Copilot, Claude Code, Gemini CLI, Qwen Code, Auggie CLI, Qoder CLI, Codex CLI, OpenCode, OpenClaw, Kiro CLI and Hermes Agent. Each entry is a package name, so the client is not bundling the agents themselves. It is a shell that launches or connects to them. That distinction matters for anyone evaluating install size and dependency surface.
Stdio, WebSocket and what each transport can reach
There are two connection paths, and they are not equivalent. On desktop, ACP UI can start an agent as a local subprocess and speak ACP over stdio. That is what gives the desktop build access to the host filesystem, and it is why the README states that the web build omits local stdio agents and host filesystem access, since a browser tab cannot spawn a subprocess.
The second path is WebSocket. A remote agent listens on ws:// or wss:// and the client connects to it. The README describes this as the way to talk to agents on another machine, and it is the only path available to the Android APK, the iOS build and the web app. Two operational details are documented rather than implied. First, a page served over HTTPS can only open wss:// URLs because of the browser mixed-content rule, so LAN access over plain ws:// requires running the bundle locally with npm run preview:web or putting a wss:// tunnel in front of it. Second, on mobile and the web the client sends a JSON-RPC $/ping heartbeat every 25 seconds so that NAT and proxy idle timeouts do not silently drop the socket. That heartbeat is a concrete design decision: it trades a small amount of background traffic for session survival on flaky networks.
Configuration files, hot reload and the browser exception
Agent definitions live in a JSON file whose location depends on the platform. On Windows it is %APPDATA%\acp-ui\agents.json, on macOS ~/Library/Application Support/acp-ui/agents.json, and on Linux ~/.config/acp-ui/agents.json. On Android the path is /data/data/formulahendry.acp_ui/files/agents.json, and on iOS it sits in the app sandbox. On desktop these files are editable directly, and the README lists hot-reload config as a desktop feature, so changes to agent configuration do not require a restart.
The web build breaks that pattern. Its configuration lives in browser localStorage under the key acp-ui:agents, and the README notes that on mobile and the web the config file is not user-accessible, so agents are added and edited through the in-app Settings UI. If you are standardising agent configuration across a team, that difference matters. Desktop config can be version-controlled and copied between machines. Browser localStorage cannot, and it is tied to one browser profile on one origin. There is no documented export or import path for the web build in the material provided.
Installing on Windows, Linux and Android versus macOS and iOS
Release artifacts are conventional. Windows gets an .msi installer or an NSIS .exe. Linux gets .deb, .AppImage or .rpm packages for both x64 and ARM64. macOS gets separate .dmg files for Apple Silicon and Intel. Android gets an .apk that must be sideloaded through the system's install-unknown-apps flow. iOS has no prebuilt binary at all and must be built from source with Xcode, which the README points to under a Building for iOS heading.
The macOS situation deserves attention before you download anything. The .dmg builds are ad-hoc signed but not notarized, because there is no paid Apple Developer account behind them. On first launch Gatekeeper will show a dialog stating that Apple could not verify the app is free of malware. The README is explicit that the app is not damaged and that this is the standard warning for un-notarized software. The documented fix is a single command run after installing or upgrading: xattr -dr com.apple.quarantine /Applications/acp-ui.app. Two GUI alternatives are given, one for macOS 15 Sequoia and later through System Settings, Privacy & Security, Open Anyway, and one for macOS 14 Sonoma and earlier through right-clicking the app in Finder and choosing Open. If your organisation blocks unsigned or un-notarized binaries outright, none of these workarounds apply and the macOS build is simply not deployable.
Permission prompts, session modes and the unstable model picker
The feature list describes permission controls that let you approve or deny agent actions before execution, session modes you can switch between (the README gives ask, code and architect as examples), a collapsible view of the agent's reasoning, slash commands, and a traffic monitor for inspecting ACP protocol messages in real time. The traffic monitor is the most useful of these for anyone debugging an integration, since it exposes the wire traffic rather than a summary of it.
One item is flagged in the README itself: the model picker is marked as an unstable API. Treat that as a statement about the underlying protocol surface rather than a temporary documentation gap. If your workflow depends on programmatically selecting a model per session, expect that part of the interface to move. Session management covers creating, resuming and managing conversations, and on mobile and the web the client reattaches to a session automatically when the app or tab regains focus. That reconnect behaviour is paired with the 25-second ping, so the two features are designed to work together rather than independently.
Where ACP UI is the wrong tool
The browser and mobile builds cannot spawn local agents. If your agent needs to read and write files in a working directory on your machine, the web app and the Android APK will not do it, and the README says so directly when it describes the web build as omitting local stdio agents and host filesystem access. Running the desktop build is not optional for that class of work.
The second limitation is configuration portability. Desktop agents.json is a real file you can inspect, diff and back up. The web build's localStorage entry is none of those things. A team that standardises on the browser client inherits a configuration model that resists review.
The third is distribution friction. An un-notarized macOS build and a sideloaded Android APK both require users to override a platform security default. That is a per-user, per-machine action, and it recurs on each upgrade for the macOS quarantine attribute unless the command is run again. For a tool that connects to agents holding API keys, the override is not a trivial ask, and the README does not describe any code-signing roadmap that would remove it.
ACP UI against a vendor's own client
The obvious alternative is the first-party interface each agent ships with. Claude Code, Gemini CLI and Codex CLI all come with their own clients, and those clients are maintained by the same team that maintains the agent, so protocol changes land in both at once. ACP UI sits one layer out. It depends on the agent implementing ACP correctly, and it depends on its own release cadence keeping up. The repository shows three releases in May 2026, v0.1.14 through v0.1.16, which is a reasonably tight cadence for a project at version 0.1.x, but it is still a third party tracking an interface it does not control.
The difference in approach is breadth against depth. A vendor client can expose every feature the agent has, including ones ACP does not cover. ACP UI offers one interface across eleven agents and five platform families, and the price of that breadth is the parts of each agent that fall outside the protocol. If you use exactly one agent and want everything it can do, the vendor client is the safer choice. If you switch between agents, or want the same session view on a laptop and a phone, the protocol layer is what buys you that.
Licence, maintenance cost and what to check first
ACP UI is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive licence with no copyleft obligation on your own code. It says nothing about the agents you connect to, and those carry their own licences and their own terms for API usage, so the MIT grant here covers the client only. This is a description of the licence text, not legal advice.
Maintenance cost has three parts. The client itself updates through the normal release channel, with the macOS quarantine command reapplied after each upgrade. The agent packages are separate dependencies that you install and update independently, and their versions are not pinned by ACP UI as far as the README shows. The model picker is documented as unstable, so any automation built on it should be expected to need revision. Before adopting, confirm that your intended agent appears in the default agent table or can be added through Settings, and confirm that the transport you need is available on the platform you are targeting. A desktop install with a local agent over stdio is the best-supported path. A browser session against a remote agent is supported, but only over wss:// when the page itself is served over HTTPS.
Editorial conclusion
Adopt ACP UI if you want one chat surface across desktop, browser and phone for agents you already have installed, and if you accept that the web and mobile builds cannot spawn local stdio agents or touch the host filesystem. Skip it if your workflow depends on a single vendor's own client, or if you need a signed and notarized macOS build without touching the terminal. Before installing, verify two things: that the agent you intend to use is listed in the default agent table or can be added through Settings, and that your network path to a remote agent is wss:// rather than ws:// when the page is served over HTTPS.
Community notes