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)

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.