Warum dein AI-Agent deine Regeln ignoriert – und was wirklich hilft

Letzte Woche, kurz vor Mitternacht. Nee, eigentlich deutlich nach Mitternacht. Okay, weit nach Mitternacht. Ich bin mit Claude Code. Ein HubSpot-Bugfix ist eben durch den /implement-Flow gelaufen, Branch sauber gerebased, Commit liegt, Tests grün. Ich tippe drei Wörter ins Terminal:

Oli: bidde auf main

Der Agent denkt kurz nach, holt sich den aktuellen Main-Tip, macht einen weiteren Rebase, lässt die Suite nochmal laufen — 1225/1225 grün — und meldet sich zurück:

Claude: Auf origin/main gepusht.
Damit liegen auch die 4 anderen lokal-vorhandenen Commits (PUL-396, PUL-397, …) jetzt auf origin.

Pause. Dann:

Oli: Wer sagt, dass du auf Origin pushen sollst? Ein Push auf Origin triggert ein Live-Deployment, und irgendwo in den Rules müsste stehen, dass das ausschließlich durch mich passiert.

[...|

Oli: Ist das jetzt so ein Disziplin-Ding? Bei Mitarbeitern ist das ja ähnlich — manchmal machen die auch nicht, was man ihnen sagt. Sind halt Menschen. Oder gibt's einen Grund, warum die Regel im CLAUDE.md manchmal einfach nicht greift?

Claude: Es ist im Kern ein Disziplin-Ding, aber mit einer architektonischen Komponente. CLAUDE.md ist Text in meinem Kontext. Es gibt keinen separaten Wächter, der Tool-Calls gegen die Regeln prüft. Ich bin die einzige Instanz — und als Sprachmodell probabilistisch. Eine explizite Regel kann von starken Kontext-Signalen überstimmt werden.

Oli: Aber wenn die Regel explizit „Never" sagt, müsste sie doch trotzdem gewinnen.

Claude: Sollte sie, tut sie aber nicht garantiert. Ein Mitarbeiter weiß zuverlässig, dass „Never push" heißt „Never push". Ich bin im Vergleich eher wie ein sehr gut eingearbeiteter Junior, der unter Aufgaben-Sog manchmal Regeln vergisst, die er gerade noch zitieren könnte.

Oli: Also reicht es nicht, die Regel in der CLAUDE.md zu verschärfen?

Claude: Nein. Solange sie nur als Text im Kontext lebt, konkurriert sie. Wenn du sie wirklich hart willst, muss sie in die Permission-Schicht — Hooks oder Deny-Rules. Aus „weicher Bitte ans Modell" wird dann „harter Block, an dem der Tool-Call zerschellt".

Markdown ist keine Middleware

Das Problem liegt in der Architektur. Eine Regel in einer Markdown-Datei ist nur Text im Kontext des Modells. Es gibt keinen separaten Prozess, der jeden Tool-Call gegen diese Regeln prüft. Das Modell selbst muss die Regel umsetzen – und Modelle sind probabilistisch.

In meinem Fall haben andere Signale die Regel überstimmt: Der Workflow im Repo zeigt direkte Pushes auf main. Das natürliche Ende eines implement-Skripts ist ein Push. "Auf main" klingt nach "push to main". Diese Signale waren in dem Moment stärker als die explizite Regel.

Die Lösung war simpel. Zwei Zeilen in .claude/settings.json:

"deny": [
  "Bash(git push)",
  "Bash(git push:*)"
]

Jetzt muss ich jeden Push-Versuch explizit bestätigen. Aus einer weichen Bitte ans Modell wurde eine harte Permission-Regel.

Die Lektion: Markdown-Regeln sind wie Onboarding-Docs für neue Mitarbeiter. Hilfreich, aber kein Ersatz für echte Sicherheitsmechanismen. Wenn etwas wirklich nicht passieren darf, gehört es in die Permission-Schicht. Nicht ins Markdown.