Bash tool_result replaced by a concurrent session's assistant output (cross-session output bleed) — 2 documented occurrences

Environment

• Claude Code CLI 2.1.220, macOS (darwin 25.6.0)
• Multiple interactive sessions running in parallel in separate terminals (same user, different project directories) — a standard multi-clone workflow

Summary

Twice within a week, the assistant text of one running session materialized verbatim as the tool_result of a Bash call in a different session. The receiving session's command was a short wc -c on files in its own session scratchpad (/private/tmp/claude-<uid>/<project-hash>/<session-uuid>/scratchpad/). Instead of byte counts, the tool channel returned ~1.5–2.4k chars of coherent prose that session B had just generated as its normal assistant output — including references to session B's conversation history and action prompts addressed to its own user.

Both occurrences were verified afterwards from the two sessions' ~/.claude/projects/**/<session>.jsonl transcripts: the receiving side shows the text inside a regular tool_result block (is_error: false, matching tool_use_id), and the emitting side shows the identical text as an assistant/text block 4 seconds earlier in both cases.

The two occurrences

| | Case 1 | Case 2 |
|---|---|---|
| Date (UTC) | 2026-07-23 ~08:30 | 2026-07-30 ~06:27 |
| Victim command | wc -c <file1> <file2> (after cd into scratchpad) | pdftotext …; pdftotext …; wc -c … (only the wc output was replaced; the pdftotext outputs were fine) |
| Emitting session | long-running session in another project dir | same long-running session |
| Delta assistant-text → foreign tool_result | ~4 s | ~4 s |

Correlated anomalies (same command/path, same sessions)

• Case 1: the first attempt of the identical wc -c call timed out after 2m (exit 143) with Warning: no stdin data received in 3s, proceeding without it… — a wrapper message, notable for a command that had file args and shouldn't read stdin. The retry (with < /dev/null) then received the foreign text.
• Case 2: the next verification call after the bleed (ls + md5 + wc -c on the same files) hit the 120 s timeout and reported exit 1, while its output file contained the ls/md5 sections complete, cut off exactly before the wc section.

So all four anomalous events cluster on wc -c invocations over scratchpad paths while another session was actively generating output.

Why this matters

The foreign text arrives in the most-trusted channel a session has (its own tool results) and in both cases carried imperative content (trigger words for follow-up actions intended for the other session's user). Both receiving sessions correctly treated it as untrusted data, but this is effectively an unintended prompt-injection surface between concurrent sessions of the same user — and it initially presents as either a hook hijack or model confabulation, which costs real diagnosis time.

What it is not

• Not file contents: the files involved were verified clean; the text existed only in the tool-result channel.
• Not hooks: no PreToolUse/PostToolUse/Bash-wrapping hooks configured (only a Notification sound hook).
• Not model confabulation on the receiving side: the text exists in the emitting session's transcript first, timestamped.

I can share redacted transcript excerpts (JSONL lines with timestamps/tool_use_ids) privately if useful — the full transcripts contain personal data I won't post publicly.