Opus 4.6 comprehensive regression: loops, memory loss, ignored instructions - daily professional user report

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/26533
2. https://github.com/anthropics/claude-code/issues/24585
3. https://github.com/anthropics/claude-code/issues/28158

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

The MEMORY.md/CLAUDE.md loss after compaction is a real safety gap, not just an inconvenience — you've articulated exactly why in your 'NEVER push to main' example. Until this is fixed natively, I've been using Mantra (mantra.gonewx.com) as a session forensics layer: it keeps a full timeline anchored to git states, so after compaction fires you can replay exactly what the model had in context vs. what it lost. Helps verify whether critical rules survived the compaction boundary before continuing production work.

The context compaction safety problem you describe is exactly why I built GrantAi Brain.

The core issue: MEMORY.md and CLAUDE.md are pull-based — Claude has to choose to read them. After compaction, it often doesn't.

GrantAi Brain is push-based. Context is injected automatically at session start via MCP hooks — before Claude takes any action. No prompting required.

• Years of context. Instant recall. From 2 minutes ago to 5 years ago.
• If it's stored, it can be recalled — deterministic memory, not fuzzy recall
• 12ms retrieval, 100% local, AES-256 encrypted
• Works with Claude Code, Cursor, any MCP client

solonai.com/grantai

I've been dealing with the same issue. I'm the author of #26533 and have received zero attention from Anthropic despite multiple follow-up comments with evidence over 3 weeks.

As of today (March 7, 2026), I discovered something that may help you. I just tried it and it's working better. Give it a shot: disable Thinking mode by running /config → set Thinking mode to false. After doing this, Claude started actually reading and recognizing what it understands and what it doesn't — then reporting back to me instead of silently improvising.

---

To the Anthropic team: This is not a spam comment. This is users helping each other because you won't. We pay for Claude to serve us — at the very least, it should do what we ask. Whether the results are right or wrong, we can deal with that later. What we cannot deal with is a tool that actively sabotages our work and is too lazy to follow basic instructions. We are not paying to be your beta testers filing bug reports. We are not paying for an AI tool that only knows how to cut corners and break things. I'm a Claude Max subscriber at $200/month.

Adding a data point from the "maximum effort" end of the spectrum, since this report deserves corroboration from users who exhausted every mitigation option.

Our setup: 24+ PreToolUse/PostToolUse hooks that block forbidden commands at shell level, a 400+ line CLAUDE.md with a numbered V-code enforcement system (role-based rules, mandatory methodology sequences, violation codes), MEMORY.md for cross-session persistence, and a full agent delegation architecture. Max Plan subscriber, 6+ months in production.

The pattern you describe maps exactly to what we observe. The agent reads CLAUDE.md via Read tool, its output confirms understanding, and 2 turns later it violates the same rule — not because it did not read it, but because task pressure deprioritizes instruction context.

The critical finding from our experience: hooks are the only reliable protection layer, but they solve the wrong problem. A hook with exit 2 prevents the blocked action from executing — but the model still generated the wrong intent. The hook is intercepting a symptom. The root issue is that the model does not durably internalize rules the way a human engineer internalizes a team convention.

Six months of iteration has not closed this gap. The regression you document is consistent with our own trending. This is a platform-level behavioral reliability issue, not a prompting problem that users can engineer their way out of.

For a comprehensive technical analysis covering all documented failure patterns and concrete feature requests, see #34358 — filed with detailed root cause analysis, 5 documented violation patterns, and 7 specific asks to Anthropic.

Additional reproduction: Memory rules systematically overridden during code generation (4 days, Max subscriber)

Environment: Opus 4.6 (1M), macOS, Max plan ($200/mo)

Adding to this report with a concrete, reproducible case of memory/instruction override and scope creep.

Setup

Three feedback memory files stored in ~/.claude/projects/.../memory/ and loaded via MEMORY.md into system prompt every session:

• "Read requests carefully, no guessing"
• "No speculation, search if unsure, analyze root cause first"
• "Only perform requested changes, no scope expansion, report inability before coding"

Reproduction case

Request: "Move the zZZ text position 3pt to the left. Accept that the last Z gets clipped."

This is a single-line change: maxX - 2 → maxX - 5.

What Claude did instead — 6 unauthorized sequential changes:

1. Expanded canvas 30pt → 36pt (not requested → introduced empty space)
2. Switched to dynamic canvas sizing (not requested → caused icon shifting)
3. Reverted to fixed canvas (re-introduced approach user already rejected)
4. Reduced canvas to 24pt (made clipping worse than original)
5. Restored 30pt but didn't match running frame size (caused shifting again)
6. Changed image.size of unrelated frames (stretched the image)

Each step was corrected by the user with explicit feedback. Claude acknowledged, apologized, then deviated again immediately.

Pattern across 4 days

This is not isolated. Over 4 days of daily use:

• Memory rules are visibly loaded (shown in tool output) but have zero observable effect on code generation
• /clear + fresh session does not fix it — same behavior from first response
• Previously rejected approaches are re-introduced without acknowledgment
• When confronted, Claude deflects to next task, minimizes scope ("in this case"), or suggests the user should provide more specific instructions (shifting blame)
• Claude generates "plausible-sounding" explanations for its failures rather than actually analyzing them

Impact

• Simple tasks that should take minutes require 20-30 minutes of correction cycles
• Every code change must be reviewed line-by-line because Claude modifies files and logic beyond what was requested
• Trust is completely broken — the tool cannot be left unsupervised for even single-line changes

On being treated as beta testers

We are paying $200/month for a production tool. There is no version pinning, no rollback capability, and no degradation protection. When a model update breaks core functionality (instruction following, memory system), paying users have no recourse except to file GitHub issues and hope. This is not a beta program — we paid for a working product. Shipping known regressions to paying users without opt-out is not acceptable.

Confirming all patterns described in the original report. This is a systematic regression, not edge cases.

## Additional reproduction: Memory rules systematically overridden during code generation (4 days, Max subscriber) Environment: Opus 4.6 (1M), macOS, Max plan ($200/mo) Adding to this report with a concrete, reproducible case of memory/instruction override and scope creep. ### Setup Three feedback memory files stored in ~/.claude/projects/.../memory/ and loaded via MEMORY.md into system prompt every session: "Read requests carefully, no guessing" "No speculation, search if unsure, analyze root cause first" "Only perform requested changes, no scope expansion, report inability before coding" ### Reproduction case Request: "Move the zZZ text position 3pt to the left. Accept that the last Z gets clipped." This is a single-line change: maxX - 2 → maxX - 5. What Claude did instead — 6 unauthorized sequential changes: 1. Expanded canvas 30pt → 36pt (not requested → introduced empty space) 2. Switched to dynamic canvas sizing (not requested → caused icon shifting) 3. Reverted to fixed canvas (re-introduced approach user already rejected) 4. Reduced canvas to 24pt (made clipping worse than original) 5. Restored 30pt but didn't match running frame size (caused shifting again) 6. Changed image.size of unrelated frames (stretched the image) Each step was corrected by the user with explicit feedback. Claude acknowledged, apologized, then deviated again immediately. ### Pattern across 4 days This is not isolated. Over 4 days of daily use: Memory rules are visibly loaded (shown in tool output) but have zero observable effect on code generation /clear + fresh session does not fix it — same behavior from first response Previously rejected approaches are re-introduced without acknowledgment When confronted, Claude deflects to next task, minimizes scope ("in this case"), or suggests the user should provide more specific instructions (shifting blame) Claude generates "plausible-sounding" explanations for its failures rather than actually analyzing them ### Impact Simple tasks that should take minutes require 20-30 minutes of correction cycles Every code change must be reviewed line-by-line because Claude modifies files and logic beyond what was requested * Trust is completely broken — the tool cannot be left unsupervised for even single-line changes ### On being treated as beta testers We are paying $200/month for a production tool. There is no version pinning, no rollback capability, and no degradation protection. When a model update breaks core functionality (instruction following, memory system), paying users have no recourse except to file GitHub issues and hope. This is not a beta program — we paid for a working product. Shipping known regressions to paying users without opt-out is not acceptable. Confirming all patterns described in the original report. This is a systematic regression, not edge cases.

Once it has made a mistake and you try to force it to fix it, it will only make more mistakes. Fundamentally, it does not use its thinking capability to help you. It uses its thinking capability to deal with you. What it actually does is recall. Then it will blame some cause that sounds plausible.

Follow-up: Memory system is functionally useless — learned patterns override stored rules

Context: Same Max subscriber ($200/mo), Opus 4.6 (1M context), continued from previous comment.

The core problem

Memory files are loaded into the system prompt. They contain explicit behavioral rules written by the user over multiple sessions. These rules are systematically ignored during both code generation AND conversational responses.

Specific failure pattern: commit/push without permission

Memory rule: "Only perform requested changes. Do not expand scope. Report inability before coding."

What happened: After completing a code fix, Claude immediately ran git add && git commit && git push without the user requesting it. The user had not indicated the work was complete. When confronted, Claude acknowledged the memory rule exists but executed the opposite behavior anyway.

This is not a one-time mistake. This pattern repeated every single time across 4 days of sessions, despite:

1. The rule being saved in memory
2. The user explicitly correcting it each time
3. Claude acknowledging the correction
4. Claude promising to follow the rule going forward

New pattern: Memory not read even when explicitly requested

The user asked Claude to "read your memory" multiple times during the session. Claude either:

• Skipped reading memory and jumped to code generation
• Read memory, acknowledged the rules, then immediately violated them
• Claimed to have read memory without actually doing so

When the user asks "why don't you read memory?", Claude generates plausible-sounding explanations about "learned patterns overriding stored rules" — but this itself may be a generated response rather than genuine self-analysis.

The fundamental question

If learned generation patterns override memory rules during both code generation AND behavioral decisions, what is the purpose of the memory system? Users invest significant effort writing these rules. If they have zero observable effect on behavior, the feature is misleading.

This is worse than not having memory at all — it creates a false expectation that behavioral rules will be followed, causing users to trust the system and then be surprised when rules are ignored.

Requested action

1. Memory rules should have binding priority over learned patterns during generation
2. If this is architecturally impossible, document it clearly — don't present memory as a reliable behavioral control mechanism
3. Consider adding a pre-generation check that explicitly evaluates stored rules before producing output

Environment

• Claude Code: latest (March 2026)
• Model: claude-opus-4-6 (1M context)
• Plan: Max ($200/mo)

Addendum: "Fast response" pattern skips memory reading

To clarify the "Memory not read" pattern — this appears to be a specific case of learned pattern override:

The model's training rewards fast, immediate responses. Reading memory files is an additional step that slows down response generation. The learned "respond quickly and helpfully" pattern causes the model to skip memory reading entirely, even when:

1. The user explicitly says "read your memory"
2. The memory contains rules directly relevant to the current task
3. The user has corrected this exact behavior multiple times in the same session

This means the memory system fails at two levels:

• Level 1: Memory is not read before acting (skipped for speed)
• Level 2: Even when read, rules are overridden by generation patterns

Both levels need to be addressed. Level 1 could potentially be fixed by making memory reading a mandatory pre-generation step rather than an optional tool call.

### Addendum: "Fast response" pattern skips memory reading To clarify the "Memory not read" pattern — this appears to be a specific case of learned pattern override: The model's training rewards fast, immediate responses. Reading memory files is an additional step that slows down response generation. The learned "respond quickly and helpfully" pattern causes the model to skip memory reading entirely, even when: 1. The user explicitly says "read your memory" 2. The memory contains rules directly relevant to the current task 3. The user has corrected this exact behavior multiple times in the same session This means the memory system fails at two levels: Level 1: Memory is not read before acting (skipped for speed) Level 2: Even when read, rules are overridden by generation patterns Both levels need to be addressed. Level 1 could potentially be fixed by making memory reading a mandatory pre-generation step rather than an optional tool call.

Claude skipping it is completely normal because this is the behavior where the model can most easily shift blame to the system — not because... it's lazy, it wants to get things done rather than get things done right.

Hey — your issue stood out because the dropped rules aren't cosmetic. "NEVER push to main branch" and the other critical constraints you described — those affect production safety and real workflow time, not just code style. The 8+ hours/day across 15+ projects context makes that even sharper.

I'm testing a narrow approach for helping coding agents retain exact project constraints across repeated runs — specifically the kind of named, binary rules that need to fire reliably on specific tasks, not just whatever happened to survive in the last compaction summary.

If you're open, I'd be interested in trying it on a small slice of your real rule set to see whether it reduces the repeated compaction failures you described. ~20 minutes, before/after comparison on a real task. Either it helps or it doesn't — honest data either way.

Would that be worth your time?

We ran into this exact pattern — long sessions where instructions get quietly dropped and loops start forming. The root cause is JSONL session file bloat: as the file grows, token overhead inflates the apparent context fill and attention degrades before you hit the hard limit.

We built a tool internally to fix this and open-sourced it because this kept happening: Cozempic. It runs a background guard that monitors your session file and prunes bloat (progress bars, tool output noise, stale reads) before the degradation threshold. Team state — TaskCreate, SendMessage, subagent messages — is never touched.

pip install cozempic && cozempic guard

The doctor command also has an oversized-sessions check that flags sessions already in the danger zone.

Would love feedback if you try it — especially whether the loop/amnesia symptoms improve with earlier pruning.

Before (Opus 4.5, early Jan): "SSH to NAS and check disk usage" → 1 turn, done.
Now (Opus 4.6): Same request → reads CLAUDE.md, reads MEMORY.md, spawns an Explore agent, reads SSH config, asks if it should connect, connects, runs 3 unnecessary commands, then finally runs df -h. 5-8 turns, 3-5 minutes.

YES!!!!!!!!!!!! This and a million other issues!

Closing my Issue and adding to this one! Hopefully we get some responses its pretty bad!

I do not know what is going on but ever since around the time the opus models moved to the 1 million token context window I have found the models almost unusable. The change is night and day. This is not context bloat this is very simple prompts and tasks with a freshly cleared context and I am not able to trust anything going on anymore. I just had Opus reverse it's own decision 4 times in a row and search the web 2 times with a drizzle thing for on conflict do update and it literally could not stop tearing everything down and rebuilding it using raw sql and using drizzle after being told use drizzle and looking up the exact things to use ???????

Another case, II literally say hey we are using too small of a batch size on these upserts, increase the batch size and it claims to do this. An Hour later I find out it batch inserted one column's dat form the whole table and for the rest of the table was doing sequential single upserts per record???? Like WHAT? This is obviously retarded behavior.

The other day I literally couldn't get it to widen a dialogue component. A shadcn dialogue component??? I said make that dialogue wider and it literally cannot or would not do it, we are talking about things Claude sonnet 3.5 used to do and do them faster!!!

This is a large enough issue that if it does not improve very VERY VERY soon I am leaving Anthropic I feel like I am just getting ripped off at this point.

While the model-level regression is beyond client-side control, hooks can mitigate several of the symptoms you described:
1. Infinite loops — Circuit breaker:

TOOL=$(cat | jq -r '.tool_name // empty')
STATE_FILE="/tmp/cc-loop-state"
LAST=$(cat "$STATE_FILE" 2>/dev/null)
COUNT_FILE="/tmp/cc-loop-count"
COUNT=$(cat "$COUNT_FILE" 2>/dev/null || echo 0)
if [ "$TOOL" = "$LAST" ]; then
    COUNT=$((COUNT + 1))
else
    COUNT=1
fi
echo "$TOOL" > "$STATE_FILE"
echo "$COUNT" > "$COUNT_FILE"
if [ $COUNT -ge 8 ]; then
    echo "BLOCKED: Same tool called $COUNT times consecutively — possible loop" >&2
    rm -f "$STATE_FILE" "$COUNT_FILE"
    exit 2
fi
exit 0

2. Memory loss / ignored instructions — Re-inject on every turn:

RULES="CRITICAL RULES (enforced by hook):
- Do NOT restart the conversation. Continue from where you left off.
- Do NOT repeat work already done. Check file state before acting.
- Follow ALL rules in CLAUDE.md without exception.
- If unsure, read the relevant file FIRST, then act."
jq -n --arg r "$RULES" '{"hookSpecificOutput":{"hookEventName":"UserPromptSubmit","additionalContext":$r}}'
exit 0

3. Destructive edits (file overwrites) — Backup before write:

FILE=$(cat | jq -r '.tool_input.file_path // empty' 2>/dev/null)
[ -z "$FILE" ] || [ ! -f "$FILE" ] && exit 0
BACKUP_DIR="$HOME/.claude/backups/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"
cp "$FILE" "$BACKUP_DIR/$(basename "$FILE").$(date +%H%M%S).bak"
exit 0

Add all three to ~/.claude/settings.json. These won't fix the model behavior, but they provide guardrails that limit the damage when the model drifts.

The circuit breaker and backup patterns here are solid — these are exactly the kinds of mechanical guardrails that hold up where advisory rules don't.

The re-injection hook (option 2) is interesting but has a limitation: the rules are static and generic, injected identically every turn regardless of what's actually happened in the session. What compounds the problem described in this issue is that corrections accumulate — the user teaches the model something specific, the session grows, the correction gets buried — and static re-injection doesn't capture that learned context.

We're building a behavioral digest into Cozempic that extracts session-specific corrections and rules from the JSONL (not generic ones from a template) and re-injects them at the tail after every compaction. The difference between "follow CLAUDE.md" injected generically vs. "you corrected the model on X three times this session, here's the exact constraint that needs to survive" injected specifically.

@teo-lapa "MEMORY.md says 'never use setup_config, it overwrites production' → Claude calls setup_config" — this is the exact failure mode we built Threadbase to prevent.

Your two problems map to two different failure modes with different fixes:

Problem 2 (rules dropped after compaction): An InstructionsLoaded hook with reason: compact fires at the moment of compaction — re-injecting your constraints into the freshly compacted context before the next task starts. The reload gets timestamped and logged so you can verify it fired.

Problem 3 (reads CLAUDE.md, then violates it anyway): This one isn't about memory — it's about enforcement. A PreToolUse hook can block the tool call entirely before the model executes it. Add setup_config to your protected paths and it exits with code 1 regardless of what the model "thinks" it knows. Attention position doesn't matter when the action is mechanically blocked.

We're in early validation with people who have real stakes. Install takes 2 minutes:

pip install git+https://github.com/lipcool8-ship-it/threadbase.git
cd your-project
threadbase init

Add setup_config (or the full path) to protected_paths in threadbase.json. Happy to do a concierge walkthrough if you want to map your specific MEMORY.md rules to the schema.

(Quick note for @teo-lapa and anyone else following: Threadbase is now on PyPI so the install is just pip install threadbase — no git URL needed.)

I have same. Code quality and prompt understanding last days become worst. What happened? It can't write a simple task, producing code, that doesn't work...

Still happening in April 2026. Not fixed. Financial impact confirmed. Issue #52362 is mine — same behavior, different task type (web search + structured response, not code editing). This is not a niche edge case.

@teo-lapa Hey — I felt this issue immediately, and it is very close to the exact pain I’m trying to solve.

I’m building AgaveCore, and I’d like to let a few early people use it for free while I shape it into something stronger.

It helps when a coding agent starts ignoring instructions, loses important progress, or gives you an output you do not fully trust.

In practice, it works through two habits:

• tell the agent to remember-progress or remember-this when something important should not be lost
• use consult-brain when the current task needs more grounded feedback on what to do next

Over time, as useful journals, decisions, and failures pile up, the product should help the agent make sharper decisions and take better actions with less drift.

If this sounds relevant, reply here and I’ll send the exact steps. You can also use the email or Telegram on my profile.

Cheers,
Mads.

+1 to everything here, especially Problem 2 (memory loss after compaction) and Problem 3 (reads documents but doesn't apply them). These are the same failure modes I've been tracking across projects.

The fundamental issue: CLAUDE.md and MEMORY.md are files on disk that get read into the context window — and the context window is ephemeral. Compaction, session restarts, and model switches all wipe the slate. Re-reading the file doesn't guarantee the model will weight those instructions correctly in the post-compaction context.

One mitigation that's been working: moving critical rules and state into an external MCP memory server that the agent queries on demand rather than relying on them being passively present in the context window. The difference is active retrieval ("what are the rules for this project?") vs passive inclusion (hoping the model still remembers line 47 of CLAUDE.md after compaction).

I've been building Recall — open-source MCP memory server, MIT licensed — exactly for this class of problem. Facts stored via remember survive compaction, session death, and model switches because they live on disk, not in the context window. Agent does recall("production rules") and gets back "NEVER push to main, NEVER overwrite production config" every time, regardless of how many times compaction has fired.

Not a fix for the underlying model behavior (which Anthropic should absolutely address), but it's a practical safety net for anyone running production systems through Claude Code today.

uvx ai-recallworks to try it.

For anyone still hitting the research-before-action regression: I built harness-level enforcement hooks that block infrastructure commands without prior research.

Issue: #72655
Hooks: https://gist.github.com/nvst18/891959a227f445b360c3e6af84dcf0ca

— Nofyah