How to run several Claude Code sessions on one app without losing track
You can run several Claude Code sessions on one codebase in two ways: point them all at one folder, or give each its own git worktree. One folder is quicker to see and easier to break. Worktrees are safer and slower to bring together.
This post covers when to pick each, and the habits that keep a shared folder from turning into a mess.
The two ways
| One folder, several sessions | One worktree for each session | |
|---|---|---|
| Set-up | Open more terminals in the same project | git worktree add ../app-pricing -b pricing for each one |
| What you see | Every change lands in one running app, straight away | Each worktree needs its own dev server and its own port |
| Risk | Two sessions edit the same file and one overwrites the other | Merge conflicts later, when the branches come together |
| Good for | Small changes to different parts of one page or product | Large changes that touch shared files |
Neither is the right answer every time. A good rule: if two tasks could touch the same file, split them into worktrees. If they clearly cannot, one folder is fine and you get to watch the whole thing come together in one browser tab.
When one folder is enough
One folder works when the tasks sit in different places. One session rewrites the hero copy. Another restyles the pricing table. A third adds a page. They share a dev server, so you see all three changes arrive in the same app.
It stops working when tasks meet. The usual meeting points are the files everything depends on: the router and the global styles first, then shared components and config.
Five habits that keep it sane
Give each session one area, and say so in its first prompt. “You own the pricing section. Do not edit files outside src/pricing. If you need a change outside it, stop and ask me first.” A session that has been told its edges is much easier to keep inside them.
Name the terminals. Three tabs all called “claude” is how you paste the right prompt into the wrong session. Rename each tab after its area: hero, pricing, signup.
Let one session at a time touch shared files. If two tasks both need the router, do them one after the other. This single rule prevents most overwrites.
Commit small, and commit from each area. A commit after each finished change gives you a clean point to return to when a session goes wrong. It also shows you which session did what, because the commits are grouped by folder.
Keep the changes where you can see them. The real cost of parallel sessions is attention. You cannot read three diffs at once. You can watch one page.
Where the trouble comes from
Most collisions are one of two kinds.
The first is two sessions in one file. Each reads the file, each writes its own version, and the second write wins. You notice later, when something you saw working is gone.
The second is harder to spot. One session changes a route or a function while another changes the component that calls it. Both edits are fine alone, and the app breaks where they meet.
Both come down to the same question: who is working where, right now?
Seeing who is where
A diff tells you what changed after the fact. While three sessions are running, what you need is a view of the page itself with each session marked on it.
That is what Flockshow does. It works with Claude Code on Vite and React. Each session gets a named cursor on your running app. When a session edits the hero, its cursor flies to the hero and shows a label such as “Ava rewriting Hero”. Two cursors heading for the same heading is something you see at once, before either has finished.
It only listens to the events Claude Code already sends to your own machine. It never types into your sessions.
If you prefer worktrees, keep them. The cursors are for the case where several sessions share one folder and one running app.
A set-up to start with
- Split the work into areas that do not share files.
- Open one terminal for each area, name it, and give each session its edges in the first prompt.
- Keep shared files for one session at a time.
- Commit after each finished change.
- Watch the app, not the diffs.
When the areas stop being separate, move that task into a worktree.