[Bug] Tool-layer unreliability in long/compacted sessions: duplicated results, delayed delivery, empty/garbled file reads

Bug Description

Claude Code bug report

Subject: Tool-layer unreliability in long/compacted session — duplicated + delayed results, empty/garbled file reads

Environment

• Claude Code CLI version: 2.1.158
• Model: Opus 4.8 (1M context) — claude-opus-4-8[1m]
• OS: macOS (Darwin 25.5.0), Apple Silicon, zsh
• Session: long-running, had been /compact'd at least once; /effort max; 1M context
• Pattern: frequent parallel tool calls (multiple Bash/Read in a single turn)

Summary

In a long, previously-compacted session, the tool-execution layer became
unreliable. Results were duplicated and delivered in delayed batches, the Read
tool intermittently returned empty content for non-empty files, and at least one
read returned corrupted output. This caused the agent to re-issue commands, act on
stale/mismatched data, and produce an incorrect edit plus an inaccurate
(already-pushed) git commit.

Symptoms (most → least reproducible)

1. Duplicated tool results — identical Bash/Read outputs returned 2–3× within

the same turn.

1. Delayed, batched delivery — tool calls appeared to return nothing; the

results (originals + retries) then arrived together in one large batch a turn or
two later. This is the root cause of the re-issue → duplication loop.

1. Read returns "empty file" for a non-empty file — a 600+ line source file

read as empty / "shorter than offset," then succeeded on retry.

1. Garbled Read output — non-monotonic line numbers (e.g. line 166 followed

by line 163) and stray fragments, i.e. corrupted rendering rather than real file
content (observed at least once).

Impact

• Wasted cycles re-running commands that had actually succeeded.
• Agent briefly concluded work was complete based on file content that didn't match

the real repo (caught later via git).

• A string-match edit was built from stale content → silent no-op → an inaccurate

commit message pushed before a delayed background (Codex) result arrived.

Likely triggers

• Long session lifetime + at least one /compact; large (1M) context; bursts of

parallel tool calls. Short/fresh sessions did not exhibit the empty/garbled reads.

Severity

High for long sessions — output you can't trust forces re-verification of
everything and can drive wrong actions (bad edits/commits) on a live codebase.

Environment Info

• Platform: darwin
• Terminal: WarpTerminal
• Version: 2.1.158
• Feedback ID: 50a522ac-22c8-4038-b9d2-ee5a3f8214e8

Errors

[]