Sessions

Sessions group your tasks by what you’re working on. Each session has its own task list and its own set of open tabs, so a feature, a bugfix, and a refactor never mix.

Switching sessions - tabs close and the target session’s tabs come back

Why Sessions

Without sessions, every task lands in one long history and every open tab competes for the same tool window. Sessions split that into independent working sets:

• Scoped history - the sidebar only shows tasks that belong to the active session
• Scoped tabs - switching sessions closes the current tabs and reopens the target session’s tabs where you left them
• No migration - existing tasks live in the Default session until you move on

Creating a Session

Click the session indicator in the header (it shows the active session’s name, Default at first) to open the session manager. From there:

• Click New Session and give it a name, like auth-refactor or perf-hunt
• The new session becomes active, starting with a clean task list
• New tasks you create now belong to this session

Switching Sessions

Open the session manager and pick a session. Before the switch happens, Multi shows a preview of what changes:

• Which open tabs will close
• Which of the target session’s tabs will reopen
• Whether any running tasks are affected

Confirm and the swap happens in one step. Your previous session keeps its tabs, so switching back restores everything.

Renaming and Deleting

The session manager also handles cleanup:

• Rename a session inline when the project outgrows its name
• Delete a session you’re done with; its task count is shown so you know what’s inside

Tips

• Keep one session per branch or worktree for a clean mental mapping
• Park an investigation in its own session; switching away costs nothing since tabs are restored on return
• The Default session is a fine inbox: triage tasks out of it into named sessions when a thread grows