HTTP API
The REST endpoints the desktop app calls on the local server.
The server exposes a REST API on 127.0.0.1 at an OS-assigned port (the Tauri host injects it into the webview). It’s the same API the desktop UI uses. There is no authentication beyond the loopback bind and a CORS allowlist, because the server is a single-user local process.
Routes
| Route | Description |
|---|---|
GET /api/health | Health check |
GET /api/auth | Per-provider (Claude/Codex) login status |
POST /api/auth/:provider/login | Start an in-app login and return the authorize URL |
GET /api/auth/login/:sessionId | Poll login status (the callback completes it) |
POST /api/auth/:provider/logout | Clear a provider’s stored credential |
GET /api/workspaces | List workspaces |
GET /api/instances | List VM instances |
POST /api/instances | Create a VM instance |
GET /api/instances/:id/agents | List agents on an instance |
POST /api/instances/:id/agents | Create an agent (claude-code, pi, shell) |
GET /api/instances/:id/chats | List chats |
POST /api/instances/:id/chats | Create a chat (Claude or OpenAI model) |
WS /api/instances/:id/agents/:agentId/terminal | Terminal WebSocket |
Workspaces are read-only here
There is no POST /api/workspaces or DELETE /api/workspaces/:id. Workspaces are added and removed by editing ~/.config/isolade/workspaces/, which the server reconciles on startup. This keeps the workspace set reproducible from files in git. See Configuration layout.
The sandbox API
The endpoints above are the server’s public API. The server in turn calls a separate internal API on the sandbox runtime (VM lifecycle, exec, registry discovery). That interface is documented in packages/sandbox/README.md in the repository.