Multiple Claude Code sessions in one repository: what breaks

Claude Code sessions in one repository can silently revoke each other’s permission to write files. My setup keeps that permission in one shared file, so it assumes only one agent works in the repository. A scheduled agent running beside an interactive session breaks the assumption without anyone deciding to. The last writer wins, so whichever agent saves the shared file second erases what the first one wrote. In six days, from September 18 to 24, 2026, I logged three cases where one of my agents or sessions deleted, nearly overwrote or rewrote the permission file another one was relying on.²³ For a site that publishes on a schedule, a blocked scheduled publish is a page that does not ship, with nothing on the live site to show it. No publish actually failed in my three cases.

Three incidents between September 18 and 24, 2026, all through one shared permission file, and no lock or warning existed to stop any of them.

Can two Claude Code sessions safely share one repository?

Not safely by default. Two Claude Code sessions in one repository share every file at a fixed path, including the permission file that a hook (a script the tool runs before every write) uses to refuse writes to any file the permission file does not list. Before you add a second session, list the files your tooling writes to a fixed location.

My setup calls that permission file the scope contract and keeps it at .claude/SESSION_CONTRACT.md. It is a short file naming the paths the current session may edit. A cleanup routine deletes the file when a session ends, because a permission file left over from yesterday would silently authorize today’s writes against a task that already finished.²

The second writer is a scheduled runner. This site’s daily Pulse page, a dated what’s-new digest, is written and published by an unattended job at about 11:15 a.m. Eastern time, with no human approval in between. That job reads and writes the same permission file, at the same path, as whatever interactive session happens to be open.³

What happened when agents shared one permission file?

Three incidents between September 18 and 24, 2026 each ended with one session’s permission file deleted, threatened or rewritten by another, and no error announced any of them. A cleanup routine cleared a live peer’s file. An interactive session nearly overwrote the scheduled runner’s. The runner later rewrote the shared file and dropped two lines that a session had just added.

1. September 18, the cleanup routine. A close-out routine, the end-of-session cleanup, ran from a different folder and cleared the permission file of a different interactive session. That session had been running for fifteen hours and was still saving work to the repository. The session list showed it busy, and its permission file named a file it had modified seven minutes earlier. Losing the file would have blocked its next write for a reason it had done nothing to earn. The tool it uses to delete sends files to the Recycle Bin, so recovery was possible.²
2. September 18, 11:07, an interactive session and the runner. The interactive session was about to overwrite the permission file the runner was using mid-run. The runner had finished writing the day’s page but not yet recorded that it finished, so an overwrite would have blocked that day’s publish. The overwrite did not happen only because the session read the file before writing.³
3. September 24, the runner again. While an interactive session held the permission file, the runner added a line for that day’s Pulse page and later rewrote the file. The interactive session had added two lines, the paths of two articles being swapped in the schedule. Afterward, both lines were gone.³

My best explanation for the third case is that the runner wrote back a copy it had read earlier. That is suspected, not confirmed, because I saw only the before and after states of the file. Nothing broke, since the write in question had already happened, but a later write to either article would have been refused for no reason.³

The three share one shape. Each writer treated the file as its own, and the last writer won. There was no lock and no session-specific path.³

The next diagram shows the third case as two agents, one file and three steps.

Does the Agensh paper say anything about shared permission files?

The abstract of the Agensh paper (arXiv 2609.26781) does not mention guardrails or permission files. The paper measures whether more concurrent agents solve a hard task better. Its abstract describes “a scalable self-organized multi-agent harness without a central orchestrator.” A harness is the software that runs and coordinates the agents. The abstract lists a shared workspace, which “holds proposed, ongoing, and completed work”, as one of three components.¹

The headline result is about throughput. On pandoc, a document-conversion program that is one of the paper’s five hardest benchmark tasks, the final test-pass rate rose from 33.89% to 55.06%.¹ That took the agent count from 1 to 1,024.¹

Those results are why the incidents above matter beyond my workstation. If teams follow them, more agents will write into shared state, and each added writer is another chance for the last-writer-wins shape. That is my inference. The abstract is silent on whether the shared workspace also holds permissions, and it reports no test of one agent’s change removing another’s constraint.

What rule keeps agents from removing each other’s guardrails?

Three checks should close the gap, and a team running a scheduled agent beside an interactive one can apply them without changing tools. Keep the permission file per session, so no two agents own one file. Refuse to overwrite a file that changed after you read it. Look for a live peer before you clear state you did not create.

1. Give every session its own state file, named by a session identifier, and have the write-checking hook read only that file. Two agents then have no file in common to overwrite. My repository has none of this today, and the deferred-findings entry for the runner was still open on September 29, 2026.³
2. Read before you overwrite, and stop when the file changed. Record the file’s modified time, or a fingerprint of its contents, when you read it. Compare just before writing, then re-read and merge if the two differ. The September 18 near miss was stopped by exactly this habit, applied by hand.³
3. Check for a live peer before clearing state you did not create. A permission file dated today that names files you never touched belongs to somebody else, so leave it alone and say so in your handoff notes.²

Read against the three incidents, check three covers the cleanup case, check two covers the other two, and check one removes the shared file all three depended on. I have not tested any of them, so this is analysis and not a result.

How is a removed guardrail different from gated writes or sub-agents?

One agent erasing another’s guardrail differs from two problems already covered on this site. Human approval of an agent’s writes assumes the approval stays in place, whereas here the approval itself gets erased. Sub-agents inside one session share no conversation with each other, while separate sessions share a file by accident.

Gate the irreversible step puts the approval at the write. The failure in this piece is one agent deleting that approval before the write happens. What sub-agent delegation costs you covers work handed to helpers inside one session, which share no conversation with each other.

Why do agents overwriting each other’s permission files matter for SEO?

A blocked scheduled agent is a page that does not ship, and the September 18 near-overwrite of the runner’s permission file would have blocked the daily Pulse page due at about 11:15 a.m. Eastern time.³ Google can discover a URL only after it exists, so a daily page that misses its day is a URL that does not exist that day, and the live site keeps serving yesterday’s version with nothing to signal the gap.

The same shape applies to any unattended job that touches what a crawler sees. A feed export, a sitemap rebuild (the file listing every page a site wants crawled) and a redirect map update are illustrative examples, and none of them failed for me. A refusal inside an unattended job may never reach a person.

The alert worth building fires on the missing output, a page or file that should exist by a set hour and does not. An alert on the refused write watches the symptom you may never see.