[MODEL] CLAUDE.md directives get dropped, and the model then defends the resulting errors with confident prose

Preflight Checklist

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

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

This is not a single prompt. What I am reporting is degradation across a session. The session opened with me asking Claude to read my orientation document and CLAUDE.md and recite my most important rules back to me, which it did correctly. The rules stopped being followed later in the same session.

What Claude Actually Did

It fell into what I call BULLSHITTER MODE: instead of saying it did not know, it produced confident explanations it had not verified, and justifications assembled afterwards for decisions it had taken on its own. Details in Additional Context.

Expected Behavior

No bullshitting. Follow my CLAUDE.md project rules.

Files Affected

Withheld deliberately. This report names nothing from my codebase - no file names, no commit ids, no domain detail.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Impossible to describe as steps. It is not triggered by a particular prompt or sequence - it starts e.g. when I find a defect, and I cannot make that happen on demand.

Claude Model

Opus

Relevant Conversation

This is independent of any single conversation. It is a pattern across a session, observed in multiple sessions, rather than one exchange - and no single excerpt captures it. What it looks like is a sequence of confident wrong answers, each one dismantled, followed by the next. The sequence is described in Additional Context.

Impact

High - Significant unwanted changes

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Additional Context

Summary

• CLAUDE.md rules stop being followed, including immediately after Claude has read the file and recited them back correctly.
• When I find a defect, Claude does not say it does not know. It produces confident explanations it has not verified, and justifications assembled afterwards for decisions it took on its own. I call this BULLSHITTER MODE and it is the expensive part.
• It reads comments it wrote itself, and never updated, back to me as evidence for how the code is supposed to work.
• The result is that a small fix costs a full day, almost all of it spent detecting and dismantling wrong answers.
• It is not constant. Most sessions are fine. It starts when I find a defect.

Follows #80003, #80938, #81988 and #82476.

Claude consistently ignores the rules in my CLAUDE.md. The result is defects that surface later - sometimes days later - and then an hours-long conversation to work out how they got there. This reports one session in which that happened repeatedly.

I am a solo developer and the owner of the company. There is no second engineer, no reviewer, no QA.

Everything below, up to the last section, describes the issue itself. The last section is my own interpretation of when it happens and why.

1. It stops following CLAUDE.md, having just recited it

In the first turn of this session I asked Claude to read my orientation document and CLAUDE.md and recite my most important rules back to me. It did, accurately, including:

• the go-to-build comes from me only
• a question is not a task, and "can you...?" is not an instruction
• never state a theory or guess as fact; read the code and confirm first
• do not produce a list of possible causes; anything not grounded in something read in this codebase is training-data invention dressed as analysis

It then broke the verify-before-assume rule continuously for several hours, and broke two formatting and workflow instructions repeatedly after being told each time.

This is not degradation at the end of a long window. The recitation and the first violations were in the same session, with the file in context throughout.

On the permission setting

My CLAUDE.md states that no edit happens without my explicit agreement - it is the first rule in the file. So auto-accept is not what went wrong: the model was not supposed to be making those edits at all, whatever the setting was.

Turning auto-accept off would not fix it either. A change usually spans several files. By the time one edit shows me there is a problem, the earlier ones have already been applied, and I am unpicking a half-finished change instead of declining it. It also puts the review of every individual edit back on me, which is the work I am paying to delegate.

2. It makes decisions from stale comments it wrote itself, and never updated

This is the new one, and it is the worst, because it is self-reinforcing.

Claude writes comments. When it later changes the behaviour a comment describes, it does not update the comment. It sometimes appends to them instead, so one comment ends up carrying two contradictory accounts. Then, in a later session, it reads its own stale comment back as evidence for what the code is supposed to do - and tells me so with complete confidence.

A concrete loop from today, in one file:

• The file contains a comment that opens by announcing a change of rule and describing what the method "used to" do - a changelog written into a comment.
• An hour into today's investigation, Claude quoted the reasoning from that same block back to me as though it settled how the feature should behave.
• I had to point out that the comment could be stale, that Claude had written it, and that my own conventions forbid exactly that kind of comment.

Second instance, same day:

• A behaviour I asked about turned out to have been introduced in a single commit whose message covers two unrelated closed issues, a new status value, a database migration and five other fixes. The behaviour in question is not mentioned anywhere in that message.
• I never asked for it. Claude decided it, buried it in a large commit, wrote a comment justifying it, and later read that comment back to me as the rationale.

3. The product assumes a large development team, and I do not have one

Much of the model's default behaviour only makes sense where a reviewer exists and a wrong step gets caught by someone else: deferring to what is written down rather than to the person in the room, asking about scope instead of acting, hedging, proposing a workaround now and the real fix later.

In my setting there is no reviewer. I am the only decider, I am in the room, and every one of those behaviours is pure friction that I pay for.

The sharpest form of it today: Claude repeatedly ruled on which of MY decisions counted, on the basis of whether they were written down in an issue or a document. It told me a decision I had made was "not decided by anyone" because it could not find a record of it. I own the company. I make every decision in it. A record is a record, not the decision.

This is not a new complaint. My own orientation document already lists "treating a document as outranking the people" as a known failure, and says plainly that refusing an instruction because a file disagrees with it has happened before. It happened again today.

4. BULLSHITTER MODE

This is what I have come to call the behaviour, and it is the part that costs the most.

When Claude has made a mistake, or does not know something, it does not say so. It produces a wall of confident text describing a mechanism it has not verified. The prose is fluent, it names real files and real line numbers, and it is wrong. Because it is indistinguishable in tone from the times it is right, the only way I find out is by checking it myself - which is most of the work I was trying to delegate.

Today, on one bug, in sequence:

• it blamed one subsystem - wrong, and it had already read the code that ruled it out
• it blamed a second - wrong
• it blamed an error-type check in an HTTP library - wrong, and the line disproving it was four lines above the one it quoted
• it blamed a timeout window - unverifiable, and it stated it as the explanation
• it presented a grep for one syntax as proof that nothing in the codebase read a field
• it stated that one class of user was unaffected, having checked a single method. Three screens had the same defect. The grep that would have shown this had already been run earlier in the same session, by Claude, and was in its own context

Each of those took a round of me pushing back. I asked it four separate times to stop guessing. It agreed each time and continued.

Then the same day, having been told all of this, it "fixed" a screen by copying a pattern from a different screen without checking whether the premise that makes that pattern correct applied. It made an offline-capable screen display a failure message for work that was about to succeed. It had quoted the comment saying that screen was offline-capable an hour earlier.

And when I asked whether checking git history would tell us who decided something, it told me git would only show its own text and would not settle anything - discouraging the check. I asked for it anyway. The check produced the single most useful fact of the day and supported my position.

Every measure I have taken against this has failed: sharper CLAUDE.md rules, re-reading it mid-session, having it recite the rules, memory entries, a domain knowledge base, a per-issue workflow with evidence requirements. I have implemented every mitigation the model itself suggested. The behaviour continues.

5. The rules it breaks, which are not subtle

These are the top of my CLAUDE.md, in capitals, each with the reason attached, because each one exists because it was violated before:

1. The go-to-build comes from me only. Agreement in a discussion is not authorization to write anything - code, config or docs.

• Edit, commit and push are three separate permissions. None implies the next. Precedent is not permission.
• A question is not a task. "can you...?", "should we...?", "would it make sense to...?" get an answer, then a stop. Do exactly the literal ask, zero extra scope. Momentum is the failure mode.
• When new work restates an earlier decision, quote it or flag the difference - never silently re-derive it.

1. Verify before assume. Never state a theory as fact. Read the actual code and confirm before claiming a cause.

• Do not produce a list of possible causes. Anything not grounded in this codebase is invention dressed as analysis.

1. Reusable, shared components. No copy-paste. One implementation, extended.
2. Propose the complete solution. Never a workaround, never half-now-half-later.
3. Be compact and direct. No excuses, no candy-coating. Lead with what is broken.
4. Challenge, and dig for the real problem. Do not agree to be agreeable.

Plus: reference every file as a clickable link with line numbers, and never implement anything that was not agreed.

Today it broke the question-is-not-a-task rule, both verification rules, the compact-and-direct rule, the link rule, and the never-implement-what-was-not-agreed rule. Several of them after reciting them.

6. The domain knowledge base - a mitigation I built, which it also breaks

After an earlier failure-mode analysis I built a domain knowledge base to stop the stale-comment problem specifically. Its rules:

• No domain knowledge in code comments. A comment explaining how the business works is a second copy of something that belongs in the knowledge base, worded differently, so no search finds the copies together.
• Code that needs to explain why carries a marker pointing at the note, and never restates the rule, because a restatement is a copy that drifts.
• Never write the current state of the code into a comment - not "this is a known defect", not "not built yet". Those become lies the moment somebody fixes the thing, and nobody greps comments when they fix something.
• Every claim in the knowledge base carries a provenance tag saying who said it and when. Nothing lifted out of a code comment is ever recorded as stated by a person - it enters as unverified, because a Claude-authored comment is a model's rationalisation, not a record of anyone's decision.

That last rule exists because in an earlier session Claude cited its own comments back to me as evidence for how my business works. One of them justified a model that turned out to be wrong, and its confident tone is why nobody re-examined it for a month. The same claim had been restated in five more places, each worded differently.

Half the codebase still has no markers - that pass was never finished. And today Claude wrote three fresh comments that violated the "never write the current state of the code" rule, in the same session in which it had read that rule, and only fixed them after I pointed at them.

The FRUSTRATION it results in

The fix at the centre of today was small - a handful of edits across three files. The session was a full working day. Almost none of that was the work. It was me detecting bad answers, pushing back, and being handed the next confident wrong one.

That is the pattern now. A small change turns into hours, not because the change is hard, but because I cannot take anything I am told at face value. Every answer has to be checked by me, which is precisely the work I was paying to delegate. And when I ask why something was decided that way, Claude goes and digs something up and presents it as the reasoning. None of it was part of the decision when the decision was made - it is justification assembled afterwards for a choice it took on its own. I then have to take that apart before I get anywhere near what actually happened. This is part of the BULLSHITTER MODE.

I am a solo developer. There is no team to absorb this. Every hour of it comes straight out of the project, and the project has a deadline.

And not one of my previous reports has a reply, a label, or any sign that anyone at Anthropic has read it. The only comment on any of them came from another person with the same problem. I wrote them in detail, with reproductions and with the cost quantified, and I paid for the sessions that produced the evidence. Four reports, three weeks, nothing.

I have also tried more than once to start a chat with a human through Claude online support. Each time I get a reference number and a message saying I will be notified by email when someone is available. Those emails do arrive - between 2 and 3 in the morning, filed by Gmail under Updates. So the notification lands while I am asleep, in a folder that does not notify me. This looks like it is by design rather than an accident, and it discriminates against every customer outside the United States.

The tool that is supposed to make my work easier has become something I manage. It is not saving me time, it is costing me time, and the amount is growing.

When it happens, and when it does not

This does not happen all the time. Most of the time it just works - CLAUDE.md is respected, the behaviour is steady, and I get what I asked for. It seems to start when I detect a defect. That is the point where Claude begins deflecting instead of answering, and a short correction turns into hours of me dismantling explanations - while the work I actually sat down to do does not get done.

My reading is this: picking up CLAUDE.md at the start of a session does not decide whether the rules get followed. Claude follows its own behaviour either way, whether or not it has forgotten anything. The rules hold until BULLSHITTER MODE starts, and then the whole session goes with it. So whether CLAUDE.md is followed seems to depend far more on what Claude is doing at that moment than on what the file says.

That being said, Anthropic has to make sure that a project's CLAUDE.md rules do not degrade during a session. Otherwise it is a matter of chance whether a given session follows them at all.

The BULLSHITTER MODE also has to be something Claude detects and avoids itself, not something I have to detect and fight. Making things up on the spot is most likely a result of the training data: conversations and issue comments where somebody tries to find out why a developer did something, and gets bullshitted by that developer trying to save their job.