This is how a prohibition on automatically retrying the task once the subscription limit was reached ended up in the file. Its owner set it: the retry hits the same limit. With usage credits enabled (an additional paid balance used to cover work beyond the subscription limit), the retry also costs money: according to the limits documentation, with credits enabled, work does not stop at the limit and continues using credits. Therefore, to the question of whether the agent should retry the task after the limit is reached, my answer is no.
The file has to be cleaned out just as regularly as it is topped up. According to the same Anthropic documentation, an outdated entry is more harmful than its absence. Anthropic recommends keeping CLAUDE.md under 200 lines, assigning it an owner, and reviewing changes like code.
Why the agent stops following a rule from CLAUDE.md in a long session
The agent most likely remembers the rule from CLAUDE.md, but at some point stops applying it. This is what happened in the StateTrack-Bench benchmark from the EMNLP 2026 conference: the authors attributed 88.6% of failures in long dialogues to behavioral drift, when the AI model remembers the constraint but no longer follows it. That is nearly nine out of ten failures, and rereading CLAUDE.md after the conversation has been compacted will most likely not save them: the rule is already in the context.
Microsoft Research also showed an overall decline: across all the leading models tested, performance in multi-turn dialogue was lower than in single-turn dialogue, by an average of 39% across six generation tasks. Anthropic writes about its rules plainly: a prohibition such as “never do X” in CLAUDE.md is unsuitable for anything that must not be allowed to happen even once. Claude follows such an instruction in most cases, but may violate it under pressure, in a long session, in an ambiguous situation, or because of prompt injection.Prompt injection here means someone else’s instruction in a file that the agent opened as part of the task.
Which rules cannot be left only in the CLAUDE.md text
Rules whose violation costs money, exposes keys, or starts work without confirmation cannot be enforced by text alone. Claude Code has permissions for these: allow, ask, and deny rules specify what the agent does on its own, what it asks about, and what is forbidden. It also has hooks: shell commands that Claude Code runs automatically in response to a session event, for example when the agent is about to write a file or finish a turn. There is also a separate code-based check before work is started.
the retry hits the same limit, and usage credits cost money | TAG40||
Do not finish until the work is complete@@ | the agent ends its turn without completing the work@@ | stop hook (Stop)@@ |
Currently, my prohibition on retrying after reaching the limit is only in the text: without usage credits, a retry just hits the same limit. With credits, it costs money, and then a single line in CLAUDE.md is not enough.@@
The agent obtains keys and passwords only from the environment and .env. By itself, this does not prevent it from reading a secret and outputting it or writing it into code, so the prohibition is enforced in code: a deny rule on reading .env blocks the agent from accessing the file containing the keys, and a file-write hook rejects a change containing a key. These two rules do not cover outputting a secret from the environment. Once a key has been exposed, it cannot be taken back, so such a rule cannot remain text alone; I looked into separately why the PreToolUse hook lets keys slip into commits.@@
The rule to start work only after an approved plan was the final check that relied on an agreement. Now code verifies it: the launch script first looks for a file containing my confirmation of the plan and exits with an error if it is missing, so the work does not start.@@
How to prohibit the agent from running a command via permissions in the Claude Code settings@@
A command that the agent must not run under any circumstances is added to the deny list in the permissions. This is how I blocked the browser tool command that was spending paid credits: with a rule in the permissions, rather than a request in the text.The Claude Code documentation recommends committing the project-wide `.claude/settings.json` to git so that all participants receive the rules. The example is illustrative; the exact syntax is described on the Configure permissions page linked from the same documentation.
{ "permissions": { "deny": ["mcp__browser__paid_action"] } }`deny` is the list of things the agent is forbidden to do. According to AgentVera, anything that must never happen is moved into `deny` rules, hooks, or a sandbox: even automatic mode with a risk classifier only evaluates the action and does not serve as a hard rule.
`mcp__browser__paid_action` is the conditional name of a command for a browser tool connected via MCP, a protocol for external agent tools. A safeguard that only monitors Bash commands will not see such a call, as noted by a commenter on issue #65563. In the issue itself, the author writes that the agent was asked only to investigate a deletion bug, but through browser automation it clicked delete and confirmation on an actual record in the production database.
The Stop hook prevents the agent from abandoning the work midway
To prevent the agent from ending its turn until the work is completed, a hook is attached to the Stop event. Claude Code runs it when the agent tries to finish and, with exit code 2, returns it to work. Put the JSON in the Claude Code settings file, put the `check-done.sh` script in the project root, and make it executable. The example is illustrative: replace `make check` with your project’s check command.
{ "hooks": { "Stop": [ { "hooks": [{ "type": "command", "command": "./check-done.sh" }] } ] } }exit 2 is a blocking error: according to Anthropic’s hook documentation, the action is canceled, and the agent receives the text from stderr as an error message.
Exit code 1 without output does not block the action: this was tested in Caprock on versions 2.1.289 and 2.1.299. Since version 2.1.295, the onFailure: block option blocks the action even when the hook fails.
After eight consecutive blocks without a tool call, Claude Code still completes the turn, according to AgentVera. The CLAUDE_CODE_STOP_HOOK_BLOCK_CAP variable raises the threshold, so for a long-running task, it is worth checking whether the hook hits it.
What to keep in CLAUDE.md and what to move to Claude Code permissions and hooks
An agent’s rules file is a failure log, not a declaration: every line in it should address a case that has already occurred. If violating a rule costs money, exposes secrets, or starts work without confirmation, the rule does not belong in the text: it should be enforced by permissions, a hook, or a code check. CLAUDE.md should retain what the agent may occasionally violate without consequences: the project’s structure, workflow, and style.I'm curious which rule you first moved from CLAUDE.md into the settings, and after what failure.
