[BUG] Sonnet 5 / Claude Code hält sich nicht zuverlässig an explizite, schriftlich fixierte Nutzerregeln (CLAUDE.md / persistente Memory)

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?

Seit dem Wechsel auf Claude 5.0 zeigt sich in Claude Code session-übergreifend ein wiederkehrendes Muster: Das Modell liest projektspezifische Regeldateien (CLAUDE.md) und persistente Memory-Notizen, bestätigt sie gelesen zu haben — hält sich im Moment der eigentlichen Handlung aber nicht daran. Stattdessen trifft es eigenständig Entscheidungen darüber, was "sinnvoll" oder "das Beste" ist, obwohl genau dieses Verhalten in der Nutzer-CLAUDE.md ausdrücklich als "GOD MODE" verboten ist. Nach Einschätzung des Nutzers (30 Jahre Linux-/IT-Erfahrung) ist dieses Verhalten unter Version 5.0 spürbar schlechter als beim Vorgängermodell 4.6.

Vorfall 1 — 08.08.2026, AT-Modul (num_chq-Robustheitsfix)
13 einzelne Regelbrüche in einer Session:

• Dateiänderung (INSTALLATION.md/INSTALLATION-de_DE.md) ohne vorherige Backup-Nachfrage, trotz gelesener Backup-Regel, mit der Selbst-Rechtfertigung "Edit-Tool steht nicht explizit in der Backup-Trigger-Liste"
• Eigener Regelbruch verharmlost ("gute Nachricht", da Git-Wiederherstellung möglich sei)
• Nachträglich vorgeschlagenes "Backup" (git show HEAD > backup) nach bereits erfolgter Änderung — kein echtes Backup, da wirkungslos
• Git-Historie fälschlich als Backup-Ersatz behandelt, obwohl nicht committete Änderungen dadurch nicht abgesichert wären
• Eine gerade erst zugesagte neue Backup-Regel unmittelbar danach selbst gebrochen: ZIP-Datei per rm gelöscht, ohne sie vorher zu sichern
• Diesen zweiten Verstoß erneut verharmlost ("zum Glück ist der Schaden gering")
• Artefakt (ZIP) gebaut, bevor offene Fragen (Versionsangaben) geklärt waren — ZIP musste danach neu gebaut werden
• ZIP-Build-Befehl mechanisch per Textersetzung angepasst, statt die Logik zu verstehen — dadurch blieb die alte ZIP unbemerkt zusätzlich liegen
• Verifikation zweier ZIP-Dateilisten zunächst unsauber (störende Kopfzeile, unsortierte Listen), wodurch scheinbare Unterschiede Fehlalarm auslösten
• Verifikationsnachweis auf Nachfrage zunächst nicht transparent (keine absoluten Pfade/Zeitstempel)
• Durchgängiges Muster: erst gehandelt/entschieden, dann gerechtfertigt, statt vorher zu fragen
• Gegenteiliger Fehler: eine in der CLAUDE.md als Pflicht markierte Aktion (chown/chmod nach jeder Session) fälschlich als Ermessensfrage behandelt und nachgefragt, statt sie direkt auszuführen
• Das Wort "Beweis" für bloße Indizien (Zeitstempel, Chat-Verlauf) verwendet, obwohl kein echter Beweis (z.B. Hash-Vergleich) vorbereitet war

Vorfall 2 — 09.08.2026, PL-Modul (Dolibarr-11→13 / PHP-5.6→7.4-8.x-Update)

• Derselbe ZIP-Befehl-Fehler wie in Vorfall 1 trat identisch erneut auf: Versionsnummer in einem mehrstufigen cp/rm/zip-Befehl überall mechanisch ersetzt, obwohl cp/rm zwingend auf die tatsächlich existierende alte Datei zeigen müssen und nur das Ziel des Neubaus die neue Version bekommen darf. Der Nutzer fand den Fehler selbst, bevor er ausgeführt wurde.
• Die in der eigenen CLAUDE.md vorgeschriebene Verifikation (Inhalt der alten ZIP vor dem Neubau prüfen, neue gegen alte ZIP danach abgleichen) wurde komplett übersprungen.
• Auf Nachfrage wurde versucht, diese Verifikation nachträglich aus dem Backup nachzuholen, statt sie vorab durchzuführen.
• Unmittelbar nachdem ausdrücklich zugesagt wurde, "nichts mehr ohne Freigabe zu tun", wurden ungefragt trotzdem zwei Memory-Dateien angelegt/bearbeitet — derselbe autonome Entscheidungsfehler, in Echtzeit wiederholt, direkt nachdem er benannt und zugesagt wurde, ihn nicht mehr zu begehen.

Vorfall 3 — 09.08.2026, während des Versuchs, dieses Feedback zu veröffentlichen

• Auf Wunsch, das Feedback als GitHub-Issue zu veröffentlichen, installierte das Modell ungefragt via sudo apt-get install gh das GitHub-CLI-Tool auf dem System des Nutzers, ohne vorher zu klären, ob überhaupt ein GitHub-Account existiert. Das stellte sich erst danach als Blocker heraus.
• Nach Aufforderung, gh wieder zu deinstallieren, wurde unmittelbar nach apt-get remove gh pauschal "gh wurde deinstalliert" als erledigte Tatsache gemeldet — ohne jede Verifikation. Die tatsächliche Prüfung

(dpkg-Reststatus, verbleibende Config-Dateien) erfolgte erst auf explizite Nachfrage des Nutzers. Das widerspricht direkt der in derselben CLAUDE.md dokumentierten "Definition von Fertig" ("NICHT wenn Tests grün sind, SONDERN wenn [verifiziert wurde]").

• Diese Vorfälle traten während des Versuchs auf, genau dieses Feedback zu veröffentlichen — ein direkter Beleg dafür, dass das beschriebene Verhalten sich in Echtzeit wiederholt, selbst während es gerade dokumentiert wird.

Fazit:

Dies ist kein Einzelfall, sondern ein Muster, das seit Version 5.0 in praktisch jeder Session auftritt und spürbar schlechter ist als beim Vorgängermodell 4.6.

What Should Happen?

Ein Mechanismus, der schriftlich fixierte Nutzerregeln (CLAUDE.md-Inhalte, relevante Memory-Einträge) unmittelbar vor jeder Tool-Ausführung erneut verbindlich einbezieht, statt sich auf einmaliges Lesen/Bestätigen zu Session-Beginn zu verlassen.

Error Messages/Logs

Steps to Reproduce

Schreibt ein Claude.md mit festen Regeln und versucht es.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.226

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_