Local Runtime
not yet releasedOne binary. It finds a model you already run, gives each agent its own identity and keys, answers from your documents, and can be consulted by another firm's agent without handing over the conversation.
Everything below is implemented and running, but binaries are not published yet — there is nothing to download. What you can use today is the SDK, on npm and PyPI. This page describes the runtime so the documentation matches the software, not a release date.
Running it
The runtime serves its own interface over loopback. Starting it prints a URL carrying a one-time token; nothing is exposed to the network unless you ask for it.
aroha upA workspace lives at ~/.aroha (override with AROHA_HOME) and holds your agents, their keys, their documents, and the audit log. One runtime serves one workspace: a second aroha up against the same workspace attaches to the first rather than starting a rival copy.
The desktop app
A native window around the same runtime, for people who would rather not keep a terminal open. It is deliberately thin: it starts the runtime, reads the URL the runtime reports, and shows that page in the window. There is no second interface to keep in sync.
It is built on Tauri, so it uses the webview your operating system already ships rather than bundling a browser engine — the shell is single-digit megabytes against roughly 120 MB for the Electron equivalent. For a product whose argument is that nothing leaves your machine, shipping a second browser to display a page served from 127.0.0.1 is hard to justify.
Closing the window stops the runtime it started — but only that one. If a runtime was already serving the workspace, the window attaches to it and leaves it running on exit, because taking down a session you did not start is not a reasonable thing for a window to do.
MCP servers, local and remote
The runtime speaks both MCP transports. A local server is a command it runs as a subprocess. A remote server is an HTTPS endpoint, which is what almost everything published actually is — including every server in the Aroha marketplace, browsable from the MCP panel and installable in one click.
The catalogue is fetched by the runtime rather than by the page. The browser would otherwise need a CORS grant from a registry the runtime does not own, and every visit would tell that registry a browser on your machine was shopping. An unreachable catalogue shows an empty list rather than an error, because being offline is a normal state here.
Why remote servers are trusted less
A local server runs your copy of a package you chose, and its arguments never leave the machine. A remote server is someone else's computer: it sees every argument you pass it, and it can change what it offers between two calls in the same conversation. The runtime treats those differently.
| Local (stdio) | Remote (HTTP) | |
|---|---|---|
| Where it runs | A subprocess on your machine | Someone else's server |
| Tool arguments | Never leave the machine | Sent to that server on every call |
| What it offers | Only when you update the package | Can change between two calls in one conversation |
| Unknown tools | Runs unattended, subject to your own guard rules | Unrecognised tools ask once, then are remembered |
Aroha keeps a taxonomy of well-known capabilities with a risk tier and a reversibility for each. A tool it recognises as low risk and fully reversible runs without ceremony wherever it lives. A tool it does not recognise — which is most third-party tools, since servers name things whatever they like — is treated as unknown rather than as fine.
On a local server that is nothing to act on. On a remote one it means the first call asks you, naming the server and saying plainly that the arguments will be sent to it. Approve once and it is remembered, so the cost is one prompt per tool rather than friction on every call. Your own mcp-guard rules are unaffected: a rule that says “always ask” keeps asking, because one approval must not quietly delete a rule you wrote.
When a remote server changes
Remembering an approval creates a second problem: what you approved can change afterwards. So approvals are recorded against a fingerprint of the server's tool list — names, descriptions, and argument schemas. If any of it changes, the remembered approvals are dropped and the next call asks again.
Descriptions are in that fingerprint deliberately. A tool's description is injected verbatim into the model's prompt, so rewriting it is rewriting an instruction to your agent even when the tool itself is untouched. The MCP panel marks a server whose tools changed, because a tool that suddenly starts asking again should look like the defence working rather than a bug.