Claude Code on the web: messages alternate between two concurrent conversations in the same container, with no indication in the UI

Environment: Claude Code on the web (claude.ai/code), managed container, single project, container reused across several days. Observed August 2026.

Version: the client is server-managed on this surface and auto-updates, and the build serving the incident was not stamped at the time. For calibration, a container on the same surface reports 2.1.227 today (2026-08-11), days after the observation.

Symptom: two conversations for the same project were live in one container at the same time, and the messages I sent alternated between them with no indication in the UI, which went on showing a single continuous thread.

Concretely: I asked a session to update a documentation file. It analysed the code, found the document was many versions out of date, and asked me a numbered question about scope, naming a specific new file it proposed to write instead. I answered that question in what looked like the same thread. The reply came back from a session that had never seen the analysis and did not know what the proposed filename referred to — it searched the codebase for other things by that name and reconstructed a plausible but wrong reading of my answer. Several exchanges went by before I pasted my original message and the two halves met.

Evidence from the container: two transcript files for the same project were being written 39 minutes apart, one holding the analysis and its question, the other holding my follow-up and the confused reply. Grepping for a term that occurs only in the analysis found it present in the first transcript and absent from the second until I pasted it.

Why this is worse than an inconvenience: the answering session cannot tell that it is missing anything. It sees a question with no antecedent and answers it. Nothing signals to either side that the thread has split, so the failure reaches the user as a confidently wrong answer, which is indistinguishable from an ordinary bad one.

Related issues, and why I do not believe this duplicates any of them:

• #80431 — pre-/clear context returning after a "Resumed session" event. I have reproduced that one too and have commented there. Same underlying area, in that the mapping from the visible UI thread to the backend conversation is not stable, but that report is about one conversation being resumed in place of another, not about two being live at once and receiving interleaved messages.
• #70096 — remote-control restart: the web UI stays continuous while the backend starts a fresh session, so context is lost. Inverse direction, and one new session rather than two live ones.
• #81290 — two transcripts written in parallel on Desktop after auto-compaction. There the two files share entry UUIDs, i.e. one conversation recorded twice. Here the two transcripts hold different conversations, and each is missing what the other has.
• #73545 — Desktop Chat-tab messages routed into an already-active Code session. That is several conversations collapsing onto one backend session and it surfaces as a hang; this is one UI thread spread across two backend conversations and it surfaces as a wrong answer.

Suggested minimum fix: surface the conversation identity in the UI, so a thread that has silently swapped is visible rather than something the user has to deduce from the model's confusion.