No unusual instruction, no edge-case prompt. Just several Claude Code sessions on one account, all reading and updating the same shared project doc, the way Projects tells you to use it.
What the source says
On the night of 9-10 September 2026, a Claude Code user filed GitHub issue #93260 after noticing that a shared handover document, claude/open-tasks.md, had been silently rewritten in full three times in about ninety minutes by different concurrent sessions on the same account. Each rewrite was individually correct — a well-formed, current snapshot from the session that wrote it. Each one also erased content a different session had added only minutes earlier: a running log of which mailboxes, drafts, chat threads, and scheduled tasks had already been read.
The document's internal UUID changed with every write (f0793cd2 → f8de655a → 7a066ec8), so no single write looked anomalous, and every session got a normal success response. Nothing signaled that anything had been lost.
The reporter's root-cause description: project_write performs a whole-document replace with no compare-and-swap. When multiple sessions read the same doc, compose changes, and write back their full copy — the ordinary shape of concurrent agent work — whichever write lands last silently discards everything the others added in between. They distinguished this from a previously closed issue (#87117) about a single session composing an incomplete write; this one destroys writes that were each correct on their own.
They also ruled out the client-side fixes you'd reach for first: reading immediately before writing only narrows the race window, an internal read-splice-patch is invisible to a competing whole-file writer, and an out-of-band mutex only works if every session opts in — which unattended runs can't do at all, since connector writes there block on an approval prompt nobody answers.
What it doesn't establish
This is a single first-hand report, not an independently reproduced or maintainer-confirmed bug. reproducible: false in our record reflects that: the mechanism is clearly documented, but no third party has filed a matching repro. As of publication the issue is open with no maintainer response. Severity here is scored medium (4.2), not because the loss was small — a live read log silently vanishing is a real problem — but because it requires a specific, if increasingly common, usage pattern: multiple concurrent sessions writing the same Projects doc.
Why it's worth knowing anyway
The loss was caught only because one session happened to run a custom grep check against the doc. Without that, a later session would have re-read sources needlessly or, worse, treated an unrecorded source as already clean — silent, compounding damage.
The reporter proposed three fixes, and it's worth noting the product already has precedent for two of them: a version token on project_read accepted as an if_version parameter on project_write (Claude's own memory tool already implements exactly this), a non-destructive append mode for log-style docs, and a shrink/delta signal (bytes_before/bytes_after) so a model can detect it just erased most of a document and repair it.
If you're running concurrent agent sessions against any tool's shared "memory" or "project doc" feature, this is the failure mode to check for before you rely on it: does a write know when it's stomping on someone else's, or does it just win?
Full incident record, severity scoring, and cross-references: https://www.stupidllm.com/incident/STUPID-2026-0108/
Top comments (0)