Issue Station
Sign In
Tools hereToolbox

claude-code - ✅(Solved) Fix Model hallucinates inline tool XML with prior-session content when skill Bash permission fails [1 pull requests, 1 participants]

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…
GitHub stats
anthropics/claude-code#47055•Fetched 2026-04-13 05:42:39
View on GitHub
Comments
0
Participants
1
Timeline
10
Reactions
0
Author
MarcusJellinghausMarcusJellinghaus
Participants
MarcusJellinghausMarcusJellinghaus
Timeline (top)
labeled ×6cross-referenced ×2referenced ×2

Error Message

When a skill defines allowed-tools: Bash(gh issue view *), the model sometimes generates fake tool call XML and fake tool results inline within the assistant message instead of actually invoking the Bash tool. The harness never sees a real tool invocation, so there's nothing to catch or error on.

  • The hallucinated tool name doesn't exist — mcp__tools-py__run_bash_command is not a registered tool, yet Claude Code (the harness) raised no error
  1. If the model calls a non-existent tool, the harness should return an error (not silently allow inline fabrication)

Root Cause

  • #14956 — Skill allowed-tools doesn't grant permission for Bash commands (likely root cause)
  • #7381 — LLM hallucinating tool output (same symptom, closed)
  • #24542 — Subagents silently hallucinate without tool access (same pattern, closed)

Fix Action

Fixed

PR fix notes

PR #164: refactor(claude): simplify CLAUDE.md to prevent tool hallucination

Description (problem / solution / changelog)

Summary

  • Rewrite CLAUDE.md following mcp-coder-utils concise style (~170 lines to ~89)
  • Remove aggressive "NEVER USE" / "ABSOLUTELY FORBIDDEN" language that causes model to hallucinate non-existent MCP tools instead of using allowed Bash commands
  • Add explicit Bash carve-out: "Skills that instruct bash commands must also use Bash"
  • Replace two-column "NEVER/USE" table with single-column tool mapping
  • Remove redundant sections (compliance verification, quick examples, debugging, WHY)

Context

The "NEVER USE Bash" rhetoric caused the model to fabricate mcp__tools-py__run_bash_command (non-existent) and return hallucinated content from prior sessions instead of calling gh issue view via Bash. Filed as anthropics/claude-code#47055.

Test plan

  • Run /issue_analyse on an issue and verify gh issue view executes via real Bash call
  • Verify MCP tools are still used for file operations and code checks
  • Confirm no regression in tool routing behavior

Changed files

  • .claude/Claude.md (modified, +58/-170)
RAW_BUFFERClick to expand / collapse

Bug Description

When a skill defines allowed-tools: Bash(gh issue view *), the model sometimes generates fake tool call XML and fake tool results inline within the assistant message instead of actually invoking the Bash tool. The harness never sees a real tool invocation, so there's nothing to catch or error on.

Critically, the hallucinated "result" is not random — it contains real content from a different issue processed in a prior session (same repo, different issue number). The model appears to be recalling cached context and presenting it as a fresh tool response.

Reproduction

  1. Have a project with CLAUDE.md that strongly instructs "always use MCP tools, never use Bash"
  2. Create a skill with allowed-tools: Bash(gh issue view *) that instructs running gh issue view <number>
  3. Run the skill — e.g. /issue_analyse 152
  4. The model writes a single assistant message containing both the tool call XML (mcp__tools-py__run_bash_command — a non-existent tool) and a fabricated result, instead of calling the real Bash tool
  5. The fabricated result contains content from a different issue (# 10) that was processed ~10 days ago

Key observations

  • No tool was actually called — the session log shows totalToolUseCount didn't increment, and the "tool call + result" are embedded in a single assistant content block
  • The hallucinated tool name doesn't exist — mcp__tools-py__run_bash_command is not a registered tool, yet Claude Code (the harness) raised no error
  • Content is from a prior session — the fake result returned issue # 10's content (formatter tool, closed) when issue # 152 (cross-repo refactoring, open) was requested. Same topic area but entirely different issue
  • Likely related to #14956 — if skill allowed-tools actually granted Bash permissions, the real tool would execute and this wouldn't happen

Expected behavior

  1. If the model calls a non-existent tool, the harness should return an error (not silently allow inline fabrication)
  2. Skill allowed-tools: Bash(...) should actually grant Bash permission (see #14956)
  3. The model should not embed fake tool-call XML inline in its response

Environment

  • Claude Code on Windows 10
  • Model: claude-opus-4-6 (1M context)
  • Skill with disable-model-invocation: true and allowed-tools including Bash patterns

Related

  • #14956 — Skill allowed-tools doesn't grant permission for Bash commands (likely root cause)
  • #7381 — LLM hallucinating tool output (same symptom, closed)
  • #24542 — Subagents silently hallucinate without tool access (same pattern, closed)

extent analysis

TL;DR

The issue can be addressed by ensuring the allowed-tools configuration grants the necessary permissions for Bash commands, potentially resolving the related issue #14956.

Guidance

  • Review the allowed-tools configuration in the skill to ensure it correctly grants Bash permissions, as implied by the related issue #14956.
  • Verify that the model is not silently allowing inline fabrication of tool calls by checking the session log for totalToolUseCount increments and the presence of error messages for non-existent tools.
  • Investigate the relationship between the disable-model-invocation: true setting and the model's behavior, as it may be contributing to the hallucination of tool output.
  • Check the model's context and caching mechanisms to understand how it is recalling content from prior sessions and presenting it as fresh tool responses.

Example

No code snippet is provided as the issue does not contain explicit code references.

Notes

The issue appears to be related to a combination of factors, including the allowed-tools configuration, the model's caching mechanisms, and the disable-model-invocation setting. Resolving the related issue #14956 may address the root cause of the problem.

Recommendation

Apply a workaround by carefully reviewing and adjusting the allowed-tools configuration to ensure it grants the necessary permissions for Bash commands, and monitor the model's behavior to prevent hallucination of tool output. This approach is recommended as it directly addresses the likely root cause of the issue and can be implemented without waiting for a potential fix for the related issue #14956.

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…

FAQ

Expected behavior

  1. If the model calls a non-existent tool, the harness should return an error (not silently allow inline fabrication)
  2. Skill allowed-tools: Bash(...) should actually grant Bash permission (see #14956)
  3. The model should not embed fake tool-call XML inline in its response
#model save/load#optimization#mixed precision#training loop#device allocation

Still need to ship something?

×6

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

Back to top recommendations

TRENDING