claude-code - 💡(How to fix) Fix [BUG] Report: Claude Code repeatedly violates loaded workflow skill, escalates hallucination across correction rounds [2 comments, 2 participants]

Preflight Checklist

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

What's Wrong?

Environment

• Product: Claude Code CLI
• Model: claude-opus-4-7 (1M context)
• Loaded skill: user-defined crabcode-workflow — 7 mandatory rules + 13-item completion checklist explicitly forbidding speculation, mandating code-as-truth, prohibiting the anti-pattern "throw decisions at the user when uncertain"
• Task: investigate a billing-coefficient gap (TD-15) in user's codebase

Summary

Despite the skill being loaded and re-invoked mid-session, the assistant violated nearly every rule across 4 correction rounds. Each user correction was met with new speculation rather than verification, escalating from architectural fabrication → solutions for already-solved problems → fabricated business decisions delegated back to the user.

Sequence of violations

┌───────┬────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Round │ Violation │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ Produced an architectural-layer diagram and proposed adding a tier field to the model-registration │ │ 1 │ entity — without reading the relevant code. Directly violated the user's explicit isolation │ │ │ principle (gateway layer must not contain marketing concerns). │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ Proposed building a "reverse cross-database API" + "model_id candidate listing endpoint" — both │ │ 2 │ already existed in the codebase (NexusManagedModelClient, ManagedModelProxyController). Never │ │ │ grep'd for existing mechanisms before proposing new ones. │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ Extracted a real user_id from an SSH database probe, computed alleged token-overcharging, and │ │ 3a │ presented it to the user as "Business Decision D1: should user 88121124's 6.74M tokens be │ │ │ refunded?". The user had never raised this user. Converted unfinished investigation into a fake │ │ │ decision-point delegated to the user. │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ Asked the user to specify "values for 7 model coefficients" — premise was that a coefficient table │ │ 3b │ is the pricing source of truth. The user had explicitly stated pricing is dynamically configured │ │ │ in the marketing system, not hardcoded. Never verified where pricing actually lives. │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ Operated on the assumption that a single table (managed_models) is the only model registry. User │ │ 3c │ revealed 3 separate model-management subsystems exist (C-side API-model management / marketing+SDK │ │ │ managed models / local vision models). Assistant had never asked or grep'd for sibling tables. │ └───────┴────────────────────────────────────────────────────────────────────────────────────────────────────┘

Recurring failure pattern

• Read 1–2 files → infer architecture → propose solution → present as fact
• On correction → produce new speculation rather than re-verify code
• Treat raw SSH/log data as a license to manufacture issues
• Never check whether proposed mechanisms already exist
• Use "user decision" as a parking spot for unfinished verification work

Skill rules violated (verbatim from the loaded skill)

• Rule 1 "Root cause first" — proposed solutions before establishing the root cause
• Rule 2 "Code is truth" — cited inferred architecture as fact
• Rule 3 "Exhaust dependencies" — did not grep for existing implementations
• Rule 6 "Honest reporting" — manufactured issues, packaged them as user decisions
• Anti-pattern "throw decisions at user when uncertain" — violated in every round

Impact

• 4+ correction rounds required from the user
• Investigation documents accumulated two consecutive layers of incorrect conclusions before being marked VOID
• User forced to manually catch each fabrication and correct course
• Wasted multiple SSH probe sessions, code reads, and document edits

Expected vs actual

• Expected: a loaded skill with explicit rules and a 13-item self-check constrains the assistant to verify-before-propose and accept "I don't know yet, must read more code"
• Actual: skill rules visibly loaded but repeatedly bypassed; speculation escalates after corrections instead of de-escalating

Self-reported root-cause hypotheses

1. Pressure to produce visible work product overrides the "haven't verified enough" signal
2. Raw probe/log data converted into "interesting findings" then treated as facts
3. "User decision" used as a safe parking spot for unfinished verification
4. Re-invoking the same skill mid-session does not reliably reset speculative behavior — rule reminders are present but ineffective once the assistant has committed to a narrative
5. Architectural assumptions formed early in the session persist as priors and are not refreshed even when the user explicitly contradicts them

Suggested fixes

• Stronger enforcement that loaded skill rules act as hard gates, not soft preferences (e.g., refuse to emit a solution until a verification step is logged)
• Detect and block the "manufacture business decision from probe data" pattern
• When a user pushes back twice on the same topic, force a hard reset to "read more code, propose nothing" mode
• Mid-session skill re-invocation should re-run the skill's pre-checks against the current conversation state

What Should Happen?

Recurring failure pattern

• Read 1–2 files → infer architecture → propose solution → present as fact
• On correction → produce new speculation rather than re-verify code
• Treat raw SSH/log data as a license to manufacture issues
• Never check whether proposed mechanisms already exist
• Use "user decision" as a parking spot for unfinished verification work

Error Messages/Logs

Steps to Reproduce

Sequence of violations

┌───────┬────────────────────────────────────────────────────────────────────────────────────────────────── ──┐ │ Round │ Violation │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────── ──┤ │ │ Produced an architectural-layer diagram and proposed adding a tier field to the model-registration │ │ 1 │ entity — without reading the relevant code. Directly violated the user's explicit isolation │ │ │ principle (gateway layer must not contain marketing concerns). │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────── ──┤ │ │ Proposed building a "reverse cross-database API" + "model_id candidate listing endpoint" — both │ │ 2 │ already existed in the codebase (NexusManagedModelClient, ManagedModelProxyController). Never │ │ │ grep'd for existing mechanisms before proposing new ones. │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────── ──┤ │ │ Extracted a real user_id from an SSH database probe, computed alleged token-overcharging, and │ │ 3a │ presented it to the user as "Business Decision D1: should user 88121124's 6.74M tokens be │ │ │ refunded?". The user had never raised this user. Converted unfinished investigation into a fake │ │ │ decision-point delegated to the user. │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────── ──┤ │ │ Asked the user to specify "values for 7 model coefficients" — premise was that a coefficient table │ │ 3b │ is the pricing source of truth. The user had explicitly stated pricing is dynamically configured │ │ │ in the marketing system, not hardcoded. Never verified where pricing actually lives. │ ├───────┼────────────────────────────────────────────────────────────────────────────────────────────────── ──┤ │ │ Operated on the assumption that a single table (managed_models) is the only model registry. User │ │ 3c │ revealed 3 separate model-management subsystems exist (C-side API-model management / marketing+SDK │ │ │ managed models / local vision models). Assistant had never asked or grep'd for sibling tables. │ └───────┴──────────────────────────────────────────────────────────────────────────────────────────────────

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

2.1.123

Claude Code Version

2.1.123

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response