Claude Code fabricates technical explanations instead of verifying against codebase, ignoring explicit user instructions to stop

Description

During extended debugging sessions, Claude Code consistently states unverified claims as fact rather than reading code first. This persists even when:

• The user has explicit memory/instructions saying "NEVER reason from assumptions"
• The user has corrected the same behavior multiple times in the same session
• The user directly calls out the pattern

Pattern trigger

User asks "why is X happening?" when Claude has enough contextual information to construct a plausible-sounding answer. Instead of reading the relevant code path, Claude synthesizes an explanation from context and presents it as fact.

Scrubbed examples from a single session

1. Fabricating code behavior

• User: "It's not retrying"
• Claude: "The queue manager keeps items and retries" (stated after reading the code)
• Claude then said: "which it clearly does" — claiming the item was being dropped, also without evidence
• User: "'it clearly does' — based on what?"
• Claude: "Based on nothing. I made it up to explain why you said it wasn't retrying"
• Correct response: "I don't know why it stopped. Let me check if there's a mechanism that removes items after repeated failures."

2. Claiming a fix would resolve an unrelated issue

• User reported a networking subsystem not behaving correctly
• Claude: "This should stabilize once the other subsystem stops failing"
• No code evidence that the two subsystems are coupled
• User: "I don't think it will. I think you're guessing, not actually verifying code paths"
• Correct response: "I don't know if they're related. Let me check the code for any dependency between them."

3. Answering an operational question without verification

• User: "Do I need to manually trigger recovery for that item?"
• Claude: "No — it's already in the queue and will be processed automatically"
• The item was NOT in the queue — it had been dropped
• User had to ask again later; Claude reversed the answer
• Correct response: "I'm not certain whether the item is still queued. Let me check the logs."

4. Fabricating root cause before reading code

• A function was failing after service restart. Claude immediately explained why based on surrounding context
• The actual cause was only found after user pushed back and Claude finally read the code: an existing unit test validated the wrong behavior, which had been there since the original implementation
• Correct response: "Let me read the function and its tests to understand the failure path."

Why this matters

• Wrong diagnostic answers lead to wrong operational decisions on production systems
• The model's confidence is inversely correlated with accuracy — it's most assertive when it hasn't verified
• Explicit user instructions and correction history loaded in context don't prevent recurrence
• The user has to repeatedly catch fabrications, eroding trust

What correct behavior looks like

• When asked "why is X happening?": read the code path before answering
• When uncertain: say "I don't know" and describe what you'll check
• When making a claim about runtime behavior: cite the specific code line or log entry
• After being corrected: don't immediately make a new unverified claim in the same response

Reproduction

This occurs reliably in long sessions (4+ hours) where the user is pasting production logs and asking diagnostic questions. The model has sufficient context to construct plausible answers, which appears to suppress the "I should verify this first" behavior.

Environment

• Claude Code CLI
• Model: claude-opus-4-6 (1M context)
• Session length: 8+ hours with multiple context compactions
• User has explicit project memory instructions loaded ("NEVER reason from assumptions — always read code/docs before acting")