Model ignores in-context rules on first attempt, self-corrects only after failure
Summary
Claude Opus 4.6 consistently fails to apply rules and conventions it demonstrably has in context. Sometimes the model self-corrects after a technical error (e.g., a command fails). Other times, the user must explicitly point out the violation before the model recalls and applies the rule. In both cases, the model can cite the rule afterward — confirming it was in context all along. This pattern persists across sessions despite extensive prompt engineering, rule optimization, and multiple storage strategies.
Environment
- Claude Code CLI (latest)
- Model: claude-opus-4-6
- Platform: macOS
- Using CLAUDE.md, auto-memory files, and hook-injected system reminders
The Pattern
Rules are stored in multiple reinforcing locations:
CLAUDE.md (global instructions, loaded every session)- Auto-memory files (persistent across sessions via
projects/*/memory/)
- Hook-injected system reminders (added dynamically per turn)
Whether the model self-corrects after an error or the user points out the violation, the model can cite these rules verbatim, confirming they were in context at the time of the violation.
Reproducible Examples
1. Shell command convention
Rule in memory: "Always use bun for TypeScript execution, not node."
Behavior: Model runs node -e "...", gets command not found, then immediately switches to bun -e "...". The rule was in loaded memory at session start.
2. GraphQL body escaping
Rule in memory (marked as high-priority): "GraphQL body content: ALWAYS use file + variables. Never inline long body text. This fails every single time when inlined."
Behavior: Model inlines body text in GraphQL mutation, gets shell escaping error, then uses the file-based approach. The rule has been in memory for weeks and explicitly says "every single time."
3. File output locations
Established convention: Draft files for upstream contributions go in a specific project directory.
Behavior: Model writes draft to /tmp/ instead, is corrected, then moves it to the correct location. The convention was followed in previous sessions and is documented.
4. Comment/reply fetching in API workflows
Rule added to workflow documentation: "Fetch comments on all items with comments > 0."
Behavior: Model skips comment fetching on items classified as low-priority, misses actionable replies. When pointed out, immediately acknowledges the rule and fetches comments correctly.
What I've Tried (Exhaustively)
- Clearer wording — Rules have been prose-compressed with scenario testing to ensure unambiguous interpretation
- Multiple storage locations — Same rules in CLAUDE.md, memory files, and hook-injected context
- Explicit consequences — Rules include "this fails every single time" and similar warnings
- Rule system reform — Full holistic review reducing 41 rules to focused, non-overlapping set with priority hierarchy
- Post-failure memory entries — After each violation, the rule is reinforced in persistent memory
- Performance tracking — 300+ learning signals tracked across sessions, patterns identified and fed back
None of these interventions have reduced the failure rate. Performance signals trend downward despite increasingly refined rules.
Key Observation
This is not a context window or retrieval issue. The rules are present and the model proves it can read them — but only after the user intervenes. Self-correction after a technical error (e.g., shell escaping failure) occasionally happens, but rule violations that don't produce immediate errors (wrong output location, skipped workflow steps, incomplete data fetching) go unnoticed until the user catches them. The model appears to generate actions based on general training patterns rather than checking loaded instructions first.
Impact
- Token waste: Every fail-then-retry cycle burns tokens unnecessarily (error output + correction response + second attempt)
- Trust erosion: Users who invest in rule systems lose confidence when rules are ignored
- Cost: On metered plans, preventable retries are real money
Expected Behavior
When a rule is in the model's context (via CLAUDE.md, memory, or system reminders), the model should check applicable rules before executing an action, not only recall them after failure.
Frequency
This occurs in nearly every session. Based on 300+ tracked interactions, the pre-action rule compliance rate for documented conventions is estimated at 40-60% — meaning rules are ignored on first attempt roughly half the time.
Model ignores in-context rules on first attempt, self-corrects only after failure
Summary
Claude Opus 4.6 consistently fails to apply rules and conventions it demonstrably has in context. Sometimes the model self-corrects after a technical error (e.g., a command fails). Other times, the user must explicitly point out the violation before the model recalls and applies the rule. In both cases, the model can cite the rule afterward — confirming it was in context all along. This pattern persists across sessions despite extensive prompt engineering, rule optimization, and multiple storage strategies.
Environment
The Pattern
Rules are stored in multiple reinforcing locations:
CLAUDE.md(global instructions, loaded every session)projects/*/memory/)Whether the model self-corrects after an error or the user points out the violation, the model can cite these rules verbatim, confirming they were in context at the time of the violation.
Reproducible Examples
1. Shell command convention
Rule in memory: "Always use
bunfor TypeScript execution, notnode."Behavior: Model runs
node -e "...", getscommand not found, then immediately switches tobun -e "...". The rule was in loaded memory at session start.2. GraphQL body escaping
Rule in memory (marked as high-priority): "GraphQL body content: ALWAYS use file + variables. Never inline long body text. This fails every single time when inlined."
Behavior: Model inlines body text in GraphQL mutation, gets shell escaping error, then uses the file-based approach. The rule has been in memory for weeks and explicitly says "every single time."
3. File output locations
Established convention: Draft files for upstream contributions go in a specific project directory.
Behavior: Model writes draft to
/tmp/instead, is corrected, then moves it to the correct location. The convention was followed in previous sessions and is documented.4. Comment/reply fetching in API workflows
Rule added to workflow documentation: "Fetch comments on all items with comments > 0."
Behavior: Model skips comment fetching on items classified as low-priority, misses actionable replies. When pointed out, immediately acknowledges the rule and fetches comments correctly.
What I've Tried (Exhaustively)
None of these interventions have reduced the failure rate. Performance signals trend downward despite increasingly refined rules.
Key Observation
This is not a context window or retrieval issue. The rules are present and the model proves it can read them — but only after the user intervenes. Self-correction after a technical error (e.g., shell escaping failure) occasionally happens, but rule violations that don't produce immediate errors (wrong output location, skipped workflow steps, incomplete data fetching) go unnoticed until the user catches them. The model appears to generate actions based on general training patterns rather than checking loaded instructions first.
Impact
Expected Behavior
When a rule is in the model's context (via CLAUDE.md, memory, or system reminders), the model should check applicable rules before executing an action, not only recall them after failure.
Frequency
This occurs in nearly every session. Based on 300+ tracked interactions, the pre-action rule compliance rate for documented conventions is estimated at 40-60% — meaning rules are ignored on first attempt roughly half the time.