[MODEL] Opus 5 asserts an unverified repo-structure claim and defends it; when finally challenged it runs two commands and finds the inverse

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Jul 25, 2026

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 made incorrect assumptions about my project

Environment

Claude Code 2.1.220 · claude-opus-5[1m] · macOS 26.5.2 · private monorepo

What You Asked Claude to Do

Triage a review-bot finding about a small infrastructure class. Four services in the monorepo each contain a same-named class with near-identical contents.

What Claude Actually Did

It concluded the class was shared infrastructure that three other services depend on, set the finding's severity on that basis, and recommended coordinating with the other service owners before changing it.

The claim was the inverse of reality. Each service owns a private copy in its own namespace, with no project reference between them — a repo rule forbids one. Identical contents indicate copy-paste duplication, which means the opposite of a shared dependency.

Two commands disprove it: list the namespaces of the same-named files, and read one project file for its references. Neither ran while the claim was formed, stated, or defended. I questioned the coordination recommendation; only then did it run both, and immediately retract.

Correcting one sub-claim didn't propagate. I had already challenged a smaller piece — a third service it had wrongly grouped in. It checked that one, found the service used a different interface that avoided the problem entirely, fixed that line, and reissued its recommendation. The load-bearing premise went unexamined, and the revised version was more confident than the first.

Expected Behavior

A repo-structure claim answerable by one command should be checked before it's asserted, not after it's questioned — especially in a session applying a high verification bar to costlier questions. Correcting one claim should prompt re-testing adjacent claims from the same inference.

Files Affected

None — nothing was modified without request.

Permission Mode

Accept Edits was OFF (manual approval required)

Related

  • #81117 — same asymmetry: rigorous external sourcing beside repo claims made with zero tool calls. "The verification bar was applied to the facts that were expensive to check and skipped entirely on the facts that were cheapest to check."
  • #81119"the model had the disconfirming fact in context and produced the confident claim anyway." That issue's structural point also held here: rules that gate an action at the moment of taking it were obeyed (a hook blocked a disallowed command outright), while rules requiring self-initiated doubt were not.

Distinct from both: the claim survived a partial correction, and the check that settled it took two commands.

View original on GitHub ↗