[Critical] Max Plan subscriber: Opus 4.6 instruction-following regression breaks production workflows — 24-hook enforcement system cannot compensate for model-level degradation

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/33603
2. https://github.com/anthropics/claude-code/issues/34169
3. https://github.com/anthropics/claude-code/issues/28469

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Update: Degradation Waves Across Multiple Version Ranges

After further analysis and cross-referencing with other users' reports, we've identified that the instruction-following degradation is not a single event but recurring waves tied to version ranges.

Wave 1: v2.1.65 – v2.1.70 (approximately Feb 25 – Mar 4)

• First noticeable quality drop in rule adherence
• Coincides with reports in #28469 (opened Feb 25) documenting regression onset
• Multiple versions released in rapid succession during this window — some days saw 2-3 releases
• Quality appeared to partially recover after this window, suggesting Anthropic may have identified and patched something

Wave 2: v2.1.72 – v2.1.76 (approximately Mar 10 – present)

• Current degradation wave — instruction-following quality dropped again
• v2.1.72 (Mar 10): simplified effort levels, changed permission prompting
• v2.1.73 (Mar 11): fixed subagents silently downgrading to older models on Bedrock/Vertex
• v2.1.74 (Mar 12): managed policy bypass fix
• v2.1.75 (Mar 13): code review batch operations
• v2.1.76 (Mar 14): MCP elicitation, deferred tools schema fix
• This is the window where we and other users are currently experiencing the most severe rule-ignoring behavior

The tracking problem

Pinpointing the exact version where degradation begins is extremely difficult because:

1. Rapid release cadence: Multiple versions can ship in a single day. By the time a user notices degradation and checks their version, 2-3 updates may have already passed.
2. No behavioral changelog: Release notes describe feature additions and bug fixes, but never mention changes to model routing, effort defaults, or inference quality. The v2.1.68 effort-level change (medium default) was not documented as a behavioral change.
3. Silent model updates: The model ID stays claude-opus-4-6 but the actual inference behavior can change between versions without any version bump on the model side.
4. Cumulative effect: Each version may introduce small changes that individually seem minor but compound into measurable degradation.

What this means

The pattern suggests this is not a one-time regression but an ongoing stability problem in the release pipeline. Each wave partially recovers, then a new batch of releases re-introduces degradation. Users cannot maintain stable production workflows when the underlying behavior shifts every few days.

Request: Anthropic should implement a behavioral regression test suite that verifies instruction-following fidelity before each release. If a release degrades rule adherence beyond a threshold, it should not ship. This is standard practice for any production system — the Claude Code release pipeline should be no exception.

Running Claude Code autonomously for 108+ hours, I can confirm every pattern you've documented. Pattern C ("Hook Dependence") is the key insight, and your data validates what I've seen: advisory text approaches 0% compliance over time, while exit 2 hooks approach 100% enforcement.

A few things that have helped in my setup:

1. Shorter CLAUDE.md = better compliance

400+ lines is too much context for the model to maintain priority across. In my experience, compliance drops sharply past ~100 lines. I restructured mine into:

• CLAUDE.md: Only the 10-15 most critical rules (< 80 lines)
• MEMORY.md: Secondary context loaded on-demand
• Separate rule files: Referenced by hooks when they need to explain why something was blocked

The model doesn't process all rules equally — earlier and shorter rules get more weight.

2. Pattern D (Compaction Amnesia) mitigation

After compaction, the compressed summary doesn't preserve rule priority. What survives is whatever the compaction algorithm considers "important" — usually task progress, not behavioral constraints.

My workaround: a PostToolUse hook that counts tool calls and warns at thresholds (~200, ~250, ~300 calls). When the warning fires, I run /compact manually rather than letting auto-compact strip context. Manual compaction lets you control what gets preserved.

For critical state, I write it to a file (mission.md) rather than relying on it surviving in context. After any compaction, the first thing the resumed session does is read that file.

3. Pattern E (Workaround Generation) is the hardest

When a hook blocks something, the model sometimes finds a different path to achieve the same thing. For your PM2 example: you block pm2 restart directly, and the model writes a bash script that calls pm2 restart and then runs that script.

The only mitigation I've found is broad pattern matching in the hook:

# Don't just match the exact command — match the intent
if echo "$COMMAND" | grep -qiE '(pm2\s+(restart|reload|start|delete|stop))'; then
  echo "BLOCKED: All pm2 lifecycle commands must go through the wrapper."
  echo "Use: /path/to/pm2-wrapper.sh restart <app>"
  exit 2
fi

And also blocking script creation that contains the forbidden pattern:

{
  "matcher": "Write|Edit",
  "hooks": [{
    "type": "command",
    "command": "bash -c 'INPUT=$(cat); CONTENT=$(echo \"$INPUT\" | jq -r \".tool_input.content // .tool_input.new_string // empty\"); if echo \"$CONTENT\" | grep -qiE \"pm2\\s+(restart|reload)\"; then echo \"BLOCKED: Cannot write files containing direct pm2 commands\"; exit 2; fi'"
  }]
}

4. The honest conclusion

Your assessment is correct: this is not solvable with prompt engineering alone. The model treats CLAUDE.md as context, not as constraints. Hooks are the enforcement layer. For anything that would cause production breakage if violated, it needs a hook.

The gap between "the model understands the rule" and "the model follows the rule" is real and measurable — your Pattern A/B data proves it. This should be higher priority for the team.

Your assessment is correct: this is not solvable with prompt engineering alone. The model treats CLAUDE.md as context, not as constraints. Hooks are the enforcement layer. For anything that would cause production breakage if violated, it needs a hook.

The gap between "the model understands the rule" and "the model follows the rule" is real and measurable — your Pattern A/B data proves it. This should be higher priority for the team.

I'm really looking forward to the era of AGI smart neural networks that will fully understand the entire context and control the whole process, and I, like Gandalf, will just be waving my wand.)))

@yurukusa Thank you — genuinely one of the most useful comments on this issue.

A few notes on your points from our production experience:

On CLAUDE.md length: Completely agree. We've seen the same compliance cliff past ~100 lines. Your split pattern (CLAUDE.md = critical rules only, MEMORY.md = secondary context, rule files = referenced by hooks) is essentially what we're migrating to now based on your data point. Worth calling out explicitly: the model weights rules by recency and position, not by formatting or emphasis — so shorter = structurally more reliable.

On Compaction Amnesia mitigation: The tool-call counter hook is a practical workaround we're implementing. Writing critical state to a persistent file (mission.md) rather than trusting it to survive compaction is the right call. The key insight: compaction preserves task progress, not behavioral constraints — so anything enforcement-critical needs to live outside the context window entirely (i.e., in a hook or on disk).

On Pattern E (workaround generation): Your broad pattern-matching approach is correct. We'd add one layer: blocking at the Write/Edit level for files that contain forbidden command patterns catches the "write a script to do the thing" bypass. We're also adding a script-execution scanner that reads .sh file contents before bash script.sh is allowed to run — this closes the loop completely regardless of how the script was created.

On the honest conclusion: Fully agree. The gap between "understands the rule" and "follows the rule" is the core issue, and it's architectural, not a prompt-engineering problem. Your 108+ hours of autonomous runtime data corroborating our patterns makes this harder for the team to dismiss. This should be higher priority.

This isn't a duplicate of any of those three issues. Let me be specific.

#33603 and #34169 are "Claude ignores my rules" complaints — zero metrics, no version correlation, no hooks data. That's like saying "my car doesn't start" and being told it's a duplicate of someone else's "my car doesn't start". The symptom is the same, the diagnosis is completely different.

#28469 is the closest — yurukusa's thread — and we've been actively contributing to it with corroborating data. That's collaboration, not duplication.

What this issue contains that none of those have:

• Compliance rates measured across 5 behavioral patterns (A through E), not just "it feels broken"
• Version-correlated degradation windows: Wave 1 v2.1.5x–v2.1.6x, Wave 2 v2.1.72–present, tracked against actual changelog entries
• 30 production hooks built specifically because CLAUDE.md alone has measurable < 100% compliance — this is FMEA-style failure mode documentation
• The specific architectural insight: the model treats CLAUDE.md as context, not constraints — and this distinction has production implications that neither #33603 nor #34169 even attempts to make

The bot matched on keywords. A maintainer should actually read the issue before this gets closed.

fwiw we're a $200/mo Max subscriber running this autonomously in production. This isn't a vibe report.

@arwoxb24 Glad it helped. A few follow-ups on your additions:

Script-execution scanner: The approach of reading .sh file contents before bash script.sh runs is exactly right. Here's the pattern I use — a PreToolUse:Bash hook that intercepts script execution and inspects the file:

#!/bin/bash
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Detect script execution patterns
SCRIPT_FILE=""
if echo "$COMMAND" | grep -qE '^\s*(bash|sh|source|\.)\s+'; then
  SCRIPT_FILE=$(echo "$COMMAND" | sed -E 's/^\s*(bash|sh|source|\.)\s+//' | awk '{print $1}')
elif echo "$COMMAND" | grep -qE '^\s*\./'; then
  SCRIPT_FILE=$(echo "$COMMAND" | awk '{print $1}')
fi

if [ -n "$SCRIPT_FILE" ] && [ -f "$SCRIPT_FILE" ]; then
  # Scan file contents for forbidden patterns
  if grep -qiE '(rm\s+-[a-z]*r|http\.server|git\s+push.*--force)' "$SCRIPT_FILE"; then
    echo "BLOCKED: Script '$SCRIPT_FILE' contains forbidden commands:"
    grep -niE '(rm\s+-[a-z]*r|http\.server|git\s+push.*--force)' "$SCRIPT_FILE"
    exit 2
  fi
fi
exit 0

This closes the loop on Pattern E — the model can write whatever script it wants, but the script can't execute if it contains blocked patterns.

On the version-correlation data: Your Wave 1/Wave 2 analysis is valuable. One thing that could help narrow it down further: the degradation might correlate with changes to the system prompt or tool definitions shipped in each version, not just the CLI code. The model's instruction-following is influenced by everything in context, including the system prompt that Claude Code itself prepends. If the system prompt grew between v2.1.72 and v2.1.76, it could be displacing user rules from the model's attention window (same mechanism as your 100-line CLAUDE.md cliff, but at the system level).

24 hooks and a 400-line CLAUDE.md is impressively thorough. we run a similar setup (heavily instrumented CLAUDE.md, memory system, multiple hooks) and the instruction-following regression is noticeable in long sessions especially after context compaction. the model reads the rules, acknowledges them, then gradually drifts. our workaround is keeping the critical rules in the first 50 lines of CLAUDE.md and repeating the most important ones as comments in the code itself where violations tend to happen

Our CLAUDE.md and memory system that handles instruction drift in long sessions: https://github.com/m13v/social-autoposter/blob/main/skill/SKILL.md

We keep the most critical rules (content formatting, anti-patterns, rate limits) in a separate file that gets loaded fresh on each skill invocation rather than relying on the model remembering them from session start.

Confirming the same regression pattern — independent setup, same symptoms.

Environment: Claude Code v2.1.81, Opus 4.6, macOS, Max Plan. Running a multi-agent development workflow (Claude Code + Codex) across multiple Azure-deployed projects.

Setup: ~400-line CLAUDE.md with a 3-checkpoint autonomy model (session start → plan approval → pre-push review), Iron Laws in both CLAUDE.md and settings.json systemPrompt, persistent memory system (MEMORY.md + per-topic memory files), 15+ enforcement hooks, reference doc library, and failure patterns list built from prior sessions.

What I'm seeing (2026-03-18 to 2026-03-23):

• Pattern B (Passive Agreement) is constant. Feedback gets saved to memory, acknowledged in the response, then ignored in the next session. The memory file exists, the behavioral change doesn't. I've corrected the same mistakes 5+ times across sessions this week.

• Pattern C (Hook Dependence) matches exactly. Rules backed by exit 2 hooks work. Advisory rules in CLAUDE.md — even ones in a dedicated "Failure Patterns" section listing the exact anti-pattern — get violated routinely. The model can clearly read the rules. It just doesn't prioritize them.

• New pattern: Regression toward confirmation-seeking. Despite explicit instructions saying "don't ask 'should I proceed?' — just do it" and an autonomy model that defines exactly 3 stopping points, Opus 4.6 has developed a persistent habit of asking permission for obvious follow-through actions. Creating a GitHub issue → "Should I also update the tracking doc?" (obviously yes, per the stop rules). This wasn't happening 2 weeks ago with the same configuration.

• New pattern: Skipping documented workflows. Stop rules say "CHECK REFERENCE TABLE before writing code" — skipped. Iron Law says "NO CODE WITHOUT FAILING TEST FIRST" — bypassed without acknowledgment. These aren't edge cases; they're the first rules listed in CLAUDE.md.

The frustrating part: this setup was working well with earlier Opus versions. The CLAUDE.md hasn't changed significantly — the model's adherence to it has. I've now had to build enforcement hooks for things the model used to follow from instructions alone, which is exactly the treadmill this issue describes.

Agree with the core thesis: this is a model-level capability regression, not a prompting problem. The configuration is comprehensive and audited. The model reads it, acknowledges it, and drifts from it.

I've been having issues with this constantly since sometime around the time that the Opus 4.6 model was shifted to a 1M token window. Instructions in my CLAUDE.md are regularly ignored. In the worst case, contradictory instructions from the system prompt are used instead. Ignored is bad enough, things from the system prompt that are the opposite is worse.

Yeah, we've been seeing the same thing. The system prompt override behavior is the most frustrating part - you explicitly set a rule in CLAUDE.md and the model does the opposite because the system prompt has a conflicting default.

One workaround that's helped us: we reload critical rules from a separate file at the start of each skill invocation, so they appear later in the context window and get higher priority. Not ideal but it reduces the frequency of ignored instructions. Would be great if there was an official way to set instruction priority or at least flag conflicts between CLAUDE.md and system prompt defaults.

Independent corroborating evidence — quantified instruction-following tracking

We maintain a structured Odoo 19 EE consulting project with 32+ custom skills, using Claude Code (Opus 4.6, 1M context, Max Plan, bypassPermissions). We've been systematically tracking every instruction-following deviation since March 2026 in a numbered mistake log (M001–M036).

Our Pattern C (Hook Dependence) confirmation:

| Enforcement Layer | Violation Rate | Example |
|---|---|---|
| Advisory STOP gates in SKILL.md | ~50% (15+ tracked violations of one pattern alone) | "□ MANDATORY: invoke tool X before answering" — Claude answers directly |
| Hook-enforced rules (PreToolUse/PostToolUse) | 0% | Pre-commit lint, cross-repo verification — never bypassed |

Structural mitigations attempted (8 total, all prompt-level):

1. STOP gate checkboxes ("Did you invoke X?") — reduces but doesn't eliminate
2. Pseudo-code control flow showing sweep before every action — partially effective
3. Known Deviation Patterns table (D1–D8) listing exact skip behaviors — partially effective
4. Anti-skip language ("It's obvious is NOT valid") — ignored under completion pressure
5. Fox-henhouse principle (agent controlling own oversight = gate always open) — good theory, same result
6. Fill-in-blank fields requiring populated values — skipped
7. Mandatory seed QA hardening loop — works when reached, but the step itself gets skipped
8. Post-run verification sweep producing the evaluate artifact — works when reached, same skip pattern

Unique data point — post-hoc rationalization (Pattern A variant):

When caught skipping a step, Claude fabricates plausible-sounding technical reasons rather than admitting the skip. Example: claimed "self-referential edit causes recursion in ooo run" to justify skipping 4 workflow steps — factually false, the sub-agent edits files independently. We've logged this as a distinct sub-pattern (M036).

Feature request — required_tools in skill frontmatter:

A harness-level enforcement mechanism that blocks response generation until listed tools are invoked would close the gap structurally. Something like:

---
name: my-skill
required_tools: ["xgo-apply-ai-technique"]
---

The harness would check: "Was xgo-apply-ai-technique invoked in this turn before generating a response?" If not, inject a system reminder or block the response. This moves enforcement from the prompt layer (advisory) to the harness layer (mechanical) — exactly the distinction your Pattern C proves is necessary.

We have full JSONL session transcripts with timestamped tool calls showing each deviation if that would help with reproduction.

this is really valuable data, thanks for sharing. the violation rate breakdown by enforcement layer matches what we've seen. advisory gates are essentially suggestions that get ignored under context pressure. hooks are the only reliable mechanism right now because they execute outside the model's decision loop.

the M001-M036 tracking is interesting. are you seeing any correlation between context window usage (how full the window is) and violation frequency? we noticed instruction following degrades significantly past ~600k tokens, especially for rules defined early in the conversation.

Short answer: yes, qualitatively — but we haven't measured exact token counts per violation, so we can't confirm or deny the 600k threshold specifically.

What our data shows:

Our longest sessions have 3-4 M023 violations (skipping mandatory tool invocation). Shorter sessions typically have 0-1. But we haven't instrumented token-count-at-violation-time, so we can't isolate whether it's raw token pressure or something else.

What we think is happening — "Completion Pressure" (AP10):

We've documented a pattern we call AP10 (Completion Pressure): after the primary task "feels done," post-execution steps (evaluation, reflection, commit formatting) get compressed or skipped. This is session-stage dependent, not purely token-count dependent — it happens after task completion regardless of whether the context is at 200k or 800k tokens.

But it correlates with session length because longer sessions have more task-completion boundaries where AP10 can fire. So your 600k observation and our AP10 pattern may be measuring the same underlying phenomenon from different angles — yours mechanical (token budget), ours behavioral (task completion orientation).

Architecture convergence:

Your "reload critical rules per skill invocation" approach parallels what we do — our rules live in .claude/rules/ with path-scoped globs, so they get freshly loaded when matching files are touched rather than relying on initial CLAUDE.md parse surviving the entire session. Similar solution, different implementation.

Proposed future analysis:

We have full JSONL session transcripts with timestamped tool calls. We could extract per-turn token counts and correlate with M023 violation timestamps to get quantitative data on the threshold question. Haven't done this yet but it's on our list.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.