ACP UI's web build keeps agent API keys in localStorage and loads Application Insights

The web build keeps per-agent configuration in browser localStorage

The configuration table gives a path per platform, and the web row is the odd one out. Windows keeps `agents.json` under `%APPDATA%\acp-ui`, macOS under `~/Library/Application Support/acp-ui`, Linux under `~/.config/acp-ui`, and Android at a path inside the app's private data directory. The web build keeps the same file's contents in browser `localStorage` under the key `acp-ui:agents`, managed through the in-app Settings dialog. The feature list is what makes that worth pausing on: one of the entries is per-agent environment variables, described as API keys and settings, and another is hot-reload config. So a hosted page on a GitHub Pages origin holds the credentials for every agent you have configured, in the one storage mechanism a browser deliberately leaves readable by any script on the origin. Nothing in the visible text says the web build encrypts it, and nothing says it does not.

The same web build depends on Microsoft Application Insights

The dependency list has eleven runtime entries, and one of them is `@microsoft/applicationinsights-web`, sitting alongside the protocol SDK, the Tauri API and plugins, `marked` for Markdown, Pinia, Vue and Vue Router. It is a client-side telemetry library, and it is a dependency of the build that also serves from a static host with no server-side component. The visible documentation does not describe what is collected, whether it is enabled by default, or how to turn it off, and the traffic monitor feature, which inspects protocol messages in real time, sits in the same interface. None of that makes the dependency wrong on its own, but it is a question a reader has to answer before putting agent credentials in that build's local storage, and the answer is not written down in the pages available here. The desktop and mobile builds have no such dependency in the list.

A page served over HTTPS cannot open a ws:// agent on your LAN

The browser build is genuinely useful and genuinely constrained. It offers the same chat, sessions, permissions and traffic monitor as the native apps, and omits exactly two things: local stdio agents and host filesystem access, both of which need a subprocess a browser tab cannot start. What remains is a WebSocket client, and that runs into the mixed-content rule. Pages served over HTTPS can only open `wss://` URLs, so the hosted app at `acp-ui.github.io` cannot connect to a plain `ws://` agent on your local network. The two documented workarounds are to run the bundle yourself with `npm run preview:web` or to put a `wss://` tunnel in front of the agent, and the same note says the setup works for the web build as for a phone. Stdio agents are also filtered out of the configuration list in the browser, since they cannot run there.

The macOS build is un-notarized and the documented fix strips the quarantine attribute

The macOS release note is the most candid part of the installation section. The disk images are ad-hoc signed and not notarized, because there is no paid Apple Developer account, so on first launch macOS shows a dialog saying it could not verify the app is free of malware. The text is clear that the app is not damaged and that this is Gatekeeper's standard warning for an un-notarized app, and it gives three ways past it. The terminal route is one command, run once after installing or upgrading:

xattr -dr com.apple.quarantine /Applications/acp-ui.app

The graphical routes are System Settings, Privacy and Security, then Open Anyway on macOS 15 Sequoia and later, or a Control-click, Open, Open in Finder on macOS 14 Sonoma and earlier. All three work. The reason to think about it first is that the terminal instruction is word for word the one a user would run for an app that genuinely is infected, so a reader who trusts the project is also being asked to disable the check that would catch the case where it should not be trusted. The Windows, Linux and Android builds are distributed as ordinary installers.

The Codex adapter is maintained by Zed Industries, and four packages are unscoped

Eleven agents are pre-configured, each with the package the client launches. Nine are scoped: `@github/copilot-language-server` for GitHub Copilot, `@agentclientprotocol/claude-agent-acp` for Claude Code, `@google/gemini-cli`, `@qwen-code/qwen-code`, `@augmentcode/auggie`, `@qoder-ai/qodercli`, and `@zed-industries/codex-acp` for Codex CLI. Four are bare names: `opencode-ai`, `openclaw`, `kiro-cli` and `hermes`. The Codex row is the one to notice. The agent is called Codex CLI, the package is `@zed-industries/codex-acp`, and it lives in a repository under the Zed Industries organisation, so the ACP bridge for Codex comes from the editor vendor rather than from the model's own author. The mix of scoped and unscoped identifiers is the other detail: an unscoped name is a bare global name on the registry, so a collision is possible in a way it is not for the scoped ones.

A Microsoft Store badge sits above an install table that never mentions it

The first element of the readme is a link to a Microsoft Store listing, with an app badge image. The installation table that follows sends Windows users to GitHub Releases for an `.msi` installer or an NSIS `.exe`. The store listing is not in the table, and the table is what a reader scanning for their platform will use. The same asymmetry shows up on mobile. Android is an `.apk` from Releases that you sideload by allowing unknown apps, and iOS has no prebuilt binary at all, only a build from source with Xcode. So the six-platform claim in the feature list is accurate as a list of targets and uneven as a list of distribution channels: two platforms have a store or a signed path, two need sideloading, one needs a local build, and Windows has both a badge and a release download with nothing connecting them.

Sixteen patch releases in three weeks, then four months without one

The release history is dense and then stops. v0.1.14 shipped on 2 May 2026, v0.1.15 on 10 May, and v0.1.16 on 25 May, and the manifest version matches the newest tag at 0.1.16. The last commit on the default branch main is dated 25 May 2026 as well, sixteen minutes before the release was published, so that tag reflects the tip rather than trailing it. After that, four months. The project is marked as not archived, and the protocol it implements is one that several of the agents it configures are still changing, so the silence is worth weighing against the pace of the ecosystem it sits in. Two smaller details in the feature list say the same kind of thing about the code: the model picker is labelled as an unstable API, and hot-reload config is marked desktop only, which is the one feature the web build cannot have.

The keep-alive is a JSON-RPC ping every 25 seconds

Two features exist because of how the transport behaves, and both are more specific than the rest of the list. Idle keep-alive sends a JSON-RPC `$/ping` heartbeat every 25 seconds so that NAT and proxy idle timeouts do not drop the WebSocket, which is the kind of detail that only gets written down after it has been debugged. Foreground reconnect, on mobile and the web, automatically reattaches to the session when the app or the tab regains focus, which covers the case where a phone locked or a browser tab was discarded. Everything else in the interface is conventional chat surface: Markdown with syntax highlighting and tool call visualisation, slash commands, collapsible agent thinking, session modes such as ask, code and architect, permission controls to approve or deny before execution, and the traffic monitor for reading the protocol messages as they go past.

Editorial conclusion

Reach for ACP UI if you want one interface across several coding agents and you value the traffic monitor, which shows the raw protocol messages and is the best way to understand what an agent is actually asking for. Two platform facts decide where you can run it. The web build cannot reach a local agent on your network, because a page served over HTTPS may only open `wss://` URLs, so either serve the bundle yourself with `npm run preview:web` or put a tunnel in front. And the web build keeps per-agent configuration, which the feature list says carries API keys, in browser localStorage under the key `acp-ui:agents`, on a GitHub Pages origin, in the same build that depends on Application Insights; nothing in the visible documentation says what that dependency reports or how to turn it off. If either of those matters for your setup, use a desktop build instead. The newest release is v0.1.16 from 25 May 2026 and the last commit on the default branch main carries the same date.

Frequently asked questions

Official sources

1. formulahendry/acp-ui on GitHub
2. License: MIT
3. Project website
4. README
5. Releases