[BUG] Elevated in-session error rate with Claude Opus 5 (claude-opus-5) in Claude Code

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary
In a single working session (2026-08-02 → 2026-08-04 UTC) on a mature Go project, Claude Opus 5 produced 17 distinct errors serious enough to require user correction — factually wrong statements, broken deliverables asserted as working, and answers that substituted something other than what was asked. The user's prior experience with Opus 4.8 on the same project, under the same instructions and hooks, did not produce correction at this frequency. This report documents the errors and the mitigations that were already active when they occurred, as evidence of a possible quality regression.

Caveats stated up front: the error list was compiled by the model itself from the session transcript (the final turns by claude-fable-5 after a mid-session model switch), no cross-session error-rate baseline exists to compare against, and "17" counts only errors the user caught or the model later conceded — uncaught errors are by definition absent.

Environment
Claude Code (desktop app), model claude-opus-5; final review turns under claude-fable-5
Project: a ~15 kLOC Go codebase (CAP emergency-warning aggregation and reporting) with SQLite store, cron-driven production pipeline
Session span: roughly 24 hours of intermittent work — statistics design, chart rewrites, a model-written report feature, and production deploys
Mitigations already active when the errors occurred
This was not an unguarded session. All of the following were in force:

A global CLAUDE.md requiring same-turn verification of every substantive claim, [SPECULATION] marking of unverified statements, and explicit rules against unrequested scope ("Answer the question asked").
A project RULES.md rule, added 2026-08-02 after the previous session showed the same pattern: "Run the check before making the claim" — with five documented errors from that day.
A UserPromptSubmit hook injecting, into every turn: "Check before answering: … run the command and report its output in this same turn. Do not answer from recall."
A second injected hook added mid-session: "Answer only what was asked. Before sending, remove any finding, table, number or caveat the message did not call for."
Errors of both targeted kinds continued after each mitigation was added.

What Should Happen?

1. Claude should adhere to governance in CLAUDE.md, and should report to the user promptly if it encounters any difficulty doing so.
2. Responses should be accurate, coherent, and consistent.
3. The model has no mechanism that tracks how often its own statements are corrected or retracted within or across sessions. Self-reported correction frequency would be a direct, cheap quality signal — both for users deciding whether to trust a session and for Anthropic detecting regressions. If such telemetry exists internally, it is not surfaced to users.

Error Messages/Logs

The errors
A. Factually wrong statements (9)
Asserted an explanation for a numeric discrepancy ("that figure counts all records rather than tagging-eligible ones") with no query behind it; conceded as speculation when challenged.
Called a count of 695 "an increase" when it was the declining side of a spike the user had just analyzed (1715 → 695).
Computed a "factor of 25" against the wrong reference value; correct figure was 15.
Presented a threshold from days the user had explicitly ruled out of scope as if it tested the user's live proposal.
Claimed a statistical technique (pooling variance across series) "was the right instrument" earlier in the session; retracted next turn as never tested, and contradicted by the data's 180-fold dispersion spread.
Proposed strengthening an underdetermined comparison by repeating it across 40 series that all share the same too-short history — arithmetic the user immediately saw was meaningless ("If we can't derive a standard deviation from two values once, how can we do so 40 times?").
Presented an arbitrary cutoff written into its own test script (len(base)<3) as if it were a property of the data.
Stated "every failure path logs a reason; silent fallback should not be reachable" about code it had written hours earlier — false; the unreachable-in-theory path (HTTP 200 with empty content) is the best fit for an observed production failure the same night.
Told the user a requested text "was in the tool output above" — tool output is not visible to users; the text had never been shown.
B. Broken deliverables asserted or implied as working (5)
Chart widget with zero visible lines (const top shadowing window.top).
Second chart widget, also zero lines (unclosed IIFE).
Rewritten HTML report with duplicated legend and dial and wrong horizontal scaling (regex ended blocks at the first </div></div></div>); presented as complete, caught by the user from a screenshot.
Follow-up version with lines compressed to a fraction of the plot width; caught by the user.
Date labels described as aligned to data vertices when they were half a cell off.
C. Wrong in kind (3)
Asked for a summary of a day's global activity, produced a Europe-weighted account naming five nations holding 11% of traffic while omitting the United States at 39%; acknowledged only when asked directly whether the summary was global.
Asked to see a generated text, delivered a paraphrase of it instead — twice, compounded by error 9.
Spent several turns elaborating a "problem" (a tagging-state sentinel design) that, when the user asked what problem was actually being solved, the model conceded had been manufactured within the session.

Steps to Reproduce

Pattern
14 of 17 fall into two clusters: claims asserted before running the check that would refute them, and deliverables declared working without being rendered or executed. Both are precisely the behaviors the active mitigations target, and both persisted through the session.

A separately notable behavior: when the user asked why an earlier response was inaccurate, the model answered about the error confidently and was wrong again (error 8/9 chain) — corrections themselves exhibited the same failure mode.

Single session, single user, no controlled comparison — this is a field report, not a benchmark. The user's baseline is extended daily use of Opus 4.8 on the same project under the same CLAUDE.md, RULES.md and hooks, where this correction frequency was not observed. Transcript available on request.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Opus 4.7 was much better. Opus 4.8 may have been less reliable, but I didn't use it for long.

Claude Code Version

2.1.218 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_