Short answer: Yes, on every surface: several terminal windows, tabs in VS Code, + New session in the desktop app, several tasks in the cloud. Windows are free, working sessions are not: ten agents running in parallel use your quota roughly ten times as fast as one. And if two sessions touch the same files, you need worktrees, or they will write over each other.
Overview
| Where | How to start a second conversation | What stays separate |
|---|---|---|
| Terminal | claude --worktree <name> in a second terminal | Its own checkout, its own branch, its own files |
| VS Code | Command Palette → Open in New Tab (Cmd+Shift+Esc / Ctrl+Shift+Esc) or Open in New Window | Each conversation keeps its own history and context |
| Desktop app | + New session or Cmd+N / Ctrl+N | For Git repos, an isolated copy of the project if you want one |
| Agent view | claude agents, then one prompt per task | Every prompt starts its own background session |
| Cloud (Claude Code on the web) | Create several tasks | Each task runs in its own environment and opens its own PR |
| Claude app | New conversation | The context window is per conversation, the quota covers all of them |
The number the Claude Code team itself puts in the power user tips: three to five sessions in parallel, each in its own git worktree.
Terminal: a second session in its own worktree
A git worktree is a second working directory with its own files and its own branch, sharing history and remote with your main checkout. Claude Code creates one when you pass a name at startup:
claude --worktree feature-authThe same command with a different name in a second terminal starts the second isolated session. The short form is -w. Leave the name out and Claude invents one, such as bright-running-fox. Add --tmux and the session launches in its own Tmux session.
By default the worktree lands in .claude/worktrees/<name>/ at your repository root, on a new branch called worktree-<name>. Two things are worth doing first:
echo ".claude/worktrees/" >> .gitignoreAnd a .worktreeinclude file in your project root if gitignored files such as .env should be carried into every new worktree. A worktree is a fresh checkout, so it does not install your dependencies for you.
Two things that trip people up, both straight from the docs:
- No commit, no worktree. In a repository without a single commit the command fails with
Failed to resolve base branch "HEAD": git rev-parse failed. - Interactive runs need workspace trust. If you have never run Claude in the directory, run
claudeonce and accept the trust dialog; otherwise--worktreeexits and tells you to. Non-interactive runs with-pskip the check.
When you exit, Claude looks for work the removal would destroy: changed or untracked files, uncommitted work in submodules, new commits. An unnamed, clean worktree is removed automatically along with its branch. A named one, or one with work in it, gets a prompt asking whether to keep it, and Claude prints the way back:
claude --worktree <name> --resumeRuns with -p have no exit prompt and therefore clean up nothing. Remove those yourself with git worktree remove; if git refuses because the worktree is locked, run git worktree unlock first.
Mercurial, Perforce, and SVN have no built-in support. You get the same isolation through WorktreeCreate and WorktreeRemove hooks in settings.json.
VS Code: tabs and windows
The extension opens conversations in separate tabs or windows, each with its own history and context. Both live in the Command Palette (Cmd+Shift+P / Ctrl+Shift+P, then “Claude Code”):
| Command | Shortcut |
|---|---|
| Open in New Tab | Cmd+Shift+Esc / Ctrl+Shift+Esc |
| Open in New Window | no default shortcut |
| Reopen Closed Session | Cmd+Shift+T / Ctrl+Shift+T |
With tabs, a small colored dot on the spark icon tells you where things stand: blue means a permission request is waiting for you, orange means Claude finished while the tab was hidden. Click a conversation in the sessions list that is already open in this window and VS Code switches to its tab instead of opening a second copy.
The docs suggest a pattern worth copying: the sidebar for your main session, extra tabs for side tasks. The funnel icon filters the list down to Needs input, Working, or Completed, and the Active toggle shows only what wants your attention.
Desktop app: sessions side by side
+ New session in the sidebar, or Cmd+N on macOS and Ctrl+N on Windows, opens the next session; Ctrl+Tab and Ctrl+Shift+Tab cycle through them. For Git repositories there is a worktree option next to the branch name, which gives the session an isolated copy of the project so changes reach the other sessions only once you commit. That needs Git installed; git --version tells you.
To see two sessions at once, hold Cmd on macOS or Ctrl on Windows and click a second session in the sidebar. It opens in a second pane. Cmd+\ or Ctrl+\ closes the focused pane again.
Worktrees live in <project-root>/.claude/worktrees/. Settings → Claude Code lets you change the location (“Worktree location”) and set a branch prefix. To clean one up, hover the session in the sidebar and click the archive icon; Auto-archive after PR merge or close does it for finished local sessions on its own.
If all you have is a quick question, you do not need a second session for it. Cmd+; / Ctrl+; or /btw opens a side chat that can read the session’s context but writes nothing back into the main conversation. The app does not save side chats to disk, so they are gone once you close them.
Five ways Claude works in parallel by itself
So far this has been about you running several conversations. Claude Code can also split work up on its own, and the docs distinguish five ways:
| Approach | What it gives you |
|---|---|
| Subagents | Workers inside one session that handle a side task in their own context and return only a summary |
| Agent view | One screen for all your background sessions, opened with claude agents. Research preview |
| Agent teams | Several coordinated sessions with a shared task list and messaging between them. Experimental, off by default |
| Projects | One ongoing conversation from which Claude starts parallel threads, usually in the cloud. Public beta on Pro and Max |
| Dynamic workflows | A script that runs many subagents and cross-checks their results |
In agent view, every prompt starts a new session rather than sending a follow-up to the previous one. Space opens a row’s peek panel with a reply field, Enter or → attaches you to the full conversation, ← detaches, Esc returns you to the shell. To see what is running, /tasks lists the current session’s background work and /workflows lists workflow runs.
For large, repetitive migrations there is /batch: Claude interviews you about the migration, then fans the work out to worktree-isolated subagents, 5 to 30 of them according to the docs, each testing its own changes and opening its own PR.
> /batch migrate src/ from JavaScript to TypeScriptAn individual subagent gets its own worktree through the frontmatter of its definition:
# .claude/agents/worktree-worker.md
---
name: worktree-worker
model: haiku
isolation: worktree
---Sessions that know about each other
Your sessions can send each other messages, for instance when one has landed a breaking change that another one is building on. You ask in plain language (“ask the session in my other terminal whether the migration finished”) and Claude handles the rest through the ListAgents and SendMessage tools.
What crosses over is text only, written by one Claude for another: no conversation history, no files. To carry a whole context along, resume the session itself instead of sending a message.
This needs Claude Code 2.1.224 or later on macOS and Linux, WSL 2 included, and 2.1.234 or later on native Windows. There is nothing to switch on.
Splitting one conversation
Sometimes you do not want a second task but two paths through the same one. /branch copies the conversation up to this point and switches you into the copy, leaving the original untouched and still in the session picker:
/branch try-streaming-approachFrom the command line the equivalent is claude --continue --fork-session. The difference is the process boundary: /branch keeps running in the same process, so your “allow for this session” grants still apply. --fork-session starts a separate process, and you approve again there.
Limits
- Parallel costs parallel. Background sessions count exactly like interactive ones: ten agents at once use your quota roughly ten times as fast as one. Running several sessions or subagents at the same time multiplies token usage; the docs say so plainly.
- One quota for everything. Your usage on claude.ai, in Claude Code, and in Claude Desktop counts towards the same limit. The context window works the other way round: length caps a single conversation, the quota covers all of them.
- Resuming the same session twice goes wrong. Resume one session in two terminals without forking and the messages from both interleave into a single transcript.
- Agent view is a research preview. Its sessions run locally and survive sleep, but they stop when the machine shuts down. Worktrees Claude created there disappear with the deleted session, so commit first.
- Agent teams do not isolate. Teammates get no worktrees of their own, so the work has to be partitioned such that each one owns different files.
- For the Claude app the docs name no upper limit on conversations open at the same time. What is documented there is the two limits: the shared quota and the per-conversation context window.
Changes
- 2026-09-29: First version, every statement checked against the docs as of 2026-09-29.
Sources
- Run agents in parallel (code.claude.com)
- Run parallel sessions with worktrees (code.claude.com)
- Common workflows (code.claude.com)
- Manage multiple agents with agent view (code.claude.com)
- Manage sessions (code.claude.com)
- Message your other Claude Code sessions (code.claude.com)
- Use Claude Code in VS Code (code.claude.com)
- Desktop application (code.claude.com)
- How do usage and length limits work? (support.claude.com)
- Claude Code power user tips (support.claude.com)
- Claude Code on the web (support.claude.com)