Sessions
An isolated, disposable sandbox VM on a branch named after the session.
A session runs the agent in its own isolated sandbox. The platform cuts a branch named after the session id, provisions a sandbox VM with the repo cloned onto it, and runs OpenCode inside.
- Isolated — each session has its own VM and branch, so any number run at once (yours, teammates', automations) without interfering. None touch the default branch directly.
- Status —
provisioning → running → (stopped | failed). The branch is cut and the sandbox requested duringprovisioning;stoppedon explicit stop or idle hibernation. - Persistence — stop/resume keeps the same provider identity and filesystem, but drops running processes and memory. Permanent deletion removes that provider state. Git remains the durable contract: only work the agent commits and pushes is portable and recoverable, and only a merged change request lands it on the default branch.
Inside the VM the kortix-agent daemon clones to /workspace, supervises
OpenCode, and serves a control surface on port 8000 that the dashboard tunnels
into. A trigger fire is just an ordinary session. Full runtime detail —
status enum, injected env vars, daemon endpoints — is in
Session runtime.
Sandbox provider
Kortix supports Daytona, Platinum, and E2B Cloud. A project can follow the
platform default or be pinned to any enabled provider. Every provider builds
and hosts the same layered image through the unified runtime contract — everything above
(branch-per-session, /workspace, the daemon, port 8000) behaves the same
regardless of provider. Pin or clear a project's provider with the SDK's
p.sandbox.setProvider(provider) (null follows the platform default); see
The client.