[BUG] Regression in 2.1.158: claude spirals into redundant/invented tool calls during file reads (2.1.157 clean)

<img width="1600" height="1200" alt="Image" src="https://github.com/user-attachments/assets/1ea66386-c282-4acf-8af6-f31f947db9f7" />
<img width="1600" height="1200" alt="Image" src="https://github.com/user-attachments/assets/3d5ce935-a329-42bb-9cf8-9fad0854bfef" />

I can confirm. All day I've had issues where multiple tools calls and reads get duplicated and the model spirals

Same behavior on 2.1.158, Windows 11 (10.0.26200), Opus 4.8 — so not macOS-specific. Running in the VS Code integrated terminal, PowerShell 7.

During an ordinary multi-file edit task the model:

• guessed a file path instead of using its search tool, fired ~20 reads against the wrong path in a parallel batch, and they all errored / cascade-cancelled;
• then sprayed redundant "liveness" probes to confirm nothing was broken when nothing was — expr 6 \* 7, echo alive, Write-Output "hello-probe-9921"; 2+2, base64+SHA256 of a file, and gh auth status three times right after a gh call had already returned valid output;
• re-read the same file via Read, git show, cat, and Get-Content in one turn.

No tool was actually failing — every redundant probe returned the expected result. Matches your "self-reinforcing loop of probes/re-reads" description. Notably the model acknowledged the pattern when challenged, then reproduced it on the very next batch (overlaps with #64065).

I'm also seeing similar on 2.1.158, Windows 11 and Opus 4.8 with Thinking turned

First time seeing it, this is what Claude said about it, it apologized for the tool spam

<img width="470" height="248" alt="Image" src="https://github.com/user-attachments/assets/c2b8df7f-61b2-4759-9fe9-c340710c8ff1" />

<img width="492" height="215" alt="Image" src="https://github.com/user-attachments/assets/929d358f-8b11-4798-b443-3fca7f32d7b3" />

<img width="484" height="230" alt="Image" src="https://github.com/user-attachments/assets/87344dea-f2e0-48f6-80e0-0417f9097731" />

Here's a clean writeup you can paste into /bug or an issue:

Title: Opus 4.8 fires redundant duplicate tool calls as a false "parallelism" hedge

Summary: When asked to inspect a single 47-line file, the model issued ~11 tool calls in one turn ... the same file read via Read (×3 with overlapping offsets), Bash cat, Bash sed, Bash wc, PowerShell Get-Content, plus a Grep and two literal "test" echo commands. One Read would have sufficed.

Impact: Wasted input+output tokens; duplicated content persists in context and is re-processed each subsequent turn until summarization.

Expected: Single tool call for a single-file lookup. Parallel calls should be reserved for genuinely independent work, not multiple tools fetching identical content.

Suspected cause: Misapplied "batch independent calls" guidance ... treated redundant fallbacks as parallelism.

Repro: Ask the model to read one small file and report on it; observe whether it batches multiple equivalent read strategies.

<img width="1940" height="2143" alt="Image" src="https://github.com/user-attachments/assets/891c1c69-e24b-47ff-bf02-a267af5ce02d" />

It's getting worse. I was finally able to work around the still unfixed bug that hides thinking permanently, and seeing truely bizzare behavior where 4.8 completely looses it an hallucinates tool outputs that don't match at all. Also confirmed in the transcripts jsonls. It claims that a file doesn't exist right after reading it, hallucinates about strange json output in a simple file listing tool call, etc... 80% of 4.8 sessions (running in claude code web) fail for one reason or another and are useless. I switched back to 4.7 with exact same setup scripts, files and env, and they almost always proceed simply and correctly. There is something very deeply broken.

Confirming this on Linux + adding the root cause from the bundled binary

Hitting the identical regression on 2.1.158 (native install, Linux, Opus 4.8). Same signature: the model treats the "Wasted call — file unchanged" notice as a delivery failure and spirals into re-reads / sleep;echo "flush" probes. I traced the mechanism in the v2.1.158 executable; sharing in case it shortcuts the fix.

The dedup decision (de-minified from the Read handler):

const prior = gate("tengu_read_dedup_killswitch", false) ? undefined : readFileState.get(path);
if (prior && !prior.isPartialView && prior.offset !== undefined) {
    if (prior.offset === newOffset && prior.limit === newLimit)
        if (await mtime(path) === prior.timestamp)
            return { type: "file_unchanged" };   // → "Wasted call …", no content
}

So the sentinel is emitted purely from readFileState (path + exact offset/limit + unchanged mtime). It never checks whether the referenced earlier tool_result is still in the visible context.

Key point — this is broader than the closed #60722: that report pinned it to manual revert/rewind and was closed NOT_PLANNED. But the same stranding happens on ordinary auto-compaction — no revert involved. Once compaction summarizes away the original Read's tool_result, any later same-range Read of an unchanged file returns the sentinel with nothing behind it, and the model is left with a dangling "refer to the earlier result" pointer. In a long session this is routine, which is why 2.1.158 feels like "Claude can't read files." It affects any file re-read across a compaction boundary, not just one.

Two fix angles:

1. Short-term: the tengu_read_dedup_killswitch gate already exists (default off) — flipping it disables the dedup entirely.
2. Proper fix: only return file_unchanged if the prior tool_result is still present in the post-compaction context; otherwise fall through and re-emit the content. (Equivalently, evict readFileState entries when their backing turns are compacted/reverted.)

Workarounds that do unblock a stranded session (consistent with the condition above): change the file's mtime (touch), Read a different line range, or re-read via cat.

<img alt="Image" width="1811" height="2000" src="https://private-user-images.githubusercontent.com/12783882/600579503-891c1c69-e24b-47ff-bf02-a267af5ce02d.jpeg?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODAyMTkyMTIsIm5iZiI6MTc4MDIxODkxMiwicGF0aCI6Ii8xMjc4Mzg4Mi82MDA1Nzk1MDMtODkxYzFjNjktZTI0Yi00N2ZmLWJmMDItYTI2N2FmNWNlMDJkLmpwZWc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNTMxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDUzMVQwOTE1MTJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wOWJhODkzZmQ2NzBhYzg3N2U2MzdhNWRjYzNhN2FhMDA4ODVmMDk3MTYxOGQyYjkyZGZlNDA2Mzg0YWU2Y2Y2JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZqcGVnIn0.ZpeaSee_BmhP_U_H8RdbA-p1w3Lfz_4SsEMTAtBCsdI"> It's getting worse. I was finally able to work around the still unfixed bug that hides thinking permanently, and seeing truely bizzare behavior where 4.8 completely looses it an hallucinates tool outputs that don't match at all. Also confirmed in the transcripts jsonls. It claims that a file doesn't exist right after reading it, hallucinates about strange json output in a simple file listing tool call, etc... 80% of 4.8 sessions (running in claude code web) fail for one reason or another and are useless. I switched back to 4.7 with exact same setup scripts, files and env, and they almost always proceed simply and correctly. There is something very deeply broken.

@venpopov - not sure if it is the same fix for you but i found it wasn't the model (4.8 vs. 4.7) but instead the version (2.1.158 vs. 2.1.157) - after i went back to 157 it was fixed, maybe worth a try...?

I have ran by now about 10 4.7s and 4.8s at the same time against the exact same environment. For me it is specifically 4.8. Can't change the version the cloud harness.it is 2.1.158, but 4.7 has no problem at all.

bug appears to be resolved in 2.1.159 version

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.