claude-code - 💡(How to fix) Fix [Bug] File read errors not surfaced, causing hallucinations in tool use

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

I'm having a ton of trouble with Claude Code on Linux this week and I do not think it is the model that is causing the problem. What I am seeing is that Claude will scan files (or do almost any tool use) and the file it scans will return empty for some reason, or there is some kind of tool use error, and instead of observing the tool use error it assumes the file is empty... or it re-triggers the tool use causing session bloat some other way. This also seems to be causing it the models to hallucinate very frequently. Here's an example:

Root Cause

So, I go through the planning phase, and planners keep bulldozing each other's work because they think something is not done that is done, or they keep looping on bizarre issues. It causes context and tool uses to explode all the time, and in order to get anything done I have to use max effort, because that is the only way to get it to realize that it is hallucinating (but it also causes the session to be astronomically more expensive). It's a shame, because 4.8 seems like a good model, but the Claude Code terminal application seems to be consistently face planting. I think this because ALL models seem to be having the same issue, it's just that 4.8 seems to be recovering from the issue faster and more cleanly from my perspective.

Code Example

The full tool output finally flushed — and it surfaced a critical fact that reverses the tag decision I made. Let me correct course.
My earlier @ignore @wip choice rested on a glitched read of a non-existent file (crates/clam-bdd/tests/steps/world.rs does not exist — the Read errored). The real filter is in
crates/clam-bdd/tests/bdd.rs:61 + src/lib.rs:9, and it blocks only legacy/ignore (always) + slow/doc (conditional). The complete grep (delayed flush) shows:
- @deferred — 7 occurrences, all in the sibling dev_visual_diagnostics.feature, always as @deferred @ignore (the established convention for deferred dev scenarios).
- @wip — 0 occurrences. It is not in the corpus and not recognized by the filter.

So the architect's original @deferred @ignore was right, and my "correction" to @ignore @wip was wrong — it would have invented a novel decorative tag and mismatched every plan doc (which all say @deferred @ignore). Functionally both filter (via @ignore), but @deferred @ignore is the correct, grounded convention. Fixing now.
RAW_BUFFERClick to expand / collapse

Bug Description

I'm having a ton of trouble with Claude Code on Linux this week and I do not think it is the model that is causing the problem. What I am seeing is that Claude will scan files (or do almost any tool use) and the file it scans will return empty for some reason, or there is some kind of tool use error, and instead of observing the tool use error it assumes the file is empty... or it re-triggers the tool use causing session bloat some other way. This also seems to be causing it the models to hallucinate very frequently. Here's an example:

The full tool output finally flushed — and it surfaced a critical fact that reverses the tag decision I made. Let me correct course.
My earlier @ignore @wip choice rested on a glitched read of a non-existent file (crates/clam-bdd/tests/steps/world.rs does not exist — the Read errored). The real filter is in
crates/clam-bdd/tests/bdd.rs:61 + src/lib.rs:9, and it blocks only legacy/ignore (always) + slow/doc (conditional). The complete grep (delayed flush) shows:
- @deferred — 7 occurrences, all in the sibling dev_visual_diagnostics.feature, always as @deferred @ignore (the established convention for deferred dev scenarios).
- @wip — 0 occurrences. It is not in the corpus and not recognized by the filter.

So the architect's original @deferred @ignore was right, and my "correction" to @ignore @wip was wrong — it would have invented a novel decorative tag and mismatched every plan doc (which all say @deferred @ignore). Functionally both filter (via @ignore), but @deferred @ignore is the correct, grounded convention. Fixing now.

So, I go through the planning phase, and planners keep bulldozing each other's work because they think something is not done that is done, or they keep looping on bizarre issues. It causes context and tool uses to explode all the time, and in order to get anything done I have to use max effort, because that is the only way to get it to realize that it is hallucinating (but it also causes the session to be astronomically more expensive). It's a shame, because 4.8 seems like a good model, but the Claude Code terminal application seems to be consistently face planting. I think this because ALL models seem to be having the same issue, it's just that 4.8 seems to be recovering from the issue faster and more cleanly from my perspective.

I experience this issue when I start with a fresh instance. The example I gave you is from a Claude Code session that I had just started. The session that I am submitting this bug report from is a perfect example.

/doctor ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Diagnostics ├ Currently running: native (2.1.158) ├ Commit: 96d5f49347b9 ├ Platform: linux-x64 ├ Path: /home/jared/.local/share/claude/versions/2.1.158 ├ Config install method: native └ Search: OK (bundled) Updates ├ Auto-updates: enabled ├ Auto-update channel: latest ├ Last update attempt: failed (install_failed) — 2026-05-31 ├ Stable version: 2.1.149 └ Latest version: 2.1.158 Background server └ Status: not running └ Mode: ephemeral └ See claude daemon status for details Remote Control └ Status: enabled └ ✓ First-party provider (api.anthropic.com) └ ✓ Not inside a remote session └ ✓ Not disabled by org policy (disableRemoteControl) └ ✓ claude.ai OAuth token present └ ✓ claude.ai subscriber auth active └ ✓ OAuth token has user:profile scope └ ✓ Organization UUID resolved └ ✓ Feature-flag evaluation enabled └ ✓ tengu_ccr_bridge gate (no server response this session) └ isGrowthBookEnabled=true └ telemetryDisabledBy=none └ DISABLE_GROWTHBOOK=unset └ hasFreshGrowthBookFeatures=false └ growthBookFeaturesLoaded=278 └ growthBookLastFetched=21m ago └ tengu_ccr_bridge=true Some skill descriptions will be shortened 1 description exceeds the per-entry cap: product raise skillListingMaxDescChars (currently 1536) in settings.json Opting in would cost ~6k tokens for skills every session and uses rate limits faster Version locks └ 2.1.158: PID 13659 (running)

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [Bug] File read errors not surfaced, causing hallucinations in tool use