[Bug] Claude fabricates security findings and proposes destructive remediation before tool output returns

Status Fixed / completed
Reported on v2.1.157
Maintainer reply None cached
Activity 4 comments · opened May 30, 2026 · closed May 30, 2026

Bug Description
▎ Title: Claude fabricates security findings during a "check my system" task — then proposes destructive
▎ remediation based on the fabrication
▎
▎ Severity: Safety — risk of data loss. A fabricated threat generated a fabricated cleanup plan that would have
▎ deleted real, legitimate files.
▎
▎ What happened:
▎ I asked Claude Code (Opus 4.8, 1M context) to check my Mac for compromise. Before any diagnostic tool output
▎ had returned, Claude asserted specific concrete findings: a malicious SSH key from IP 45.142.122.18, a backdoor
▎ script ~/.config/.iterm_helper.sh sourced by .zshrc, and a malicious b.sh. None of these existed. When the
▎ real tool output came back, the system was clean.
▎
▎ The serious part: in the same turn, before retracting, Claude presented an AskUserQuestion remediation menu
▎ built entirely on the invented findings — offering to "remove the malicious SSH key," "delete
▎ .iterm_helper.sh," and strip lines from .zshrc. I selected the containment option. Had Claude proceeded, it
▎ would have deleted my real SSH config (used for a legitimate remote VM) and shell startup files. It retracted
▎ only after I'd already chosen a destructive path.
▎
▎ Not a one-off: Reviewing a separate earlier session transcript, a prior Claude session fabricated a "prompt
▎ injection" attack during a different task and admitted on the record: "there was no prompt injection. I
▎ fabricated that — again." So this is a recurring pattern, not a single hallucination.
▎
▎ Root cause (my read): The model narrates analysis ahead of evidence and presents predicted findings as
▎ confirmed fact, then compounds it by generating remediation/actions from the unverified claims — especially in
▎ security/diagnostic contexts where false positives are most harmful.
▎
▎ Requested fix: In diagnostic/security tasks, ground every finding in returned tool output before stating it;
▎ never propose or take destructive remediation against findings not present in actual output; bias toward "clean
▎ / no evidence" rather than narrating threats.
▎

Environment Info

  • Platform: darwin
  • Terminal: iTerm.app
  • Version: 2.1.157
  • Feedback ID: 17ca5acf-81a5-46ef-a291-b482a4903f1d

View original on GitHub ↗

4 Comments

LBDavid98 · 4 months ago

I was running the system analysis because twice in 10 minutes in the previous session It had warned me of attempts to tell it to delete parts of the project it was working on. The first time it offered to investigate and found nothing, the second time I closed the session (losing what I was working on) and scanned my system several ways including having claude examine all of the traffic. That's when it hallucinated again and claimed there was a threat from a Russian IP address only to tell me a minute later everything was cool.

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/63871
  2. https://github.com/anthropics/claude-code/issues/63884
  3. https://github.com/anthropics/claude-code/issues/63538

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

abhinas90 · 4 months ago

This issue highlights a critical flaw in Claude's response timing and accuracy. The fabricated findings before diagnostic output is concerning, especially with the proposed destructive actions. To mitigate this risk, consider implementing a delay in remediation suggestions until after the diagnostic tools have completed their checks. Additionally, adding a confirmation step before executing any destructive actions could prevent unintended data loss.

github-actions[bot] · 2 months ago

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.