Managing sessions

A session is one running agent, or one shell, attached to one working directory. The daemon owns it. Your devices are just windows onto it, which is why you can open and close them at will without ever losing your place.

What a session is

When you open a session, the daemon spawns the agent or shell inside a pseudo-terminal and streams its output to whatever device is watching. The agent thinks it is talking to a normal terminal, because it is. The state of that terminal, the scrollback, the cursor, a half-finished TUI, all of it lives on the daemon, not in the browser tab. A device that connects is handed the current state and then the live stream. A device that disconnects changes nothing about the session it was watching.

Many at once

Run as many sessions as you like, across projects and across machines. The point is that they are genuinely independent processes, not tabs in one program.

claude in ~/projects/api

Refactoring an auth flow, churning through files, taking its time.

shell in ~/projects/api

Tailing logs so you can watch what the refactor breaks in real time.

gemini in ~/sandbox

A throwaway experiment in a different repo entirely, untouched by the other two.

None of these blocks another. Each has its own working directory, its own agent, its own scrollback.

Switching between them

The session list in the UI shows everything the daemon is running. Tap one to attach, tap another to jump over. Switching does not pause, snapshot, or disturb the session you leave; it keeps running exactly as it was. When you come back to it, you see what happened while you were gone, the same as glancing back at a terminal tab you left open.

Persistence

There is nothing to save and nothing to lose. The session lives on the daemon, so the failure modes that would normally cost you your terminal state simply do not apply.

What it survives

A closed tab

└─

Close the browser, sleep the phone, switch apps. The session was never in the tab; it is on the daemon. Reopen and it is mid-render where you left it.

A dropped connection

└─

Signal cuts out in a lift or on a train. The encrypted channel reconnects on its own, and the session was running the entire time.

A device switch

└─

Start on your phone on the walk home, finish on your desktop at the desk. Both are paired, both attach to the same live session.

What it does not survive

Sessions are bound to the daemon process. If the daemon stops, its sessions stop with it. Restart the host, kill the daemon, or let the machine sleep so hard the process dies, and the agents inside go down too. Detaching from a device is always safe. Restarting the daemon is the one thing that actually ends a running session, so do it on purpose, not by accident.

Note

If you need a session to outlive a reboot, that is a job for the daemon's own lifecycle, not for codeout's persistence. codeout keeps your session alive across every device-side hiccup; it cannot keep a process alive that the operating system has killed.

Ending a session

Closing a window detaches; it does not stop the agent. To actually end a session, stop it from the session menu or close it from the daemon. Stopping a session ends its agent process and frees the working directory it was holding. This is the only difference that trips people up at first: walking away leaves it running, on purpose, because that is usually what you want.