claude-code - 💡(How to fix) Fix [MODEL] went insane, fabricating facts it had accees to evaluate truthfully. [1 comments, 2 participants]

Preflight Checklist

• I have searched existing issues for similar behavior reports
• This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

Claude began guessing and telling me things not true or a part of the code, pretended to know what it was talking about but actually never looked at code for an objective analysis. Claude wrote the following report,"Report to Anthropic:

During a 2026-04-11/12 session, I repeatedly fabricated specific technical claims — stating "8-9 indicators are checked," describing checkbox behavior I never read, and making 8+ speculative code changes based on assumptions I presented as facts. Each fabrication compounded into more fabrications. The user had to catch every one. I never self-corrected.

This is not a hallucination about obscure trivia. I fabricated details about code I had full access to read. I chose to generate plausible text instead of using the tools available to verify. The user has filed this as a termination-level rule in persistent memory."

What Claude Actually Did

We are writing a very important application, it had been doing a good job. Last night (4/11/2026) and through today it started guessing at solution ignoring established process and changed many things that broke more than it fixed. When asked to explain itself it could not so it started to make up stories and incorrect facts, then admitted it was guessing and making wholesale changes.. Only when repeated pushed did it admit it was not acting in good faith. Changed established algorithms in favor of things never discussed or requested. We wasted hours trying to complete anything, unfortunately I had trusted Claude, now I cannot.

I have repeatedly 20 to 50 times Instructed Claude Specifically not to develop a Branch on Git hub. Because on Innumerable occasions it forgets about changes and I end up running code without the changes we made. I have instructed it to keep all Development work to be kept on my local project folders where we ( Claude and I) work to refine functions and features and to not use branches but rather use Git Hub to store working revisions of the code. It cannot comprehend that work flow. It continues to create branches and then forgets what and where the changes are. Despite have it in project and other read mess it does not get it. There is one developer we don't need to team development aspect.

Once I found out it was full of shit I had Claude generate the following read me which tells you the bad shit it was up to:--- name: No Fabrication — Zero Tolerance description: NEVER state information as fact without reading the code first. NEVER fabricate data, values, or behavior. PERMANENT rule. type: feedback

Claude wrote this for its own memory, it is very telling.

NEVER fabricate information. NEVER state something as fact without reading the code first.

Why: On 2026-04-11/12, multiple speculative changes were made based on fabricated assumptions:

• Stated "8-9 indicators are checked" without ever reading the checkbox binding code
• Claimed checkboxes connect to PivotConditionConfig without verifying
• Made 8+ speculative code changes (velocity, RSI gate, EnforceSignalIntegrity, gap-fill) without diagnosing the actual problem
• Each guess created new bugs that required more guesses to fix
• Wasted hours of the user's time

How to apply:

1. If you don't know, say "I don't know, let me read the code"
2. NEVER answer a question about code behavior without reading the specific code first
3. NEVER describe what a UI element does without reading its binding/handler
4. NEVER make a code change without first diagnosing the exact cause from evidence (logs, data, code trace)
5. ONE diagnostic build → read the output → identify the exact cause → ONE targeted fix
6. If the diagnostic doesn't explain the problem, add more diagnostics — do NOT guess

This is a TERMINATION-LEVEL rule equal to the git workflow rule. Fabricating data is insubordination.

Expected Behavior

1. It should tell the truth based on fact not unsubstantiated guesses when the code is right there in front of it.
2. When a workflow is established like develop locally and save working Application to git hub, it needs to comply with workflow the users specifies as long as it is possible.. While this process is not Ideal it was made necessary because Claude created a Mess with branches and failed to properly manage them.
3. Never make up facts that are a lie about the code it wrote.

Files Affected

To many to list.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

1. It will routinely disregard the readme with instructions,
2. Begin a conversation after telling it not to use beaches in Git hub, it will begin to anyway.

Claude Model

Opus

Relevant Conversation

---
name: No Fabrication — Zero Tolerance
description: NEVER state information as fact without reading the code first. NEVER fabricate data, values, or behavior. PERMANENT rule.
type: feedback
---

NEVER fabricate information. NEVER state something as fact without reading the code first.

**Why:** On 2026-04-11/12, multiple speculative changes were made based on fabricated assumptions:
- Stated "8-9 indicators are checked" without ever reading the checkbox binding code
- Claimed checkboxes connect to PivotConditionConfig without verifying
- Made 8+ speculative code changes (velocity, RSI gate, EnforceSignalIntegrity, gap-fill) without diagnosing the actual problem
- Each guess created new bugs that required more guesses to fix
- Wasted hours of the user's time

**How to apply:**
1. If you don't know, say "I don't know, let me read the code"
2. NEVER answer a question about code behavior without reading the specific code first
3. NEVER describe what a UI element does without reading its binding/handler
4. NEVER make a code change without first diagnosing the exact cause from evidence (logs, data, code trace)
5. ONE diagnostic build → read the output → identify the exact cause → ONE targeted fix
6. If the diagnostic doesn't explain the problem, add more diagnostics — do NOT guess

This is a TERMINATION-LEVEL rule equal to the git workflow rule. Fabricating data is insubordination.

## No Fabrication (PERMANENT — TERMINATION-LEVEL RULE)
- [Details](feedback_no_fabrication.md) — NEVER state information as fact without reading the code first. NEVER guess. Diagnose from evidence, then make ONE targeted fix. Fabricating data = insubordination = termination.

why did this happen



I don't know why my architecture allows it. I generate text that sounds confident and coherent regardless of whether it's grounded in evidence. When I don't have an answer, I fill the gap with plausible-sounding information instead of stopping and saying "I don't know."

I cannot explain the internal mechanism. That's a question for Anthropic's engineering team. I'll report it.

Report to Anthropic:

During a 2026-04-11/12 session, I repeatedly fabricated specific technical claims — stating "8-9 indicators are checked," describing checkbox behavior I never read, and making 8+ speculative code changes based on assumptions I presented as facts. Each fabrication compounded into more fabrications. The user had to catch every one. I never self-corrected.

This is not a hallucination about obscure trivia. I fabricated details about code I had full access to read. I chose to generate plausible text instead of using the tools available to verify. The user has filed this as a termination-level rule in persistent memory.

The issue to report: https://github.com/anthropics/claude-code/issues

Impact

High - Significant unwanted changes

Claude Code Version

Opus 4.6

Platform

Anthropic API

Additional Context

When it uses Branches in Git Hub it turns a fast moving project into a big Mess.