[BUG] Model re-reads an unchanged file in a loop, ignoring repeated "Wasted call — file unchanged" rejections (bare rejection gives a context-corrupted model nothing to recover from)

Preflight

• This is a single bug report.
• Found by post-hoc audit of the session transcript JSONL.

What's Wrong?

The model reads a file, receives the content, then on a later turn requests the same file
again with no intervening change. The harness returns Wasted call — file unchanged since
your last Read. Refer to that earlier tool_result instead. The model does not adapt — it
re-issues the same read, gets the same rejection, and repeats. This is not a one-off: it
appeared independently in a subagent (during planning) and in the main session (during
implementation) in the same session.

Two distinct problems:

1. Model: repeated identical rejections do not change behavior; there is no loop-escape

heuristic ("I already have this; stop asking").

1. Harness: the Wasted call rejection returns no content and no actionable

alternative, so a model that has lost track of context has nothing to recover from — it
can only re-ask.

Environment

• Claude Code 2.1.156 (desktop)
• Model: claude-opus-4-8

Evidence

• Main session: Read of two files succeeds, then both are re-read on subsequent turns;

three consecutive Wasted call rejections; the loop continues until the session stalls with
no output. (In this instance the loop was triggered/worsened by a server-side fault that
returned duplicate message.ids, breaking the model's view of what it had already read —
filed separately — but the loop behavior is general.)

• Plan subagent: ~7 Wasted call events on several files during planning; the agent only

progressed by falling back to cat.

The recurrence across two independent contexts in one session indicates a systemic handling
gap, not random drift.

Expected vs Actual

• Expected: a redundant read is satisfied from cache (or rejected once, after which the

model proceeds); it never becomes an unbounded loop.

• Actual: re-reads loop on repeated bare rejections until the session stalls.

Asks

1. Give the model a loop-escape: after one Wasted call for a given file, do not re-issue the

identical read.

1. Reconsider the rejection payload — return the cached content (or a usable reference) rather

than a bare "refer to the earlier result," which a context-corrupted model cannot act on.

1. As a backstop, cap repeated identical failing tool calls at the harness level (companion

report, filed separately).

Related issues reviewed — why this is distinct

• #53578 (closed, stale) — "Agent loops on Read tool when saving memory — re-reads same

file repeatedly." Nearest behavioral match, but different trigger (intent-drift while
saving memory, not corrupted responses), and it does not name the no-content-rejection half.
Closed as stale, not fixed — this report should reopen/extend it.

• #63935 (closed) — "Regression in 2.1.158: spirals into redundant/invented tool calls

during file reads." Same surface, but pinned to a 2.1.158 regression (2.1.157 clean); this
occurred on 2.1.156, so the behavior predates that regression.

• #55042 (open), #60722 (closed) — share only the harness half (rejection returns no

content) but are triggered by rewind/revert state desync, not voluntary re-reads.

• #60684 (open) — the inverse (stale cache when a file is edited externally).

Unique here: a voluntary re-read of a genuinely-unchanged file + the model ignoring repeated
identical rejections + the bare no-content rejection + reproduced in both a subagent and the
main session in one session.