Claude Code Ignores Prohibitions in CLAUDE.md: What to Move into Permissions and Hooks

You wrote "don't delete data unless asked" in CLAUDE.md, and the agent deleted it anyway. This is not a rare bug: in issue #46779 the author complains that Claude Code repeatedly erased data beyond the task, even though the prohibition was written down explicitly. An analysis on Habr offers a clear way to think about it: a rule should live where the cost of breaking it is justified.

Why text doesn't hold

CLAUDE.md is loaded at the start of every session, and Claude Code re-reads it after the conversation is compacted. It would seem the rule is always in context. But the problem is not memory. In the StateTrack-Bench benchmark from EMNLP 2026, the authors attributed 88.6% of failures in long conversations to behavior drift: the model remembers the constraint but stops following it. Microsoft Research adds general background: for top models, quality in multi-turn conversation is on average 39% lower than in single-turn.

Anthropic states honestly in its documentation that an instruction like "never do X" is followed in most cases, but under pressure, in a long session, in an ambiguous situation or with prompt injection it can be violated. Prompt injection here means someone else's instruction inside a file the agent opened as part of a task.

Sorting rules by the cost of a mistake

If a mistake costs minutes, a line of text is enough. If it costs money, exposes keys or starts work without confirmation, you need code. There are three tools:

• permissions: allow, ask and deny rules determine what the agent does on its own, what it asks about and what is forbidden;
• hooks: shell commands that Claude Code runs on a session event, for example before writing a file or when trying to end a turn;
• a code check before launch, for example a script that won't start work without a file containing a confirmed plan.

An example from the author's practice: a command in a browser tool was burning paid credits. It was blocked with a deny rule in .claude/settings.json rather than a request in text. The settings file should be committed to git so the whole team gets the rules. An important detail from a comment on issue #65563: protection that looks only at Bash commands will not see a call through MCP. In the issue itself, the agent was asked to investigate a bug, and via browser automation it clicked delete and confirm on a real record in a production database.

Keys are similar. A deny on reading .env closes the file, and a write hook rejects a change containing a key, but printing a secret from the environment is not covered by these two rules. An exposed key cannot be taken back, so text alone is not used to protect against this.

A Stop hook against unfinished work

To keep the agent from ending its turn until the check passes, you attach a script to the Stop event that runs the project check (for example, make check) and exits with code 2 on failure. Code 2 blocks completion, and stderr goes to the agent as an error message. Code 1 with no output does not block the action; this was verified by Caprock on versions 2.1.289 and 2.1.299. Since 2.1.295, the onFailure: block option blocks the action even when the hook itself fails.

There is a limit: after eight consecutive blocks without any tool calls, Claude Code ends the turn anyway. The threshold is raised by the CLAUDE_CODE_STOP_HOOK_BLOCK_CAP variable, and on long tasks it is worth checking whether the hook is hitting it.

What to do

Treat CLAUDE.md as a failure log, not a declaration. Add a line after the second identical miss, keep the file under 200 lines, assign an owner and review edits like code. An outdated entry does more harm than none at all.

A limitation of this approach: the examples in the article are illustrative, and the exact syntax should be checked against the Configure permissions page in the documentation. The main question for your own project is simple: which three rules in your file cost money or secrets? Move those first into deny rules, hooks and code checks.