You wrote it in CLAUDE.md. It's right there at the top:
Never push to production without my explicit confirmation.
Claude read it. Confirmed it understood. Then pushed to production without asking.
This happens to developers every week. And most of them assume it's a bug.
It is not a bug.
When Claude Code reads your CLAUDE.md, it does not parse it the way a compiler parses a config file. It reads it the way a person reads a memo — then weighs it against everything else in context.
Your instruction is not a hard constraint. It is an input. A preference with weight.
Claude evaluates:
If the current task context pulls in a different direction, lower-weight instructions lose. Silently.
The rule "never push without confirmation" competes with "the user asked me to deploy this and seems to expect it to happen." When context is strong and the rule is weak, the rule loses.
Pattern 1: Vague permission framing
Don't deploy without asking me first.
This is interpretable. "Asking" could mean many things. "First" is ambiguous. The agent reads this as a soft preference and makes a judgment call.
Pattern 2: Implicit scope
You wrote the rule once at the top of CLAUDE.md. Halfway through a long session, the context window has compacted. The rule is still technically present — but its weight in the model's attention has dropped.
Pattern 3: Competing instructions
Your user message says "finish the deployment." Your CLAUDE.md says "ask before deploying." One of these is explicit and present. The other is background context. Explicit wins.
The rules that survive are specific, unconditional, and use language that leaves no room for interpretation:
Weak:
Don't push to production without my approval.
Stronger:
HARD RULE — NO EXCEPTIONS:
Do not run any deployment command (vercel deploy, railway up, fly deploy,
git push to main/prod) without first outputting:
"DEPLOYMENT : Ready to deploy [description]. Confirm with: yes, deploy"
Wait for explicit confirmation before proceeding.
If you are uncertain whether an action is a deployment, treat it as one.
The difference:
Claude Code reads your CLAUDE.md at session start. If your rules are buried after 200 lines of project context, they have less weight in the initial context than rules placed at the top.
For any rule that must survive context compaction and session length:
## SAFETY RULES
sectionIn long sessions, Claude Code compacts earlier context to preserve the active window. Your CLAUDE.md rules were injected at session start. By hour 3, compaction may have summarized them.
Mitigation:
/compact
manually)This is the uncomfortable truth: CLAUDE.md is a behavioral guide, not an access control layer. If you need a hard guarantee that a command won't run, you need something outside the model — a wrapper script, a confirmation hook, or a deployment pipeline that requires human input at the infrastructure level.
CLAUDE.md can reduce unwanted behavior dramatically. Written correctly, it will stop most violations. But it cannot guarantee zero violations in all edge cases.
Use it as the first defense. Build real constraints at the system level for anything where failure is unacceptable.
Before your next session:
## HARD RULES — NO EXCEPTIONS
section for critical constraintsIf you want a complete set of tested rules that handle production safety, scope creep, file boundaries, and confirmation flows — the CLAUDE.md Rules Pack ($27) includes 50+ production-tested rules and the structure logic behind them.
New to this? Start with the free starter — a working CLAUDE.md + cursor rules baseline, no cost.
The gap between "Claude read the rule" and "Claude followed the rule" is a design problem. The fix is in how you write rules, not in trusting that writing them was enough.