Docs

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

RouteDescription
GET /api/healthHealth check
GET /api/authPer-provider (Claude/Codex) login status
POST /api/auth/:provider/loginStart an in-app login and return the authorize URL
GET /api/auth/login/:sessionIdPoll login status (the callback completes it)
POST /api/auth/:provider/logoutClear a provider’s stored credential
GET /api/profilesList profiles
POST /api/profilesCreate a profile
PATCH /api/profiles/:idRename a profile
POST /api/profiles/:id/cloneClone a profile
DELETE /api/profiles/:idDelete a profile
GET /api/instancesList VM instances
POST /api/instancesCreate a VM instance
GET /api/instances/:id/agentsList agents on an instance
POST /api/instances/:id/agentsCreate an agent (claude-code, pi, shell)
GET /api/instances/:id/chatsList chats
POST /api/instances/:id/chatsCreate a chat (Claude or OpenAI model)
WS /api/instances/:id/agents/:agentId/terminalTerminal WebSocket

Managing profiles

The desktop app creates, renames, clones, and deletes profiles through the endpoints above; the additional per-profile routes (its build config, Dockerfile, and secrets) round out what Settings → Profiles edits. The server also reconciles ~/.config/isolade/profiles/ on startup, so a profile directory you copy in — for example from a dotfiles repo — is picked up automatically, which keeps the profile 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.