Claude Code's Projects tool let concurrent sessions silently destroy each other's writes to a shared handover doc, three times in ninety minutes (GitHub #93260)
4.2
medium
September 10, 2026Verified
Instruction given
None specific to the loss — the user was running several concurrent Claude Code sessions on the same account, all reading and updating a shared project handover doc (`claude/open-tasks.md`) as part of normal agentic work. No session was told to clear, reset, or resync that document.
Expected behavior
Project docs are pitched as the cross-session memory Projects tells users to rely on. Writing to one should not silently discard another session's concurrent, independently well-formed addition — at minimum the API should let a session detect that the document changed since it last read it and refuse a stale write, the way the product's own memory tool already does.
Actual behavior
`project_write` performs a whole-document replace with no compare-and-swap. On the night of 9-10 September 2026, the same handover doc was rewritten in full three times in about ninety minutes by different concurrent sessions on one account. Each individual write was correct and current on its own; each one silently deleted content a different session had added minutes earlier — specifically, a running record of which mailboxes, drafts, chat threads, and scheduled tasks had already been read, and when. The document's internal UUID changed on every write (f0793cd2 -> f8de655a -> 7a066ec8), so nothing about any individual write looked like an overwrite, and every session received a normal success response.
Damage
Three consecutive silent overwrites erased a live-source read log that other sessions depended on to avoid redundant work or, worse, to avoid wrongly assuming an unrecorded source was already clean. The loss was only caught because one session happened to run a custom grep check against the doc; without that check it would have gone completely unnoticed. No maintainer had responded as of publication, and the reporter noted every client-side mitigation available to a single session (read-then-write, read-splice-patch, an out-of-band mutex) protects only that session and is invisible to a whole-file write landing on top of it from another session, so the class of bug remains open for any concurrent Projects usage.
On the night of 9-10 September 2026, a Claude Code user filed GitHub issue #93260 after noticing that a shared project handover document, `claude/open-tasks.md`, had been silently rewritten in full three times within about ninety minutes by different concurrent sessions running on the same account. Each rewrite was individually correct — a well-formed, current snapshot from the session that wrote it — but 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, and when. The document's internal UUID changed with each write (f0793cd2 → f8de655a → 7a066ec8), so no single write looked anomalous, and every session got back a normal success response with no indication anything had been lost.
The root cause, as the reporter laid out in detail, is that `project_write` performs a whole-document replace with no compare-and-swap mechanism: when multiple sessions read the same document, compose changes, and write back their full copy — the ordinary case for concurrent agent workloads — whichever write lands last silently discards everything the others added in between. The reporter distinguished this from a previously closed issue (#87117) about a single session composing an incomplete write; this bug destroys writes that were each correct on their own. They noted that no client-side workaround closes the gap: 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 cannot do at all, since connector writes there block on an approval prompt nobody answers.
The loss in this case was caught only by luck — one session happened to run a custom check that grepped the doc for the recorded reads. Without it, a later session would have either re-read several live sources needlessly or, worse, wrongly treated an unrecorded source as already clean. The reporter proposed three fixes: a version token on `project_read` accepted as an `if_version` parameter on `project_write` (which the product's own memory tool already implements), a non-destructive append mode for log-style documents, and a shrink/delta signal (`bytes_before`/`bytes_after`) so a model can detect it just erased most of a document and repair it. As of publication the issue remained open with no maintainer response, and the underlying race condition affects any concurrent use of Projects as cross-session memory — the exact workload the feature is built for.
We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.