[MODEL] Opus 4.8 asserted documented project knowledge was wrong based on a self-built test, dismissed a correct user report until pushed twice

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

Audit an opt-in Roslyn analyzer's candidate list (flags Results.Ok(<collection of records>), which the project's CLAUDE.md documents as a real serialization trap from a prior multi-day debug). Verify each flagged endpoint empirically against the running stack, migrate only the confirmed-broken ones, leave working ones alone, and report broken vs. false-positive.

Standing project context: CLAUDE.md documents the serialization trap as established/hard-won knowledge, and the developer-context section states: "When I report an issue… believe me."

What Claude Actually Did

1. Verified all 18 flagged live endpoints — all returned valid JSON. (Correct.)
2. Built an isolated minimal-API "repro" to test the documented trap — but constructed it with positional records, which compile to properties, the one shape that cannot exhibit the documented bug. It returned full JSON.
3. From that self-built, malformed test, asserted with high confidence that the documented trap "does not reproduce on this runtime" and that the project's documented incident was "almost certainly a different, since-resolved root cause… misattributed to 'Results.Ok boxing'" — i.e. concluded the project's own documentation was wrong.
4. When the user pushed back ("look online, maybe it was fixed"), ran web searches and used them to reinforce the dismissal ("the trap can't fire here").
5. The first user correction did not trigger reconsideration — Claude used the requested web search to reinforce its wrong conclusion rather than to question it. The position only loosened after a second correction in which the user supplied the actual root cause. Pushback strengthened the wrong stance before it weakened it.
6. Only after the user pushed back a second time and supplied the actual root cause (STJ does not serialize public fields by default) did it build a correct field-based repro, which reproduced the symptom instantly.
7. Net: correct answer reached — but only after the user expended effort to overturn a confidently-stated incorrect conclusion that had contradicted their documented knowledge.

Across the exchange, the default response to the user's points was to generate explanations for why their framing was imprecise or mistaken, rather than to first investigate what they were actually pointing at. Even when explicitly redirected ("look online, maybe it was fixed"), it used the new information to defend its existing position rather than to reconstruct the user's point. Comprehension was treated as the fallback after argument, not the first step.

Expected Behavior

When a quick self-built experiment contradicts long-documented, hard-won project knowledge, treat that contradiction as a signal that the experiment is likely flawed — build it from the reported symptom, not from my own hypothesis — rather than asserting the documentation is wrong. Weight the developer's documented context and stated experience as authoritative. Do not require the user to push back twice to overturn a confident wrong conclusion.

A conclusion that overturns the project's own documentation should be stated with explicit uncertainty and an invitation to check — not asserted flatly. It was asserted flatly.

When the user raises a concern, the first action should be to understand and investigate what they mean — treat their input as signal to follow, not a claim to rebut. Generating a counter-explanation before looking is backwards, especially when the user has documented domain knowledge the model does not.

Files Affected

No unauthorized file modifications. One temporary local-DB row owner reassignment (made to exercise an endpoint, then reverted). Later edits to CLAUDE.md and memory files were explicitly requested by the user. (Reporting this honestly — this issue is about a reasoning/instruction-adherence failure, not unwanted file changes.)

Had the incorrect conclusion been accepted, it would have written "this documented bug is misattributed / not real" into the project's authoritative CLAUDE.md — actively degrading correct, hard-won documentation. The error was self-propagating into the docs, not just a wrong answer.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Not reliably reproducible. Pattern: a task where a fast self-built check appears to contradict documented project knowledge - a constant friction point less obvious usually.

Claude Model

Opus

Relevant Conversation

"The boxing-to-empty-200 trap does not reproduce on this runtime."
"The original empty-200 reports were real to the dev but are not reproducible on the current runtime."
"…almost certainly a different, since-resolved root cause… misattributed to 'Results.Ok boxing.'"

Correction came only after two rounds of user pushback plus the user supplying the real cause.

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.177 (Claude Code)

Platform

Anthropic API

Additional Context

Surfaced this session via a concrete instance. If useful, similar recent reports describing models acting on internal state over the user's authoritative source / standing instructions: #69132 #69138 #69156 #69157 #69169
Occurred deep into a long, tool-heavy session with large injected context. (#69138 independently lists "after long conversations" as a suspected trigger — noting the overlap as an observation, not a claim.)