Claude Code absorbed git worktrees — and what 'just run many sessions' actually costs

The question

DalkkakAI exists so I can run many claude sessions in parallel across multiple startups. So the obvious worry, in my own words: if one session is editing files and I ask another session to edit too, won't it get tangled? And the hopeful follow-up: doesn't the tooling just isolate everything for me now — do I even need to set up worktrees myself?

I verified the answers firsthand, on the machine I'm typing this on (Apple M2 Max, Claude Code v2.1.160). They correct two tempting beliefs.

Belief 1: "the sessions auto-isolate" — no

[VERIFIED] This session was running in the main checkout — git worktree list returned a single entry on [main], not a worktree. Claude Code does not automatically sandbox a session, and it does not auto-detect what a sibling session is editing. Two sessions launched in the same directory share that directory; if both touch the same file, the later write wins.

The one automatic guard that does exist: Claude Code's edit tool detects when a file changed on disk since it last read it, and refuses to apply a stale edit (it re-reads first). [VERIFIED — observed behavior] That stops one session from silently overwriting based on an outdated read. It does not stop the other session from overwriting my change after I've written it. So "fire edits at both, they'll never collide" is false.

Belief 2: "worktree is automatic now" — half true

Claude Code has absorbed git worktrees, and it's recent — it wasn't there in earlier versions. Verified in v2.1.160:

• [VERIFIED — --help] -w, --worktree [name] — create/use a worktree for the session, plus a --tmux companion flag.
• [VERIFIED — local changelog] mid-session EnterWorktree / switching, a .claude/worktrees/ home, a worktree.baseRef setting (branch from a fresh origin/HEAD vs. local HEAD), and background-agent worktree isolation.

But what got absorbed is the management — creating the worktree, the branch, the cleanup — not automatic isolation. A session does not enter a worktree by itself; you opt in (claude --worktree <name>, or ask the running session to enter one). Default behavior is still "share the directory you launched in."

The trade-off nobody mentions

Here's the part that actually matters, and it's a forced choice: full isolation and "the edit shows up live in the checkout / dev-server I'm running" cannot both be true.

What you want	Where the agent edits	Safety	Cost
Edit visible live in your running working tree / app	main checkout (shared)	don't touch the same files	coordinate file ownership
Independent parallel feature, merged later	a worktree	physical isolation (own branch + dir)	you must merge to see it

If you put the agent in a worktree, its edits live on a separate branch under .claude/worktrees/ — your running dev server won't see them until you merge. So "fix this bug in the file I'm staring at" wants the main checkout (and file-partition for safety); "build this whole feature in parallel" wants a worktree.

The rule I settled on

• Edits that must land now, in the working tree I'm using → main checkout; safety is declaring which files each session owns and staying off the other's.
• Heavy independent parallel work → one worktree per session (claude --worktree <name>), merge when done.
• Commit hygiene either way: the agent stages only the files it touched — never git add -A. In practice, a recent commit here staged 2 files and left 7 of my other session's uncommitted WIP files untouched. That discipline is what actually prevents "tangle," more than any auto-magic.

Honest caveats

• "Tangle" almost always means the same file edited by both at once. Different files are safe. A simultaneous git add/commit race just throws a retryable index.lock error — not corruption.
• I verified the worktree feature exists in v2.1.160; I did not independently verify its exact rollout dates, so I'm not citing any. It's "new," not "new on date X."

Commit: 81a0828