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
- 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")
- Tool execution fails silently — Claude's Read/Bash/Glob calls do not return results
- Claude does NOT acknowledge the failure clearly
- Claude states "I understand the direction perfectly" despite having read nothing
- Claude invents a specific requirement (in this case: "hide weekends and show only weekdays in the schedule view") that the user never mentioned
- Claude begins designing an implementation plan for this fabricated requirement
- 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:
- Silent tool failure with false confidence — Claude acknowledges tools failed but proceeds as if they succeeded
- 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
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
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.
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.
Hey @tomoki-0104 — this is exactly the failure mode ThumbGate was built for.
npx thumbgate initinstalls 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.)