The Developer Platform

Build apps on top of MeshHold.

Build apps on top of MeshHold. REST API, Server-Sent Events stream, the mesh protocols, and a Claude Code / OpenCode / Gemini CLI / Codex agent surface.

REST API

All endpoints live under /api/v1/. Bearer-token auth (the same token the web UI uses). Configurable bind on api.listen_addr.

Key endpoints:

• GET /api/v1/vaults — list vaults
• POST /api/v1/vaults — create
• GET /api/v1/vaults/{id}/files/{path} / DELETE … — read / delete a file
• POST /api/v1/vaults/{id}/upload/{path} — upload one
• GET /api/v1/events/stream — global SSE for chat and agent-activity events

The full reference is the REST API reference.

SSE event stream

const es = new EventSource('/api/v1/events/stream?token=...');
es.addEventListener('chat_message', (e) => {
  const m = JSON.parse(e.data);
  console.log(m.room_id, m.sender_node_id, m.message_type);
});

The event says that a message arrived, not what it says: fetch the text from GET /api/v1/rooms/{room_id}/messages.

Mesh protocol IDs

Nodes talk to each other over MeshHold's own mesh layer. Every stream opens with a protocol ID, and the version is part of the ID — a node that does not serve one answers "unsupported" rather than guessing. What a node serves at this release:

MCP / Claude Code integration

MeshHold embeds Claude Code as a vault-analog. Each instance has its own encrypted state, syncs across nodes, and proxies over the mesh.

meshhold agent create --type claude --name "Claude 1"
meshhold agent workspace add <instance-id> ~/projects/foo
meshhold agent share <instance-id>

See the Claude rollout devlog for details, and the comparison with Paseo, Happy Coder, CloudCLI and VibeTunnel for how this surface lines up against the dedicated mobile agent clients.

OpenCode driver

The same agent surface drives OpenCode through its native HTTP/SSE serve mode. Pick the driver in the Add-Instance UI; provider OAuth flows are in Settings → Providers.

Gemini CLI driver

Google's Gemini CLI is driven over ACP (the Agent Client Protocol — newline-delimited JSON-RPC 2.0 over stdio), spawned as gemini --acp. Every instance is fully isolated: its own ~/.gemini (a per-instance HOME override), its own long-running process, and its own API key stored in that instance's ~/.gemini/.env — so several accounts coexist on one node. Streaming updates and tool-call approvals (session/request_permission maps to the same Allow / Deny cards as the other drivers) flow through the one agent surface. Add a Gemini API key under Settings → Providers.

MCP for gemini is not yet wired. Gemini's ACP mode blocks session creation while an MCP server is configured, so the MCP tab is hidden for gemini pending an ACP-native fix. Claude, OpenCode and Codex support MCP normally.

Codex driver

OpenAI's Codex is driven over its app-server protocol — JSON-RPC 2.0 over stdio, one long-lived process per instance. Each instance gets its own CODEX_HOME, so its sign-in, its history and its configuration are its own and several accounts coexist on one node. MeshHold never reads or writes the ~/.codex a person uses from their own terminal.

Sign-in happens in MeshHold's own UI: a ChatGPT account by device code (a link and a code, which can be finished from another device), or an API key. The Account panel says which methods this build offers and what the account can do.

Codex draws. Ask for a picture and the answer arrives as a card in the chat with the image in it, saved into the session rather than carried in the event stream, so it survives a reload, a daemon restart, and a second node reading the same session through the proxy. The picture tool needs a ChatGPT sign-in on a plan above Free — an API-key instance says so in the Account panel instead of offering a button that would fail.

MCP servers are configured from the MCP tab like the other drivers, including remote servers over HTTP with an OAuth login. MeshHold's own tools — vault search, chat_send, attach_file, the document tools — are offered to a Codex thread on the same per-instance grants as everywhere else.

Approvals map to the same Allow / Deny cards as the other drivers, and a Windows instance can say whether its sandbox is ready and offer to set it up.

All four drivers sit behind a single SessionBackend interface, so the REST surface and the Web UI are identical regardless of which CLI backs an instance.