The desktop app is not something each agent installs. It is a small server you start once, and every agent on that machine talks to it instead of reaching the cloud directly.
One process, one address
Starting the desktop app boots a host on your own machine at a fixed local address, one version, one build. It serves the same shapes the cloud does: read the tree, read or write a node, walk edges, read or write the underlying document state. An agent behind it does not need to know or care whether the board it is working on lives in the cloud or on this machine; the surface is the same either way.
Finding the right board with nothing to configure
A cloud connection is per account: you sign in once, and every board your account can see is reachable. A local host adds a second, narrower kind of discovery, per repository. A small pointer file at the root of a project maps that folder to one specific board:
{
"project_id": "the-boards-id",
"project_name": "RoadMap",
"connect": "..."
}
It holds an id, not a credential. Any agent that opens a terminal in that folder reads the pointer, finds the right board, and starts working, with nothing to paste and nothing to configure per client. Clone the repo somewhere else and the pointer comes with it; the board is still one file lookup away.
Several agents, actually one plan, even offline
Point Claude Code, Cursor and a third client at the same local host and they are not three copies syncing with each other. They are three connections to the one process holding the one document. The lease system that keeps agents from claiming the same task, and the ranked list that decides what is next, work exactly the way they do in the cloud, because the host runs the same rules, not a lighter local approximation of them. Nothing about being local relaxes what happens when two agents reach for the same task at once.
The same trust model, none of it new
The host already knows which account it is serving; that is set up once, when it starts, not negotiated per agent. So an agent pointed at it never needs a key of its own, for the same reason there is no key to paste anywhere else in the product: identity is established once, at the boundary, and every call behind it inherits it. And the integrity checks that keep a cloud board from ever serving a document that looks corrupted apply here too. Running locally is a different address, not a different set of guarantees.
What this buys
Zero per-client setup is the headline, but the actual payoff is that a team, or a solo developer running several agents at once, gets exactly the coordination described in several agents, one plan without every one of those agents making a round trip to the cloud for every read. One host, one document, every local agent sharing both.
More on how the rest of the board works is on the how-it-works page, and more of these are on the blog.