Intermittent session-local tool-I/O corruption on Windows (silent Write loss, fabricated/replayed results, mojibake) — worse under high concurrency + long-lived sessions

What happens

Some Claude Code sessions intermittently enter a degraded state where the tool-I/O layer returns results decoupled from real execution. A fresh session recovers. Verified with Process Monitor + out-of-band disk checks from a separate process.

• Write reports success but the file never lands on disk (one case: 7–8 byte-identical repeated "success" acks, file absent).
• Stale / duplicated / replayed Bash/Read output; phantom files (claimed present by one tool, absent on disk).
• Mojibake: non-ASCII stdout garbles into symbol runs (☃ ◆ ◊) — a memory/encoding artifact; the on-disk bytes are correct.
• The anomalies trip the prompt-injection detector → false-positive "injection" warnings.
• A degraded session can present fabricated/replayed tool results as real.

Update (2026-06-22) — still reproduces on the latest 2.1.185

After updating to 2.1.185 (latest), the failure reproduced again — a pure version-regression that an update would fix is ruled out:

• A ~300-byte, 9-line file written via the Write tool returned "success" (with a ~2-minute hang), and the agent even claimed a follow-up Read "confirmed the content" — but an out-of-band ls -la from a separate Git Bash showed the file was 0 bytes (empty).
• In the same session ~12 min earlier, a 67-byte Write landed correctly (out-of-band verified), confirming the intermittent nature (same tool, same session: one write fine, another silently empty).
• Caught live with a small detection kit (out-of-band probe + nonce/hash verification). Updating to the latest version did not fix it.

Environment

• Claude Code: first observed on 2.1.183, confirmed still reproducing on 2.1.185 (latest) after updating (see Update above). Windows 11 (build 26200), Ryzen 9950X (32 logical cores)
• 3–7 concurrent CC instances; UV_THREADPOOL_SIZE unset (libuv default 4); autoCompactEnabled: true

Smoking-gun evidence (Process Monitor + out-of-band)

Probe: python -c "...write a 16-byte random GUID to D:\probe.txt; print('PROBE_GUID='+guid)", with the path pre-cleared and checked from a separate process.

• Clean run (captured under ProcMon): python.exe → CreateFile SUCCESS (OpenResult: Created) → WriteFile SUCCESS (16 bytes) → CloseFile; the session's displayed GUID == disk content == ProcMon-observed bytes. Correctly-formed commands execute truthfully and are observable.
• Degraded run (earlier): the session displayed a PROBE_GUID, but the file was MISSING on real disk (verified out-of-band after pre-clearing). No write reached the FS, yet a "success" result was shown to the agent.
• A separate-process tool (Codex CLI) and out-of-band PowerShell consistently see real-disk truth while the degraded session does not ⇒ corruption is in the CC session process's tool-I/O state, not the OS filesystem (OS cache is global; it would affect all processes — it doesn't).

Onset (locating clue)

Absent for months; recent onset and escalating over roughly the last weeks. We initially suspected a hardware upgrade or only-long-lived-sessions, but updating to the latest version (2.1.185) did not fix it, so neither a pure version regression nor a long-session-only explanation is sufficient on its own. The multi-session habit (3–7 concurrent instances; one observed running ~43 h before a forced restart) predates the onset. Best current read: an intermittent/probabilistic trigger in the tool-result channel under sustained concurrency + accumulated per-session in-process state. (Exact start date and any recent environment changes are still being pinned down.)

Likely root cause

Session-local corruption of the in-process tool-I/O orchestration (result cache / IPC / call-ID mapping / stdout pipes): results replayed, mis-attributed, or fabricated; the success ack decouples from the real fs op. Ruled out: OS/NTFS cache (global), Defender (global; doesn't explain session-specificity or mojibake), OneDrive/sync (project dirs not synced).
Honest caveat: we couldn't capture a degraded run under ProcMon (it had recovered), so for that one instance we can't fully separate "tool-layer fabrication" from "the model emitting a result for a malformed/never-dispatched command"; but mojibake / phantom files / byte-identical repeated Write-success are not model-producible and point at the tool layer.

Workarounds we use

Out-of-band verification of critical writes (separate process + hash/nonce); never batch a Write with Bash/Agent in one turn; abandon a degraded session for a fresh one; restart long-lived sessions periodically; route critical writes through a separate process; UV_THREADPOOL_SIZE=16; fewer concurrent instances.

Asks

Per-session isolation/validation of the tool-result channel; a post-tool integrity check (returned result ↔ actual fs operation) for file-writing tools; investigate the result-cache/IPC path under multi-instance + parallel-batch + long-session load. Happy to provide a .PML from a degraded run if one can be captured live.