Agmente: an iOS client for coding agents running on your own machine

What the app connects to

Agmente is described as an iOS client for coding agents. It connects to servers that speak ACP, the Agent Client Protocol, or the Codex app-server protocol, and it shows tool calls, results and conversation history on the device.

That is the whole product, and the design decision is in the second half of the sentence. Agmente is not an agent. It does not run a model, it does not execute code, and it does not have a model provider configured. It is a viewer and controller for an agent process that runs somewhere else, over a protocol that describes tool calls and results.

The list of agents it can connect to is given as a capability line: ACP agents including the Copilot CLI, Gemini CLI, Claude Code adapters, Qwen, Mistral Vibe and others, plus Codex app-server endpoints. The phrase and others is doing real work here, because the point of supporting a protocol rather than a set of products is that the list grows without the app changing.

The three things the app shows are the three things you would want to watch. Tool calls tell you what the agent decided to do. Results tell you what came back. The conversation history gives you the thread. On a phone, that is the difference between an agent you can supervise and one you have to take on faith.

The app is on the App Store as Agmente. It is written in Swift, MIT licensed, with the default branch main and no GitHub releases published. The last push was on 2026-05-31.

The remote path, and the tunnel in the middle

The remote agent setup is the part of the readme with the most detail, and it is where the security decisions live.

The model is that you start an ACP or Codex app-server agent on a remote host and expose it over wss://. The port is bridged with a websocket wrapper, and the readme gives the command to run on the remote host:

npx -y @rebornix/stdio-to-ws --persist --grace-period 604800 "copilot --acp" --port 8765

The name of the package says what it does. The agent normally speaks over stdio, and stdio-to-ws repackages that as a websocket server, so the phone can reach a process that was designed to be driven by a terminal. The --persist flag keeps the agent process alive across connections and the grace period of 604800 seconds is seven days, which tells you the intent: an agent that stays up for a week, not one that dies with the socket. The quoted command is the agent invocation, here the Copilot CLI in ACP mode.

Stopping it is a separate command, and it is deliberately forceful:

pkill -9 -f "stdio-to-ws.*8765"

That is SIGKILL by pattern match, which is the kind of thing you write when you want the port free immediately and do not care about graceful shutdown of a long-running agent session.

The remaining half of the security story is the authentication. The readme says to expose the port behind TLS and connect from Agmente using wss://your-host, and to use bearer tokens and or Cloudflare Access service tokens when the endpoint is protected. The key capabilities list the same thing: optional Cloudflare Tunnel plus Access credentials for remote access.

So the intended deployment is a private tunnel rather than a port you open to the internet. Cloudflare Tunnel gives you a TLS-terminated public hostname that only Cloudflare can reach into, and Access adds an identity layer in front of it. The bearer token is the application-level credential, and the Access service token is the one that gets you through the gateway. That is a sensible arrangement, but it does mean the security of your remote agent depends on the tunnel being configured correctly, and a websocket server with a --grace-period of a week is a long-lived thing to leave running.

The repository, and how the client is put together

The repository layout is three directories, which is a clear statement of what the project is.

The Agmente/ directory holds the iOS app source. The ACPClient/ directory is a Swift package used by the app, and the AppServerClient/ directory holds Codex app-server client support. So the protocol clients are separated from the app rather than tangled into it, which means the ACP client can be tested on its own and could be reused.

The test structure follows the same split. There are AgmenteTests/ and AgmenteUITests/ directories alongside the app, and the ACPClient package has its own tests, run with a plain swift test:

swift test --package-path ACPClient

The app tests use xcodebuild with an explicit simulator destination:

xcodebuild -project Agmente.xcodeproj \
  -scheme Agmente \
  -destination "platform=iOS Simulator,id=<SIMULATOR_UDID>" \
  test

There is also an Agmente.xctestplan at the root, which is how a scheme can hold more than one test configuration, and a scripts/ directory and an e2e/ directory, the latter suggesting end-to-end coverage beyond the unit level.

The repository also carries the files you would expect from a project that is being developed with coding assistants in the loop. There is a .agents/ directory, an .mcp.json file at the root, a .xcodebuildmcp/ directory, a CLAUDE.md file, an Agents.md file, and an .agmente.paths.example file. Agents.md is the one the readme points at for local setup, while setup.md holds the full remote setup.

On the governance side there is a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a SECURITY.md, a CHANGELOG.md, and a THIRD_PARTY_LICENSES.md. That last file is the one to look at if you plan to ship this, because it records the licences of the third-party code the app bundles, which for an app that embeds protocol clients from several vendors is exactly the document you need before distribution.

Building and running the app

The requirements are short: Xcode, with the latest stable recommended, and macOS for iOS builds. There is no mention of a server component, a backend or an account, which is consistent with an app that talks directly to an agent endpoint you control.

Building in the GUI is the normal route. Open Agmente.xcodeproj in Xcode and run the Agmente scheme on a simulator or device.

The command line alternative is given for CI and for repeatable builds:

xcodebuild -project Agmente.xcodeproj -scheme Agmente -destination 'platform=iOS Simulator,name=iPhone 16'

That destination names a simulator by model name, which is convenient locally and brittle in CI, where the device model may not exist on the runner. The test command in the readme handles this the other way round and takes a simulator UDID, which is the form that works when the runner has no iPhone 16.

Nothing in the readme describes how the app is configured once installed. There is no walkthrough of entering an endpoint URL, of storing a bearer token, or of pairing with a Cloudflare Access service token. The setup instructions in setup.md and Agents.md are framed around the agent side, running the agent and exposing it, so the app's own configuration flow is either obvious from the interface or under-documented.

For a project at this stage, with the last push on 2026-05-31 and no tagged releases, that is worth checking on a device before you build a workflow around it.

Where Agmente is the wrong choice

The first limitation is the protocol dependency, and it is absolute. Agmente can talk to ACP servers and to the Codex app-server protocol, and nothing else is described. If the agent you use does not expose either endpoint, the app does not help you, and there is no plugin or adapter mechanism in the repository that would let you add one. The list of supported agents includes the Copilot CLI, Gemini CLI, Claude Code adapters, Qwen and Mistral Vibe, but that list is a list of things that already speak ACP, not evidence of broader coverage.

The second is that you are hosting the agent yourself. There is no hosted option, no account, and no service in the middle. That is a feature for a developer who already has a machine running an agent, and a significant amount of work for anyone who does not, since the remote path needs a host, a tunnel, TLS and a token, and a long-lived process with a seven-day grace period.

The third is the security surface of a phone-facing agent. An agent that can call tools can edit files, run commands and, depending on its configuration, do things you would not want triggered from a phone on a train. The readme's security story is a bearer token and optional Cloudflare Access. That is reasonable, but it means the access control is exactly as strong as the token handling, and a stolen phone with an unlocked app is a plausible route to an agent with shell access. The SECURITY.md file is where you would look for the project's own view, and it is not summarised in the readme.

The fourth is the age and the release state. The last push was on 2026-05-31, there are no GitHub releases, and the app is distributed through the App Store rather than as a buildable artefact, so you cannot easily inspect what is running on the device or pin a version.

The fifth is the scope of what the app does. It shows tool calls, results and history, and the capabilities list mentions remote access configuration, but there is no description of steering the agent, approving actions, or editing files from the device. If you need to review and approve a change on the phone, that is the feature to check for, and the readme does not claim it.

Editorial conclusion

Agmente fits a developer who runs a coding agent on a machine with more compute or a longer-lived session than their phone has, and who wants to see what the agent is doing and steer it remotely, since the app speaks both ACP and the Codex app-server protocol and the remote path goes through a websocket tunnel with bearer tokens. It is the wrong choice if you want to use a hosted agent service, since the app connects to an agent you host yourself, and it is the wrong choice if your agent does not speak either protocol, because there is no adapter layer described in the repository. Before installing it, read setup.md and the Agents.md file for the local variant, confirm that the agent you want to use exposes an ACP or app-server endpoint, and note that the last push was on 2026-05-31 with no GitHub releases published.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. rebornix/Agmente on GitHub