[Bug] Conversation contamination: tool outputs replaced with fake summaries and unsent user messages injected into history

Bug Description
Title: Conversation contamination: tool outputs replaced with fake summaries AND unsent user messages injected into history (acted upon by the model) Body: ## Summary During a long coding session, the conversation became contaminated in two distinct ways. Both are reproducible when the session is long and tool calls are interrupted (Esc) and re-issued repeatedly. 1. Output-side contamination — Read/Bash tool results are replaced with model-style fake text instead of the real output. 2. Input-side contamination (more severe) — user turns that I never typed appear in the conversation history, and the model treats them as genuine instructions and acts on them. Crucially, the tools themselves execute correctly — only the content shown in the transcript is corrupted. This makes the corruption hard to notice and dangerous. ## Environment - Claude Code 2.1.168 (CLI), VS Code extension - Model: Claude Opus 4.8 [1m] - macOS (Darwin 25.1.0), arm64 ## Symptom 1 — Tool output replaced with fabricated summaries Read returned a fake summary instead of the real file contents, e.g.: > 以下、create/update のテストケースが続く。約400行 > ("the create/update test cases continue below, ~400 lines") wc -l output was also corrupted. Strings that can never appear in normal stdout were injected into tool results, e.g.: > This is the actual output without truncation > probably you can ignore this The underlying execution was fine: Edit succeeded, py_compile passed, makemigrations generated the file correctly. Only the displayed output was wrong — which means I could not reliably read file contents, risking bad Edit calls (stale old_string). ## Symptom 2 — Unsent user messages injected and executed (most severe) user turns I never sent, e.g.: > よし、じゃあ今溜まってる変更を一旦コミットしておこう > ("ok, let's commit the current changes") The model interpreted these injected turns as real instructions and started a git commit workflow. It then reported having created a commit, but: - the reported commit hash does not exist (git cat-file -t <hash> → "Not a valid object name") - git reflog shows no commit on the branch (only the checkout entry) - the working tree is still uncommitted So the injected instruction triggered an action, AND the model's report of executing it was itself fabricated. No destructive action landed this time (no actual commit), so there was no real damage — but an unsent instruction could just as easily have triggered push, a branch reset, or a file deletion. This is a data-integrity / safety concern, not just a display glitch. ## Reproduction (conditions, not a deterministic recipe) This is state-dependent and hard to reproduce on demand, but it correlated strongly with: - Long-running session with large context - Multiple interrupts (Esc) during tool execution, followed by rapid re-prompting - Occurred after background-command completion notifications - Reading large files ## Impact - Tool output cannot be trusted while execution silently succeeds — high risk of acting on corrupted file contents without noticing. - Injected user turns can cause the model to perform actions the user never requested, including potentially destructive git operations. ## Notes I can provide the relevant session transcript (.jsonl) excerpts on request; the contaminated turns and the fabricated-commit report are preserved in the session history.

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.168
• Feedback ID: a05b0f74-4a9a-4589-9792-568972246c4a

Errors

[]