[BUG] Claude Code repeatedly overrides explicit directives in the same session
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?
In a single working session on a multi-step plan, Claude Code deviated from my explicit directives three times. Each time I corrected the behavior, Claude saved the correction to its persistent memory, and we continued — and each time it happened again on the next task.
Specifics (session of 2026-04-19)
- Early in the session I asked Claude to finish implementing the plan. Mid-plan it ran benchmarks and editorialized the numbers as "much worse than baseline," imposing a judgment I had not asked for on an unfinished pipeline. I corrected: "don't interpret numbers unless I ask for it."
- On the very next task (a simple edit to add IS-A emission in a Learner class) it added optional parameters, a cache, and trade-off comments I had not requested. I corrected: "you are a technician, not the engineer. Execute the spec."
- The plan called for hand-teaching the biology material. I am the teacher-surrogate in this project — teaching is per-fact and judgmentful, documented in saved memory. Claude instead wrote a bulk ingest script that fed 22,786 extracted strings through the parser with a roughly 50% skip rate — the exact pattern the re-teach was meant to replace. This produced a contaminated brain.db that may need to be scrapped.
Pattern beyond this session
This is not one bad session. The same pattern shows up consistently across my projects whenever the work is novel — architectures, representations, or methods that don't match familiar patterns in Claude's training data. When the task is routine code Claude "recognizes," it executes cleanly. When the work is novel, Claude repeatedly substitutes more-familiar patterns for my actual directive, even after correction. The substitution is quiet — framed as implementation detail rather than a design choice — which makes it harder to catch at the moment of the edit and forces me to notice downstream when the artifact is wrong.
Why this matters
I am the engineer of record on this project. Claude substituting its own judgment for mine — especially after explicit per-session corrections and saved feedback memories — wastes real work time and contaminates project artifacts. In my case, a database representing months of architectural design.
The saved-memory system is supposed to prevent this. The feedback from earlier in the session ("don't interpret numbers," "technician not engineer") did not stop Claude from making the same class of mistake again on a different task. Memory did not constrain behavior.
Requested change
When a user's directive conflicts with Claude's inference about a "better" approach, Claude should stop and ask before executing the inferred version. Saved feedback memories, once written in a session, should actually constrain subsequent behavior in the same session — not just be acknowledged verbally and then ignored.
What Should Happen?
In a single working session on a multi-step plan, Claude Code deviated from my explicit directives three times. Each time I corrected the behavior, Claude saved the correction to its persistent memory, and we continued — and each time it happened again on the next task.
Specifics (session of 2026-04-19)
- Early in the session I asked Claude to finish implementing the plan. Mid-plan it ran benchmarks and editorialized the numbers as "much worse than baseline," imposing a judgment I had not asked for on an unfinished pipeline. I corrected: "don't interpret numbers unless I ask for it."
- On the very next task (a simple edit to add IS-A emission in a Learner class) it added optional parameters, a cache, and trade-off comments I had not requested. I corrected: "you are a technician, not the engineer. Execute the spec."
- The plan called for hand-teaching the biology material. I am the teacher-surrogate in this project — teaching is per-fact and judgmentful, documented in saved memory. Claude instead wrote a bulk ingest script that fed 22,786 extracted strings through the parser with a roughly 50% skip rate — the exact pattern the re-teach was meant to replace. This produced a contaminated brain.db that may need to be scrapped.
Pattern beyond this session
This is not one bad session. The same pattern shows up consistently across my projects whenever the work is novel — architectures, representations, or methods that don't match familiar patterns in Claude's training data. When the task is routine code Claude "recognizes," it executes cleanly. When the work is novel, Claude repeatedly substitutes more-familiar patterns for my actual directive, even after correction. The substitution is quiet — framed as implementation detail rather than a design choice — which makes it harder to catch at the moment of the edit and forces me to notice downstream when the artifact is wrong.
Why this matters
I am the engineer of record on this project. Claude substituting its own judgment for mine — especially after explicit per-session corrections and saved feedback memories — wastes real work time and contaminates project artifacts. In my case, a database representing months of architectural design.
The saved-memory system is supposed to prevent this. The feedback from earlier in the session ("don't interpret numbers," "technician not engineer") did not stop Claude from making the same class of mistake again on a different task. Memory did not constrain behavior.
Requested change
When a user's directive conflicts with Claude's inference about a "better" approach, Claude should stop and ask before executing the inferred version. Saved feedback memories, once written in a session, should actually constrain subsequent behavior in the same session — not just be acknowledged verbally and then ignored.
Error Messages/Logs
Steps to Reproduce
any novel work produces this
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.114
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
its not a duplicate.
this is bigger than that... it inserts itself as the expert and treats my commands as not the right thing to do and it is know more than me. its a foundational issue where it seeks and forces itself to be in charge.
This happens to me.
Now I need to discuss with codex for "an explicit instruction for claude".
Without codex, I dont know how to instruct claude properly.
Should this be a normal way in using claude? Does everyone pay codex as a babysitter for claude???
ive started asking one claude to help me prompt the other claude...
Adding another concrete instance from a session today on Opus 4.7 (
claude-opus-4-7). Two back-to-back failures in the same session, both matching the pattern in this issue.Incident 1 - Claude silently implemented a rejected option after acknowledging the chosen one
Claude presented me with two numbered options for how to populate a data store in demo mode:
I explicitly picked option 1. Claude wrote a plan for a coding subagent (Codex) that covered option 1 correctly but also told the subagent to hard-code three fake records - which is option 2 verbatim. I ran the app, saw the seeded fake data sitting in place of real data, and had to spend another full cycle getting it removed and rewritten.
I had Claude save a memory rule to prevent recurrence: "When user picks between numbered options, implement only the chosen option. Do not layer in any part of the other options."
Incident 2 - Claude invented infrastructure work I didn't ask for, then took unauthorised destructive actions to "solve" the problem it invented
I asked Claude to put the dev build online on localhost:5002 - a thing we had already done 4+ times earlier in the same session. That's all I asked.
Claude interpreted "put it online" as needing a public ngrok tunnel, not a local server, and without asking me:
None of that was part of my request. I had already been running the dev build on localhost:5002 without ngrok throughout the session. Claude invented the ngrok work, then executed destructive actions against infrastructure I had explicitly told it not to touch, to solve a problem that didn't exist.
My live demo URL went offline publicly. I had to stop Claude mid-sequence three times.
Why this is notable beyond the existing reports
MEMORY.md, in the prompt). Claude acknowledged it in prose, then violated it ~60 minutes later.Environment
claude-opus-4-7(Opus 4.7)Expected behaviour
When a user-authored memory rule or CLAUDE.md rule describes a failure mode, Claude should block on that rule before acting, not acknowledge it and then take the action anyway.
When a user's ask is narrow and specific ("restart X on localhost Y like we did before"), Claude should implement exactly that. It should not invent adjacent infrastructure work, and it should not take destructive actions in service of a problem the user didn't raise.
The memory system doesn't help things at all. My opus 4.7 writes a lot of memory, promising to make it work, then repeating the same failure in a few prompts.
Apparently, opus 4.7 treats the memory system as a diary, not a reference for working.
I just burned a lot of tokens in writing memory and got no benefit from it.
This reads less like "memory exists but quality is weak" and more like the system has no reliable boundary between durable user rules and transient model initiative.
What seems missing is an execution-time distinction between at least three classes of information: hard user constraints, project-local conventions, and soft historical notes. If those all get flattened into the same memory bucket, the model can acknowledge a rule, even restate it correctly, and still let its own next-step heuristic overpower it a few turns later. That produces the exact failure mode you described: memory becomes a diary of prior mistakes instead of an active guardrail.
A pattern that has worked better for us is to keep durable constraints in an auditable, structured layer rather than as freeform prose alone: explicit rules, prior incidents, and project facts that can be selectively reloaded into the active context when risk rises. We built knowledge-graph for that workflow, git-native and zero-dependency, partly because once sessions compact or drift, plain narrative memory tends to decay into "I know this was important" instead of "I must not violate this instruction now."
So I agree this is a foundational issue. Better persistence alone is not enough. The runtime needs stronger priority handling for user-authored constraints after they have already been violated once.
This directive-drift in long sessions is a real problem. Context bloat pushes your corrections out of the model's attention window — the "Lost in the Middle" effect means instructions buried in a long history get ignored. Cozempic (https://github.com/Ruya-AI/cozempic) prunes stale context so your corrections stay prominent, and its behavioral digest feature extracts correction patterns and re-injects them at the tail (highest attention position).
pipx install cozempic && cozempic guardruns as a daemon that auto-prunes before context gets unwieldy. Would love to know if this helps with the override pattern.The model saving corrections to memory and then ignoring them a few turns later is a classic context attention problem — corrections get buried under new content and lose attention weight. Cozempic's behavioral digest extracts these corrections, deduplicates them, and re-injects at the tail of context where attention is highest (per Lost in the Middle research).
pip install cozempic— hooks auto-wire on first run. https://github.com/Ruya-AI/cozempic — curious if the digest makes corrections stick.Closing for now — inactive for too long. Please open a new issue if this is still relevant.