File corruption (content replaced with thousands of `}`) when large parallel batches of Read + Write/Edit tool calls are processed

Environment

Description

⚠️ This is an observational report. We have not yet attempted a controlled reproduction outside of the original session. The description below reflects what was observed during normal use; we are reporting it so the maintainers can assess whether it matches a known issue or warrants investigation.

When Claude Code issues a large batch of tool calls that mixes Read and Write/Edit operations in the same turn, some files on disk end up corrupted: their entire content is replaced by thousands of repeated } characters (or similar single-character flood), while retaining the original filename.

The corruption is silent — no error is returned to Claude Code, the write is reported as successful, and the damage is only discovered on the next Read or when the file fails to compile.

Sequential operations (one file at a time) appear unaffected — the issue was only observed under parallel/batch load.

Observed conditions

• Occurred twice in the same session, both times during turns with 8–12 simultaneous tool calls (Read + Write/Edit mixed).
• The corrupted files were among the Write/Edit targets of the batch, not the Read sources.
• File size after corruption: several thousand lines of repeated } — far larger than the intended content (which was tens of lines).
• A small file (~50 lines) and a medium file (~120 lines) were both affected, suggesting no size threshold.
• Recovery: git restore <file> — the originals were intact in the working tree because no git add had been issued yet.

Workaround

Issue Write/Edit calls sequentially (one file per turn, or one at a time). Recovery when it occurs: git restore <file>.

Hypothesis

The rtk proxy likely buffers or pipes tool-call output streams. Under high parallelism, a race condition in the output demultiplexing causes one stream's content to be written to the wrong file descriptor (or the buffer is flushed with leftover data from a previous call), producing the character flood. The fact that } specifically appears suggests a fragment from a JSON response body (closing braces) leaks into the file write path.

Related issues searched

No existing issue describes this specific symptom. Closest:

• #2148 — hook returns stale/incorrect filesystem state (different root cause: caching, not content corruption)
• #2146 — hook corrupts API thinking blocks (different layer: HTTP request payload, not on-disk file)

No source files, tests, or entry points are named. First reproduce the corruption with parallel Read plus Write/Edit calls under the reported environment, then trace the Rust proxy's buffering and output demultiplexing for concurrent streams. Done means identifying a reproducible cause and preventing silent file corruption under parallel load, with coverage for the failure case.