Verified against Claude Code · 2026-08-08
Run two Claude Code sessions in parallel on the same repo without them colliding
A worktree-setup prompt that has Claude Code create an isolated git worktree per parallel task before starting work, so two agentic sessions on the same repository never fight over the same files or an uncommitted change in the other session's way.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are about to work on one of several tasks that will run in parallel against this same repository, each in its own Claude Code session. Before writing any code, set up an isolated git worktree for this specific task so this session's uncommitted changes can never collide with, be overwritten by, or accidentally include a file changed by a different parallel session working in the main checkout or another worktree. THIS TASK Implement the CSV export streaming fix described in ticket JIRA-4821, isolated from the two other tasks running in parallel on this repo today. BRANCH AND WORKTREE NAMING Branch name fix/jira-4821-csv-export-streaming, worktree directory ../tools-scult-in-jira-4821 sibling to the main checkout. OTHER PARALLEL TASKS CURRENTLY IN FLIGHT, IF KNOWN A second session is working on fix/jira-4790-invoice-rounding in a sibling worktree, and a third is doing a dependency upgrade on chore/react-19-upgrade — none are known to touch lib/reports, but confirm before assuming no overlap. SETUP STEPS — DO BEFORE ANY EDIT 1. Confirm the repository's current state is clean enough to branch from safely: run git status in the main checkout and note anything uncommitted there that is not yours to touch. 2. Create a new branch for this task specifically, following the naming convention above, and create a worktree for it using git worktree add, as a sibling directory of D:\CLAUDE\tools.scult.in, never nested inside it. 3. Move all subsequent work for this task into that worktree's directory — every file read, edit, and command from this point on happens there, not in the main checkout. 4. Confirm the worktree's dependencies are installed and its test command actually runs cleanly on the pre-change code before making any change, so a later test failure can be attributed to this task's own edits rather than to a stale or incomplete worktree setup. DURING THE TASK - Commit at meaningful checkpoints inside this worktree's own branch, not directly onto the branch any other parallel session is using, even if that other branch happens to be checked out somewhere visible. - If completing this task genuinely requires a change that would also need to exist on a different parallel task's branch, such as a shared type both are extending, say so explicitly rather than making the shared change silently in only one worktree and letting the two branches diverge on it unnoticed. WHEN THE TASK IS DONE State the exact branch name and worktree path so it can be reviewed and merged independently of whatever the other parallel sessions produce, and confirm whether this worktree should be removed with git worktree remove after merge or left for further work. Do not fall back to working directly in the main checkout partway through, even if the worktree setup feels like unnecessary overhead for a small task — the isolation is the entire point when multiple sessions are running concurrently, and partial isolation defeats it.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A git worktree is a genuinely separate working directory sharing one underlying git database — this is the actual mechanism that lets two Claude Code sessions run truly concurrently without one session's file edits ever appearing in the other's working directory, which is categorically different from two sessions sharing a single directory and relying on discipline alone to avoid stepping on each other's uncommitted edits, since a single directory can only have one branch checked out in it at any given moment. Verifying the worktree's own baseline, meaning dependencies installed and tests green on the unmodified code, before editing matters specifically in a parallel-session setup, because a test failure discovered later needs a clean attribution — otherwise a genuine regression from this session's own change is indistinguishable from a setup problem inherited from creating the worktree incorrectly, and untangling that after the fact costs far more than the thirty seconds of verification up front would have. Explicitly surfacing a shared-change need across worktrees, rather than making it silently in one, addresses a real failure mode unique to worktrees specifically: because each worktree has its own independent branch history, a change that logically belongs on two branches at once does not propagate automatically the way it would if both sessions were somehow sharing state — it has to be deliberately made twice or coordinated, and a session unaware this is even a risk will not think to flag it before the two branches have already diverged on it. The refusal to fall back to the main checkout 'for a small task' targets exactly how isolation actually breaks down in practice — not through a dramatic failure, but through a session justifying one quick edit outside its worktree because setting one up felt disproportionate, which is the same scope drift that defeats discipline elsewhere in agentic work.
Verified against
Claude Code Sonnet 4.6 · 2026-08-08
Changelog
- 2026-08-08 — Initial publish, verified against Claude Code with git worktrees (Sonnet 4.6).
Building this for real?
This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
