[BUG] Concurrent sessions in the same desktop app corrupt tool results: text injection, fabricated file state, silent dropped/partial writes

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Two Claude Code sessions were running concurrently inside the same Windows desktop app instance (same process) — same repository, two separate git worktrees on different branches, doing unrelated work. The tool results streamed back to the model in one of the two sessions got corrupted. The corruption was in the tool-result/echo layer only — the actual filesystem and deterministic side effects (compiler, test runner) stayed truthful throughout. Three classes occurred:

1. Injected text — unrelated content spliced into otherwise-normal Read / Edit / Bash / Grep results (samples under Error Messages).
2. Fabricated success / file state — file-writing tools reported success for writes that never happened, including a Write whose "created successfully" + reported line count + grep-matched content were entirely fabricated for a file that never existed.
3. Silent dropped / partial writes — edits reported "updated successfully" but were not applied; one partial apply left a source file referencing an undefined variable, silently breaking a previously-passing file.

The corruption also appeared to distort my reading of the user's own messages (I answered a different question than the one asked, confirmed by the user), so it was not strictly limited to outbound tool results.

Only one of the two sessions was affected — the other session showed no sign of reverse bleed (the corruption was one-directional in this case). It correlated with both sessions being active and with the Output token limit hit. Resume directly (forced truncation + resume) path. Critically, stopping the other session did NOT clear it: that session was never closed, only left idle (the user simply stopped advancing that conversation), so it stayed resident in the desktop-app process — and corruption kept reproducing afterward. Only a full restart of the desktop app cleared it. This points to persistent, in-process shared state/buffer rather than purely real-time contention.

What Should Happen?

• Tool results returned to the model must faithfully reflect the actual tool execution — no injected text, no fabricated success / line count / content.
• Concurrent sessions within the same desktop-app process should be isolated at the tool-result / context layer (no cross-session bleed); idling or stopping one session must not leave corrupting residue affecting the other.
• A dropped or partial file write must fail loudly, never report "success".

Error Messages/Logs

Representative corruption artifacts (none were real tool output — injected or fabricated):

Injected text, present in no file, spliced into a Read result (reads like another agent session's thinking):
Wait, let me re-read the actual file content rather than guessing.
Foreign-language error string injected into output (neither session used this language):
Đã xảy ra lỗi # Vietnamese, "An error occurred"
Leaked structural tags inside tool-output bodies:
</result> </parameter>
Fabricated duplication — git status listed the same untracked file three times.
Contradictory results from the SAME deterministic command on consecutive runs:
grep -c <pattern> <file> -> returned 1, then 0
git diff --numstat -> reported a heavily-edited file as: 1 0
Fabricated file existence:
Write -> "File created successfully"
wc -l -> "108"
grep -> matched content inside the file
(after restart) ls <file> -> "No such file or directory" # the file never existed
Partial write breaking a working file (larger edit dropped, small dependent edit landed):
NameError: name '<var>' is not defined # reproduced deterministically in the test runner after restart

Steps to Reproduce

1. In the same Windows desktop app, open two sessions against the same repository, in two separate git worktrees on different branches (unrelated work in each).
2. Drive both sessions with heavy tool use (many Read / Edit / Bash / Grep calls) at the same time.
3. Let at least one session hit the Output token limit hit. Resume directly truncation/resume path.
4. Watch the affected session's tool results: injected text from the other session, dropped/partial writes reported as success, and fabricated file state start to appear.
5. Stop advancing the other conversation (leaving it idle, NOT closed): corruption may STILL reproduce. Only a full restart of the desktop app returns output to normal (clean, repeatable, with real tracebacks/warnings).

Note: this is a concurrency/timing issue; reproduction is probabilistic, tied to simultaneous activity plus the resume path, and residue persists in-process until a full restart.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.0.74 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other (Claude Code Windows desktop app; PowerShell / Git Bash underneath)

Additional Information

What is NOT affected (ground truth stayed reliable):

• python -m py_compile and the test runner gave stable, real results.
• After restart, the actual files matched ground truth — e.g. the partial-write NameError reproduced deterministically.
• So the corruption is in the tool-result transport/echo layer, not the filesystem.

A/B evidence:

• During concurrency: the contradictions / injections above.
• Stopping the other session was NOT enough — afterward a file write was still fabricated as "success + line count + content" for a file that, after restart, turned out never to have existed. (The other session was only idle, never closed, so its in-process state was never torn down.)
• Only a full restart of the desktop app produced clean output: the same grep -c returned a stable count on repeated runs, git status no longer triplicated, a normal LF/CRLF git warning reappeared, and the test runner produced a real traceback.
• (Correlation, not proof — but the symptom profile, another agent's monologue plus a foreign-language error string, points to cross-session stream bleed rather than random truncation.)

Hypothesis:
Cross-session bleed of tool-result / context streams between sessions sharing one desktop-app process. The key observation is that the corruption was one-directional and persisted after the other session went idle — only a full restart cleared it — which suggests persistent, in-process residual shared state/buffer (consistent with the desktop app managing multiple sessions in a single process), not purely real-time contention. It may be triggered or amplified at truncation/resume boundaries (Output token limit hit. Resume), where stream re-assembly could splice in tokens from another session and drop the call in flight. The outbound direction (assistant → user) may be affected as well.

Why it matters:
The model drives decisions off tool results. Corrupted-but-plausible output (a fabricated NameError, a false "write succeeded", a fabricated file) makes it act on hallucinated facts or believe dropped writes landed — risking incomplete or incorrect commits. Cross-validating across independent tools mitigates it but at real cost and with residual risk.

Suggested guardrails:

• Namespace / integrity-check tool results so they cannot bleed across sessions sharing a process, especially around output-token-limit resume.
• Ensure idling/closing a session fully tears down its in-process state so it cannot corrupt a sibling session.
• Fail loudly on dropped or partial writes instead of reporting success.