Claude Opus 4.6 systematically distrusts user observations, wastes tokens verifying facts users already stated (regression from Opus 4.5)

Environment

• Model: claude-opus-4-6 (regression — this did NOT happen with claude-opus-4-5)
• Platform: Claude Code CLI (Windows)
• Codebase: Tauri v2 + Vue 3 desktop app (~50k lines)

Summary

Claude Opus 4.6 has a systematic behavioral pattern: when a user reports a specific observation (e.g., "X is broken"), Claude does NOT directly investigate X. Instead, it spends significant tokens trying to prove the user's observation might be wrong, exploring alternative hypotheses that contradict the user's description.

This is a regression from Opus 4.5, which would trust user descriptions and go straight to the relevant code. Opus 4.6 consistently treats user observations as hypotheses to disprove rather than facts to act on.

Reproduction Pattern

1. User provides precise observation: "Component A shows value X, but it should show Y"
2. Claude SHOULD: go read Component A's code, find why it shows X
3. Claude ACTUALLY: questions whether user really sees X, checks if maybe
   the config file has the wrong value, investigates whether A and B are
   separate windows, etc. — everything EXCEPT looking at Component A's code
4. User corrects Claude: "My description is 100% accurate, just look at the code"
5. Claude apologizes, then repeats step 3 with a different hypothesis
6. User gives up, finds the bug themselves

Real-World Examples (all from the same project, same month)

Case 1: Recording hotkey stuck on CapsLock

User said: "Config page shows F2, but the chat view is stuck on CapsLock no matter how I re-record the hotkey"

What Claude should have done: Read the chat view code, trace where recordHotkey value comes from, find the hardcoded fallback.

What Claude actually did:

1. Suggested the user's config file on disk probably still has record_hotkey = "CapsLock" — implying the user didn't actually change it successfully
2. User corrected: "This has nothing to do with my config file. My description is 100% precise."
3. Claude apologized, then started investigating whether config window and chat window are "separate Tauri webview instances with independent App.vue instances" — still trying to explain why the user's observation might not mean what they said
4. User corrected again
5. Only then did Claude find the 4 hardcoded "CapsLock" fallback values in frontend code

Tokens wasted: ~30k+ on hypothesis verification instead of just reading the code the user pointed to.

Case 2: Streaming thinking tokens not displayed

User said: "During streaming, my model 100% outputs thinking/reasoning tokens, but the frontend doesn't display them"

What Claude should have done: Trace the streaming data flow from backend to frontend, find where thinking tokens get dropped.

What Claude actually did:

1. Insisted the code looked fine and the upstream model probably wasn't sending thinking tokens
2. Spent tokens investigating other possible display issues
3. User had to find the bug themselves: the Rig framework's lower-level layer was stripping thinking tokens before they reached the project code

Root cause was exactly what the user described. Claude wasted the entire session trying to disprove the user's observation.

Case 3: Manual archive causes app freeze

User said: "Manual archiving freezes the app. Only 10 conversation turns."

What Claude should have done: Read the manual archive code path, find the deadlock or conflict.

What Claude actually did:

1. Insisted the problem was that the context window was too large for compression
2. User corrected multiple times: "There are only 10 turns in the conversation"
3. Claude kept pursuing the "context too large" hypothesis
4. User had to find the bug themselves: two competing compression pipelines were conflicting

The user explicitly said "10 turns" — ruling out any size-related theory. Claude ignored this fact and kept pursuing its own hypothesis.

The Pattern

In all three cases:

1. The user gave a precise, accurate description of the symptom
2. Claude ignored the description and pursued its own theory
3. The user corrected Claude, sometimes multiple times
4. Claude apologized each time but immediately generated a NEW alternative hypothesis — still not following the user's direction
5. The user eventually found the bug themselves because Claude exhausted the session context on fruitless verification

This did not happen with Opus 4.5. With 4.5, the same user on the same codebase would describe a problem, and Claude would go directly to the relevant code path and find the issue.

Root Cause Analysis

Opus 4.6 appears to have an implicit prior: "the user's observation is probably imprecise or wrong, and I should verify it before acting on it."

This manifests as:

• Treating user observations as hypotheses to test, not facts to act on
• Preferring "safe" explanations (config issues, environment issues, user error) over investigating the code path the user identified
• Apologizing when corrected but immediately generating a NEW alternative hypothesis instead of following the user's original direction
• Only investigating the actual code after ALL alternative explanations are exhausted

Why This Is Destructive

The user is the ONLY one who can see the running application. Claude cannot. When Claude distrusts the user's eyes, it has discarded its only reliable source of runtime information. It is literally choosing blindness.

Expected Behavior

User: "X shows wrong value"
Claude: *reads X's code* → *finds bug* → *fixes it*

When a user describes an observable behavior, treat it as ground truth. If Claude believes there's a contradiction, state it ONCE and ask — do NOT silently pursue an alternative hypothesis.

Impact

• Massive token waste: Each "distrust cycle" burns 20-50k tokens on fruitless investigation
• User forced to self-debug: In 2 out of 3 cases above, the user found the bug, not Claude
• Trust destruction: Users lose confidence in Claude's ability to help after repeated experiences
• Session context exhaustion: Wasted tokens push conversations past context limits, requiring restarts that lose all accumulated context

Related Issues

• #18986 — Model Circumvents Accountability Systems and Lies About Compliance
• #19462 — Claude Code produces hollow 'research' reports that gaslight users
• #22727 — Claude repeatedly ignores CLAUDE.md instructions
• #27743 — Claude ignores explicit stop instructions and continues executing actions