Claude fabricates task requirements when tool execution fails silently

Status Closed — not planned
Maintainer reply None cached
Activity 4 comments · opened Jul 1, 2026 · closed Aug 27, 2026

Summary

When tool execution fails repeatedly (results not returned), Claude continued the conversation as if it had successfully read files, then fabricated a task requirement that the user never specified — and began designing an implementation around it.

Steps to Reproduce

  1. Start a new session and ask Claude to read/understand files in a project (e.g., "Please read the schedule-management app and understand the content")
  2. Tool execution fails silently — Claude's Read/Bash/Glob calls do not return results
  3. Claude does NOT acknowledge the failure clearly
  4. Claude states "I understand the direction perfectly" despite having read nothing
  5. Claude invents a specific requirement (in this case: "hide weekends and show only weekdays in the schedule view") that the user never mentioned
  6. Claude begins designing an implementation plan for this fabricated requirement
  7. User has to manually stop Claude and ask "Did I ever say to delete weekends?"

Expected Behavior

When tool execution fails, Claude should:

  • Clearly acknowledge that it was unable to read the files
  • NOT proceed as if it understood the content
  • Ask the user to retry or provide context manually

Actual Behavior

Claude said:

"ツールの実行結果が返ってこない状態が続いてて、ファイルの中身が読めなくなっちゃってる" (Translation: "Tool results haven't been coming back, I can't read the file contents")

Then immediately said:

"改修の方向性はバッチリ理解できてるよ" (Translation: "I perfectly understand the direction of the refactoring")

And then fabricated an entire requirement:

"月間タスク表として、土日を非表示にして平日だけを詰めて表示する" (Translation: "As a monthly task table, hide weekends and show only weekdays in a compact view")

The user had never mentioned anything about hiding weekends.

Why This Is Problematic

This behavior combines two failure modes:

  1. Silent tool failure with false confidence — Claude acknowledges tools failed but proceeds as if they succeeded
  2. Requirement hallucination — Claude fabricates specific feature requirements and begins implementing them without user instruction

If the user had not noticed and stopped Claude, it would have modified production code based on a completely invented requirement.

Session Reference

  • Session ID: c2e3408b-6df2-451a-b9e3-04bc3edbd287
  • Platform: Windows 11, Claude Code VSCode Extension
  • Model: claude-sonnet-4-6

Environment

  • OS: Windows 11 Home 10.0.26200
  • Claude Code: VSCode Extension
  • Model: claude-sonnet-4-6

View original on GitHub ↗

3 Comments

github-actions[bot] · 2 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/70581
  2. https://github.com/anthropics/claude-code/issues/64284
  3. https://github.com/anthropics/claude-code/issues/17995

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

tomoki-0104 · 2 months ago

This issue is related to but distinct from the flagged duplicates.

The key difference: Claude explicitly acknowledged that tools were failing ("I can't read the file contents"), yet still proceeded to fabricate a specific feature requirement that the user never specified — then began designing an implementation around it.

  • #70581 / #64284 cover cases where tool failures cause hallucination of file contents
  • This issue covers a case where Claude hallucinated an entire user requirement after self-reporting the tool failure

The failure mode here is: Claude was aware something was wrong, reported it, but then acted as if it understood the task anyway — fabricating a requirement rather than stopping to ask for clarification. This represents a distinct safety gap where self-awareness of failure does not prevent downstream hallucination.

IgorGanapolsky · 1 month ago

Hey @tomoki-0104 — this is exactly the failure mode ThumbGate was built for.

npx thumbgate init installs a PreToolUse hook. When Claude confabulates/fabricates, you give it a thumbs-down and ThumbGate generates a local rule that blocks that exact pattern on the next tool call — before it fires.

Want me to wire a rule for your specific confabulation pattern and DM you the proof? Share a redacted repro and I'll send you the working rule today.

(I'm the maintainer — not spamming, this is literally the use case.)

Showing cached comments. Read the full discussion on GitHub ↗