Concurrent Claude Code sessions sharing one git clone cause push races on the same branch

Summary

Running many concurrent Claude Code sessions against the same shared local git clone (same working directory, same branch, no worktrees) causes git push races that are hard to diagnose from inside any single session.

What we observed

Our setup: roughly 10 Claude Code sessions, all pointed at the same local clone of one repo, all following a "commit then push immediately" house rule, plus one nightly desktop script that also commits and pushes to the same branch as a safety net.

On a live run, git reflog showed close to 10 sessions committing and pushing within the same minute. One push sequence looked like this:

1. Session/script A: git pull --rebase origin master succeeds.
2. Seconds later, session B pushes to origin/master first.
3. Session/script A's git push origin master then fails (non-fast-forward), even though its rebase had just succeeded moments earlier.

The failure looked like a real error from inside that session (and triggered our own failure alerting), but the commit was not lost — another session's later push happened to carry the same content forward. Diagnosing this required manually walking git reflog / git log / git rev-parse origin/master across the shared clone to confirm nothing was actually dropped. From any single session's point of view, there's no visibility into the fact that "another concurrent session already landed your content" vs. "this is a genuine failure."

We worked around it locally with a retry loop (rebase + push, retry up to 5 times with jittered backoff, never force-push), but this is a pattern every team running multiple concurrent Claude Code sessions against a shared clone will likely hit, and it's easy to misattribute as a bug in the automation rather than an inherent race condition of many agents pushing to one branch from one working directory.

Request / suggestion

Some combination of:

• Documentation/guidance recommending git worktree (or similar isolation) for concurrent Claude Code sessions operating on the same repo, since a shared working directory is the root cause of both file-level and git-level races.
• Optional built-in tooling or guidance for a safe "commit and push" pattern (rebase/retry with backoff, no force-push) for sessions that do need to share a clone.
• Any way for a session to distinguish "my push failed because the network/auth is broken" from "my push failed because another concurrent session's content already landed on the remote," so automations built around Claude Code sessions don't raise false failure alerts in this specific race.

Happy to share more detail on the exact reflog evidence if useful.