Sessions
A session is one conversation with the agent, in one project. Sessions belong to the server they were started on, so a Work session lives inside its sandbox and a Code session lives on your machine.
Starting one
New session appears in the sidebar under Recents, in the titlebar, on a project's menu, as the tab strip's +, and as mod+t. All of them do the same thing: go to the empty tab already open for that project, and open one only when there is none.
An empty tab stays open until you send a message in it or close it, so pressing New session twice does not leave two identical blank tabs in the strip.
New sessions show up in Recents as they are created, and the title lands in the list as soon as the model picks one.
The session menu
Every session row — in Recents, on the View all screen, and the ⋯ button beside a session title — opens the same menu. On a row the button is a vertical three-dot at the right edge, appearing on hover.
Pin / Unpin — moves the session into the sidebar's Pinned section, where it stays put instead of sliding down the chronological list. Pins are per server.
Rename — edits the row's label in place; Enter saves, Esc cancels. You do not have to open the session first.
Share… — only where sharing is enabled. Sharing from a row opens the session and its share popover, because the share state belongs to the session rather than to the list.
Archive — takes the session out of Recents without deleting it.
Delete — in red, and it asks for confirmation. It takes the session's children with it.
Deleting the session you are reading
Deleting the session on screen moves you to the row below it in the sidebar, and from the bottom of the list back to the top. If the delete emptied the list, you land on a new session in the same project. The deleted session leaves the tab strip with it — there is no leftover Unknown Session tab to close by hand.
Deleting a session you are not currently in just removes it and its tab and leaves you where you were. Both behaviours are the same on Code and Work.
Sessions on a server that is away
A sandbox that restarts — to apply a folder you mounted, or because you stopped and started it — is gone for a second or two. Its tabs are not closed: tabs belong to a sandbox for as long as the sandbox exists, not for as long as it is running, so they sit through the restart with your typed prompt, your terminal and your scroll position intact and pick up where they were.
While the sandbox is away the session says Waiting for this server and comes back on its own, with no click needed, once the server does. Only deleting the sandbox closes its tabs.
Unmounting a folder is different: that folder's sessions and drafts close with its project row, because the folder is no longer part of the sandbox. The sessions themselves are still inside it — mounting the folder again brings them back.
Retries and interruptions
When the connection to the model dies mid-response, the session does not silently go idle. A stream cut off before it produced anything is retried automatically, with the same visible countdown connection failures get, up to three attempts. A stream that died after producing output is not rerun — that would duplicate what you already have — but the session says the reply may be incomplete and that sending a message continues it.
Either way the transcript keeps a small note at the point where it happened, naming what failed and which attempt it was, so a turn that took minutes explains itself afterwards. The same note appears in the terminal app.
Worktrees
On Code, the new-session screen's Local chip creates a git worktree so a session can work on its own branch without disturbing your checkout.
Work does not offer it. A worktree is created on the machine the session runs on, so inside a sandbox it would check out into the sandbox's own disk — invisible from this computer and gone the next time the sandbox is reset. Work shows the branch on its own instead.