How to run multiple Claude Code sessions and keep track
Yes, you can run several Claude Code sessions in parallel, one per project or task. The hard part is attention: each session can wait silently. Use one terminal window per project, turn on Claude Code hooks for notifications, and keep one place that shows the state of every session at a glance.
Claude Code is fast enough that waiting for one session to finish feels like wasted time. So you start a second session in another project, then a third. The work goes faster - until you lose track of which session is waiting for your answer.
The short version: yes, you can run several Claude Code sessions in parallel, one per project or task. The hard part is attention. Each session can stop and wait for you, and none of them can tap you on the shoulder. This guide covers how to set up parallel sessions so you never lose a session in silence, and how to see every session's state in one place.
Can you run more than one Claude Code session at a time?
Yes. Each Claude Code session runs in its own terminal and works in the folder where you started it. You can run one session per project, or several sessions in the same project for different tasks, such as a feature in one and tests in another.
The limit is not Claude Code. The limit is your attention: every session can stop and wait for you, and none of them can tap you on the shoulder.
What goes wrong when you run several sessions?
| Problem | What it looks like |
|---|---|
| A session waits in silence | It asks for permission, then sits there while you work in another window. |
| A session finishes unnoticed | The turn is done, but you only find out when you look at that window again. |
| Every check costs a switch | ⌘-Tab, find the window, scroll the terminal, remember what you asked. |
| Windows pile up | A full editor per project just to keep a terminal, a file tree and a preview open. |
How do you set up parallel sessions so they stay manageable?
- One window per project. Start each session in its project folder and keep its terminal in that project's window, so a window always means one project.
- Name things clearly. Use your terminal's tab or window title for the project name, so you can find the right window at a glance.
- Give each session one task. Short, clear tasks finish sooner and need fewer check-ins.
- Check in at the right moment, not all the time. Polling every window breaks your focus. Let the sessions tell you when they need you.
How do you compare the common ways to track parallel Claude Code sessions?
| Approach | What you get | What it misses |
|---|---|---|
| One editor window per project | Terminal, files and preview grouped by project | A heavy editor just to hold one terminal; still no signal when a session is waiting |
Claude Code hooks + macOS osascript notification | A sound or banner when a session needs input or finishes | Tells you that a session needs you, not which - you still ⌘-Tab to find the right window |
| tmux or terminal multiplexer with panes | Many sessions in one terminal window | Panes don't show agent state (working / waiting / done); hard to map a pane to a project open in another editor |
| A monitor script you wrote yourself | Measures exactly what you want | Breaks when hook events change; no UI; expensive to keep up |
| SwitchStation Rail by SSS Flow | A slim rail that shows every session's state across projects, one click to focus the right window | macOS 14+ only; follows Claude Code and Codex sessions in Cursor, VS Code, Antigravity, Terminal, iTerm2, Ghostty and Warp |
How do you get notified when Claude Code needs you?
Claude Code (October 2026) supports hooks: small commands that run on session events, such as Notification when Claude needs you and Stop when a turn ends. A hook can play a sound or show a macOS notification, so you hear about a session even from another app.
A notification tells you that something needs you. With several sessions, you still need to know which one, and get back to it quickly.
How do you see every session in one place?
SwitchStation Rail by SSS Flow is a slim rail at the edge of your Mac screen that follows your Claude Code and Codex sessions across all your projects. It shows each session as waiting for you, done, working or idle, and one click brings back the exact window - in Cursor, VS Code, Terminal, iTerm2, Ghostty, Warp or SwitchStation Workspace.
It sets itself up with lightweight hooks that only report state (session id, working directory, event name), and it never reads your prompts or code. The Free plan covers 3 active projects and 2 monitored sessions at a time, with no time limit.
A real workflow with three sessions
Say you have three projects open: switchstation-rail-mac in Cursor, switchstation-site in VS Code, and switchstation-growth in Terminal. One Claude Code session in each. Rail shows three cells down the right edge of the screen.
- A cell that pulses means Claude Code is working.
- A yellow cell with a dot means Claude Code is waiting for you (permission, plan approval, or a question).
- A dim cell means the session is idle.
When Claude Code in switchstation-site asks for permission, the middle cell turns yellow. One click brings VS Code forward with the right tab focused, and you answer the prompt. No ⌘-Tab, no scrolling, no "wait, what did I ask?".
What should you do next?
Running several Claude Code sessions is the easiest way to get more done with AI - as long as you never lose track of them. Keep one window per project, give each session one task, and let the sessions tell you when they need you instead of checking every window yourself.
When one Mac window per project stops being enough, a session rail is the smallest tool that fixes the attention problem without changing how you code.