AI / GenAI·6 min·18 October 2026

Claude Code's desktop app is now built for running sessions in parallel

I keep several Claude Code sessions running in one project folder, and that has gone wrong before. On 1 July one session switched branches while another was mid-task. The second session’s commit landed on the wrong branch, git happily reported “Everything up-to-date” on push, and my change wasn’t on main.

So I wrote rules. Every feature branch now gets its own git worktree. A hook warns me at startup when another session is active in the same folder; it fired when I opened the session that drafted this piece. Articles claim their publication day by pushing a stub to main, which works as a lock because git rejects a push that doesn’t build on the latest state. Without that, two sessions picked the same day and nobody noticed until the build. There’s even a note about the GitHub account flipping under my feet, because a parallel session switches it back.

On 14 October, @ClaudeDevs posted a thread saying the desktop app had been reworked for exactly this kind of setup. Some of what I had been enforcing with scripts is now part of the interface, and some of it isn’t.

Back in August I covered sessions that can message each other from the terminal. This one is about the app, and about who stays in charge once Claude starts spinning up sessions by itself.

What’s new

I’ve grouped the new features, each group paired with the problem I think it’s aimed at.

FeatureWhat it doesAimed at
New session screenKeeps recent folders one click awayDigging for the right project folder every time
EnvironmentsSaves a setup (a few folders, an SSH host or the cloud), optionally with a worktree per folderRebuilding a multi-repo session by hand
Nested sessionsWhen you ask for parallel work, Claude starts a session per task, and each reports back to your main sessionA main thread drowning in intermediate steps
Follow-ups and /btwClaude suggests follow-up work you can launch as its own session in one click; side questions open in a separate tabDetours derailing the main task
Sidebar and in-session viewShows which sessions are working and which need you, plus a live to-do list, a recap card when Claude needs input, and a side rail with environment, context and changesLosing track of which session has stalled

How it fits together

The docs describe each desktop session as its own conversation with its own history and project folder. In a git repository you can give a session a worktree, an isolated copy of the project on its own branch, stored under .claude/worktrees/ by default.

A nested session therefore looks like a full session with its own context. Subagents are a different thing. According to the docs, they run as background work inside your current session and show up in the tasks pane. The thread says a nested session reports its result back to the main one. My guess is that you read the conclusion there and the working stays in the nested session, but I haven’t been able to check that.

Neither the thread nor the docs say whether a nested session gets its own worktree by default. That’s the detail I care about most, since two sessions writing to one folder without worktrees is precisely what my startup hook is there to catch.

What the app still can’t see

From inside a desktop session, Claude can list your other Code tab sessions, see what they’ve been doing and send them messages. It only sees sessions the desktop app itself is running, though. Cloud sessions and anything launched from the terminal or VS Code are invisible to it, even in worktrees of the same project. The docs spell it out: with nine terminal worktrees open and two desktop sessions, Claude in one of them reports exactly one other session.

If you work in both the terminal and the app, there’s still no single view of everything.

Then there’s shared state that lives outside git. My publication days, the active GitHub account and the queue of scheduled social posts are files and settings that every session reads, and no worktree keeps them apart. A nicer sidebar doesn’t touch any of that, so my rules stay.

The trade-offs

Parallel becomes the default. A one-click button for follow-up sessions makes running several at once the normal way to work. More sessions means more changes to review, and that part is still yours. I wrote earlier about how the work shifts from doing to checking.

You sign off on a summary. The recap card and a nested session’s report exist so you can decide without reading everything. Handy, but it means approving on the strength of Claude’s own account of its work. The diff is in the side rail; opening it is your call.

Usage and dependence scale with the session count. Every session draws on your plan’s limits. The docs say that holds for cloud sessions too, and even for the suggested follow-up prompts, which come from a short background request. Cloud sessions run on Anthropic-managed infrastructure by default, so that’s where your code goes. And the more of your workflow lives in this app, environments and nested sessions included, the bigger the move if you ever want to switch tools.

What I’m doing

The worktree rule stays, and so does the publication-day claim. The app takes care of part of the git collision, but it has no idea about the shared files in my pipeline. What I want to try first is the sidebar that shows which session is waiting on me. And I’d rather not launch a suggested follow-up session until I know which folder and branch it’ll be working in.

Frequently asked questions

Do I need to install anything?

Update the desktop app and start a new session. The Code tab needs a paid plan: Pro, Max, Team or Enterprise.

Does it work with sessions started in the terminal?

Partly. You can keep using the terminal alongside the app, but from within the app Claude only sees sessions the app runs itself. CLI, VS Code and cloud sessions are outside that view.

How is a nested session different from a subagent?

The docs describe a subagent as background work inside your session. The thread describes a nested session as a separate session per task that reports its result back to your main session.

Do more sessions cost more?

Yes. Every session counts towards your limits, cloud sessions included, although the docs say there are no separate compute charges.

Sources

Checked on 17 October 2026. I didn’t watch the videos in the thread, so everything here about the new features comes from the thread text and the docs. Neither says whether a nested session gets its own worktree by default. I found no contradictions between the two.