Sessions

A session is a git branch and a sandbox where the agent works.

A session is one unit of agent work. Kortix cuts a git branch and provisions a sandbox for it. The session id, the branch name, and the sandbox id are the same value.

Status

A session reaches one of 4 states in practice.

The database defines 3 more values (queued, branching, completed). Kortix does not write them for a session today.

Stop, resume, and idle auto-stop

You can stop a session yourself. Resume brings back the same sandbox with the same filesystem and runtime identity. Only the running processes and memory reset. The OpenCode conversation remains attached to the session.

Kortix also stops an idle session for you:

• After 15 minutes idle, for a normal session.
• After 5 minutes idle, for a session a trigger started.

An open dashboard tab does not keep a session alive. A busy agent turn blocks the stop. The maintenance sweep runs every 5 minutes. A normal automatic Stop therefore occurs approximately 15 to 20 minutes after the terminal turn.

Self-host operators can set KORTIX_SANDBOX_AUTOSTOP_MINUTES to change the normal idle grace. This setting does not change active-turn protection.

What stop and delete keep

Stop and resume keep the sandbox’s identity and filesystem. Delete destroys the sandbox. Git is the only durable record: work the agent commits and pushes survives; everything else does not.

Runtime

Every session uses OpenCode REST. Kortix stores the selected OpenCode agent and model when the session starts. Restart and resume keep the same session runtime.

Session access

A session is private to the person who created it. The owner opens Session access and picks one of 3 options.

Everyone with access reads the conversation and continues it.

Only the owner changes this. A project manager who did not create the session can open it once it is shared with them, and can stop, restart, or delete it. They cannot rewrite who else can open it. Sharing a session with a manager is not handing them its access list.

One kind of session has no human owner: the ones a trigger creates, which run under the trigger agent’s identity. Project managers govern those. Set the policy for all of them on the trigger itself, under Session access on the trigger — saving there also updates the sessions that trigger already created.

Admins can open every session

An account owner can let account owners and admins open every session in the account, including sessions members keep private. Turn it on under Account → Settings → Security → Admins can open every session. It is off by default.

• Only an account owner changes it. An admin sees the switch but cannot flip it, so no admin can grant themselves access to everyone’s work.
• Admins find these sessions on the project’s Sessions page. The sidebar still lists only the sessions you started or that are shared with you.
• Access is full access. An admin opens, reads, and continues the session, the same as a session shared with the whole project.
• Members see it. While it is on, the Session access dialog says that owners and admins can open every session.
• Everything is audited. Each flip is recorded as iam.session_oversight.enable or iam.session_oversight.disable, and each session an admin opens through it as project.admin_oversight_session_read (at most once per admin and session per hour).
• Agent and sandbox tokens never gain this access, even when an admin launched them.

Find a session by owner or access

The project’s Sessions page shows each session’s owner and access on its row: the owner’s avatar and name (You for your own), then an icon for who can open it: a lock for Only the owner, people for Specific people, a globe for Whole project.

Open Filter on the Sessions page to narrow the list:

• Owner — one entry per person, with a count.
• Access — Only the owner, Specific people, or Whole project.
• Grouping → Owner — one section per person, yours first.

The filters combine with Status, Source, and search. Reset clears them all.

Sharing a preview

You can share a session’s live preview with a public link, in view-only or interactive mode. Minting that link is the session owner’s call, for the same reason: the link is unauthenticated, so anyone holding the URL reads the session without signing in. A project manager can list and revoke a session’s links without owning it — revoking only ever removes access.

Providers

Kortix runs sessions on Daytona, Platinum, or E2B Cloud. A project follows the platform default, or requests a provider switch through the SDK — see SDK reference. A switch to a different provider is durable: the current provider keeps serving while the target warms, then activates. Every provider runs the same sandbox image.

For the full status enum, injected environment variables, and daemon endpoints, see Runtime. For how a session picks its agent, see Agents. For sessions a schedule or webhook starts, see Triggers. To land session work on the default branch, see Change requests.