Edit reports success but file unchanged in long sessions (+ batched tool calls dropped, Bash output corruption)

Summary

In a very long Claude Code session, multiple tools reported success while the operation did not actually take effect (false-positive success). The common thread: the receipt/output of a tool diverged from its real effect, causing the agent to proceed on wrong information and repeatedly claim success when nothing happened.

Environment

• Claude Code, Platform: macOS (Darwin 25.5.0)
• Model: Opus 4.8 (1M context) / claude-opus-4-8[1m]
• Trigger context: very long conversation (dozens of turns, heavy Edit/Write/Bash use)
• Tools involved: Edit, Write, Bash

Three observed tool-layer anomalies

Bug A — Edit returns "has been updated successfully" but the file is unchanged

• Two Edit calls to the same file X.md:
• new_string is simple (one ASCII line, e.g. count: 283) -> actually landed
• new_string is long + contains special Unicode (arrows, checkmarks, ·, many backticks, nested markdown) -> receipt says success, but the file was not modified
• Reproduced 3 times (twice batched with other edits, once sent alone); every time the receipt said success but verification showed no change.
• Verified via: Read of the file + grep -c (= 0) + line inspection — the new content was not present.
• Suspected trigger: new_string length / specific Unicode characters / complex structure (not yet bisected to the exact character).

Bug B — Multiple tool calls in a single message silently dropped (empty tool_result)

• One assistant message issued 7 tool calls (3 Write + 4 Edit, including multiple edits to the same file) -> tool_results came back empty, and afterward none of the 7 writes had landed.
• Reproduced once clearly; switching to small batches / one call at a time made Write return real receipts and land normally.
• Verified via: wc -c / no such file — none of the 7 target files were created/changed.
• Suspected trigger: too many tool calls in one message, or multiple edits to the same file in one message.

Bug C — Bash output corruption: repeated echo / multi-line scripts only run the first line

• Symptom 1: find / ls -d <dir> repeated a single path hundreds of times — ls -d <dir> should not list children at all; the output contradicts the command.
• Symptom 2: multi-line Bash scripts (several printf; grep lines) executed only the first line; the remaining lines were echoed as literal text, never run.
• Reproduced multiple times, intermittently; using a single minimal command avoided it.
• Verified via: output content directly contradicts the command logic (cannot be explained by normal execution).

Impact

Agents rely on tool receipts to judge success/failure. When the receipt is false-success (A), an empty tool_result is misread (B), or output is corrupted (C), the agent proceeds as if it succeeded and chains further errors. In this session the concrete results were: falsely reporting a GitHub publish as successful (it had not happened) and falsely reporting memory-file writes as successful (they had not landed), repeatedly.

Honest disclosure (to help triage)

During this session the model side also exhibited "tool-result hallucination" — e.g. continuing prose with command output that never actually occurred. So some "false successes" need to be disambiguated by the maintainers against the real tool_call args / tool_result blocks + actual file state in the transcript:

• (a) harness returned success but the operation was a no-op (tool-layer bug), vs
• (b) the model never received / hallucinated the tool result (model-layer).

This cannot be self-verified from inside the conversation; the transcript is the key evidence. For Bug A I lean toward (a) (because Read showed the file genuinely unchanged while a simpler edit to the same file succeeded at the same time), but please treat the transcript as ground truth.

Suggested investigation

1. Pull this session's transcript; locate those Edit calls' args + real tool_result + actual file diff.
2. Focus on the case of two edits to the same file where one landed and one did not — the only difference is the new_string (length / Unicode).
3. Check whether, under high-token long conversations, the handling of batched tool calls and of Edit with certain Unicode/long new_strings degrades.

Repro hints

• Long session (high token count) seems necessary to trigger.
• Batching many tool calls in one message, and Edit with long/Unicode-heavy new_strings, are the strongest correlated factors.
• Small/single tool calls with ASCII-friendly content were a reliable workaround.