Warum Coding-Agenten Ihre Anweisungen ignorieren

Warum Coding-Agenten Ihre Anweisungen ignorieren

Coding-Agenten ignorieren Ihre Anweisungen aus vier Gründen. Keiner davon ist, dass Sie zu höflich waren. Die Regel war nie im Kontextfenster enthalten. Die Regel war zu vage, um eine Handlung daran zu prüfen. Etwas anderes im Kontext widersprach ihr, meistens der Code, den der Agent gerade gelesen hatte. Oder die Regel ist weiterhin geladen, steht aber weit hinter dem aktuellen Turn, und der Agent arbeitet mit den Inhalten, die sich in der Nähe befinden.

Für jede Ursache gibt es eine eigene Lösung. Daher müssen Sie zunächst unterscheiden, welche Ursache vorliegt. Großbuchstaben und das Wort IMPORTANT sind keine Diagnose. Die folgenden Mechanismen verwenden Claude Code als Beispiel, weil sein Lade- und Kompaktierungsverhalten mit Stand August 2026 ausführlich dokumentiert ist. Andere Tools unterscheiden sich in den Details, verhalten sich im Grundsatz aber genauso.

Zunächst zwei Begriffe. Das Kontextfenster ist der Textblock, den das Modell in einem bestimmten Turn sieht: System-Prompt, Ihre Anweisungsdateien, die Konversation und jede Datei, die der Agent gelesen hat. Der Harness ist das Programm um das Modell herum, also die Komponente, die Dateien vom Datenträger liest und diesen Block zusammenstellt. Fast jede Beschwerde in diesem Beitrag richtet sich eigentlich gegen den Harness und nicht gegen das Modell.

Ihre Anweisungsdatei ist eine Nachricht, keine Einstellung

Eine Anweisungsdatei ist keine Konfiguration. Zur Laufzeit liest nichts CLAUDE.md ein und setzt die Vorgabe durch. Das Harness liest die Datei von der Festplatte und fügt den Text in die Konversation ein. In Claude Code wird dieser Inhalt als User-Nachricht nach dem System-Prompt übermittelt. Das Modell sieht Ihre Regeln daher genauso wie alle anderen von Ihnen eingegebenen Inhalte.

Das hat eine unangenehme Konsequenz. Ihre Regeln stehen mit jedem anderen Text im Fenster in Konkurrenz und haben dabei denselben Stellenwert. Eine Regel ist eine Behauptung. Die Datei, die der Agent gerade geöffnet hat, ist ein Beleg. Wenn beide nicht übereinstimmen, setzt sich der Beleg häufig durch. Dabei wird kein Fehler ausgelöst, weil aus Sicht des Modells nichts schiefgelaufen ist.

Die offizielle Dokumentation sagt das ausdrücklich: Anweisungsdateien werden als Kontext behandelt, nicht als durchgesetzte Konfiguration. Um eine Aktion unabhängig von der Entscheidung des Modells zu blockieren, benötigen Sie einen Hook und keinen Satz. Merken Sie sich diese Aussage. Die meisten Lösungen am Ende dieses Beitrags wenden sie auf einen konkreten Fall an.

Welche Anweisungsdateien geladen werden und wann

Claude Code durchläuft den Verzeichnisbaum von dem Verzeichnis aus, in dem Sie das Programm gestartet haben, nach oben. Jede CLAUDE.md und CLAUDE.local.md vom Dateisystemstamm bis zu Ihrem Arbeitsverzeichnis wird beim Start vollständig geladen. Die Dateien werden in dieser Reihenfolge zusammengeführt. Die Datei, die dem Startverzeichnis am nächsten liegt, wird zuletzt gelesen. Innerhalb eines Verzeichnisses wird die Datei .local nach der Hauptdatei angehängt.

Dateien in Unterverzeichnissen unterhalb Ihres Arbeitsverzeichnisses verhalten sich anders. Sie werden beim Start nicht geladen. Sie werden geladen, wenn der Agent eine Datei in diesem Verzeichnis liest. Dasselbe gilt für pfadbezogene Regeln in .claude/rules/ mit einem paths:-Frontmatter-Feld. Sie werden in den Kontext aufgenommen, wenn eine passende Datei gelesen wird, nicht bei jedem Turn.

Dieser Unterschied erklärt einen großen Teil der gemeldeten Fehler. Sie legen eine Regel in packages/api/CLAUDE.md ab, stellen eine Frage zur API, und der Agent antwortet, ohne jemals eine Datei unter packages/api/ zu öffnen. Die Regel wurde nicht ignoriert. Sie war nie im Kontext vorhanden. Wenn Ihr Repository die Anweisungen über Anweisungsdateien pro Paket in einem Monorepo verteilt, sollten Sie dies jedes Mal zuerst prüfen.

Es gibt noch eine weitere Falle beim Laden. Sie ist die häufigste Ursache für die Aussage „Der Agent hat meine Anweisungen ignoriert“: Claude Code liest CLAUDE.md, nicht AGENTS.md. Ein Repository, das sich auf AGENTS.md standardisiert hat und keine CLAUDE.md besitzt, stellt Claude Code überhaupt nichts zum Laden bereit. Die unterstützte Überbrückung ist eine CLAUDE.md, deren erste Zeile @AGENTS.md lautet. Sie bindet die Datei beim Start ein. Darunter können Sie Claude-spezifische Hinweise ergänzen. Ein Symlink funktioniert ebenfalls, wenn Sie nichts weiter hinzufügen müssen. Welche Inhalte überhaupt in diese Datei gehören, ist eine separate Frage. Sie wird unter Trennung von Agentenanweisungen und menschlicher Dokumentation behandelt.

Bestätigen Sie, dass die Datei geladen wurde, bevor Sie sie umformulieren

Ändern Sie den Wortlaut erst, wenn Sie nachgewiesen haben, dass der Agent die Datei sehen kann. Es gibt zwei Prüfungen. Beginnen Sie mit der kostengünstigen.

Führen Sie /context innerhalb der Sitzung aus. Der Befehl gibt das aktuelle Fenster nach Kategorien aufgeschlüsselt aus. Die Liste Memory files enthält die Namen aller Anweisungsdateien, die tatsächlich geladen wurden. Fehlt eine Datei in dieser Liste, befindet sie sich nicht in der Konversation. Dann kann nichts, was Sie in diese Datei schreiben, Wirkung haben. /memory listet die Dateipfade auf und öffnet die Dateien zur Bearbeitung, auch Dateien, die noch nicht existieren.

Für eine belastbarere Prüfung protokollieren Sie die Ladevorgänge. Das Hook-Ereignis InstructionsLoaded wird jedes Mal ausgelöst, wenn ein CLAUDE.md oder eine Regeldatei in den Kontext gelangt. Sein Matcher zeigt den Grund für das Laden an: session_start, nested_traversal, path_glob_match, include oder compact. Fügen Sie dies in .claude/settings.json ein:

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "nested_traversal",
        "hooks": [
          {
            "type": "command",
            "command": "cat >> /tmp/instructions-loaded.log"
          }
        ]
      }
    ]
  }
}

Das Hook empfängt seine Nutzdaten als JSON über die Standardeingabe. Daher hängt cat den vollständigen Datensatz an. Überwachen Sie ihn während der Arbeit mit tail -f /tmp/instructions-loaded.log. Der Exit-Status dieses Ereignisses wird ignoriert. Das Hook kann daher nur beobachten, aber nichts blockieren. Wenn Ihre verschachtelte Datei während einer Sitzung, in der Sie ihr Laden erwarten, nie in diesem Protokoll erscheint, beenden Sie die Umformulierung. Das Problem liegt an der Platzierung.

Was eine lange Sitzung mit Ihren Regeln macht

Hier wirken zwei getrennte Effekte. Sie erfordern unterschiedliche Maßnahmen.

Abstand. Eine Regel, die in Turn 1 festgelegt wurde, befindet sich in Turn 90 noch im Kontextfenster. Dort konkurriert sie mit 90 Textabschnitten, die neuer und für Ihre aktuelle Aufgabe spezifischer sind. Sie können das nicht durch Konfiguration verhindern, aber Sie können es messen. Führen Sie dieselbe Aufgabe in einer neuen Sitzung aus. Wenn die Regel dort eingehalten wird, aber im späteren Verlauf einer langen Sitzung nicht mehr, ist der Abstand die Ursache.

Komprimierung. Wenn das Kontextfenster voll ist, fasst das Harness die bisherige Unterhaltung zusammen und arbeitet mit dieser Zusammenfassung weiter. Erhalten bleibt, was der Zusammenfassungsprozess als wichtig eingestuft hat. Das entspricht nicht unbedingt dem, was Sie für wichtig halten. Claude Code dokumentiert das Verhalten für die einzelnen Mechanismen. Die Unterschiede sind erheblich. Die Projektwurzel CLAUDE.md und Regeln ohne Bereichseinschränkung werden nach einer Komprimierung erneut von der Festplatte geladen. Der automatische Speicher wird ebenfalls erneut von der Festplatte geladen. Regeln mit paths:-Frontmatter gehen verloren, bis wieder eine passende Datei gelesen wird. Verschachtelte CLAUDE.md-Dateien in Unterverzeichnissen gehen verloren, bis wieder eine Datei in diesem Unterverzeichnis gelesen wird.

Ordnen Sie Ihre Anweisungen anhand dieser Tabelle. Daraus ergibt sich die Reihenfolge ihrer Anfälligkeit. Eine Regel, die Sie nur in den Chat eingegeben haben, ist das anfälligste Element der Sitzung. Sie bleibt nur erhalten, wenn die Zusammenfassung sie zufällig übernimmt. Eine Regel in packages/api/CLAUDE.md folgt an zweiter Stelle. Sie wurde einmal geladen, aus der Zusammenfassung entfernt und kehrt erst beim nächsten Lesen in diesem Verzeichnis zurück. Eine Regel in der Datei der Projektwurzel ist am beständigsten, weil sie jedes Mal erneut von der Festplatte gelesen wird.

Wenn eine Anweisung während der gesamten Sitzung gelten muss, gehört sie ohne paths:-Frontmatter in die Datei der Projektwurzel. Alles andere ist ein Kompromiss, den Sie bewusst eingehen sollten. Verwalten der Inhalte im Kontextfenster behandelt /compact mit einem Fokusargument und /clear zwischen voneinander unabhängigen Aufgaben. Beides beeinflusst, wie oft der Zusammenfassungsprozess darüber entscheidet, welche Ihrer Regeln erhalten bleiben.

Warum der umgebende Code die Regel überstimmt

Das ist der Fehler, den Menschen am häufigsten beschreiben und am seltensten diagnostizieren. Ihre Datei sagt, dass der Datenbankzugriff über die Repository-Schicht erfolgt. Der Agent schreibt einen Handler, der das ORM (Object-Relational Mapper) direkt aufruft. Sie wurden nicht aus stilistischen Gründen ignoriert. Die Belege haben sich gegen Sie durchgesetzt.

Eine Regel beschreibt eine Präferenz. Der Code demonstriert eine davon. Wenn der Agent drei Dateien in dem Modul öffnet, das er bearbeiten soll, und alle drei das ORM direkt aufrufen, stehen auf der einen Seite ein abstrakter Satz und auf der anderen Seite drei konkrete, aktuelle und zur Aufgabe passende Beispiele. Das lokale Muster zu übernehmen, ist normalerweise das richtige Verhalten. Hier ist es nur deshalb falsch, weil Sie etwas wissen, das im Kontext nicht steht: Diese Dateien sind veraltet.

Schreiben Sie das daher in die Regel. Regeln, die ihre eigenen Gegenbelege benennen, bewähren sich in einem echten Repository. Regeln, die nur eine Präferenz formulieren, tun das nicht.

Neuer Datenbankzugriff erfolgt über app/repositories/. Dateien unter app/legacy/ rufen das ORM weiterhin direkt auf. Das ist alter Code und nicht das gewünschte Muster. Kopieren Sie ihn nicht.

Der zweite Satz erfüllt die eigentliche Aufgabe. Er teilt dem Agenten mit, was er gleich vorfinden wird und wie er es einordnen soll, bevor er es sieht. Die gleiche Korrektur gilt für jede Regel, der Ihr Repository sichtbar widerspricht: einen Commit-Stil, den Ihre Historie nicht verwendet, eine Teststruktur, die die Hälfte Ihrer Tests ignoriert, oder eine Import-Konvention, die nur im neuen Code gilt. Wenn der Code der Datei widerspricht, benennen Sie diesen Widerspruch in der Datei.

Eine vage Regel kann nicht geprüft und deshalb nicht befolgt werden

"Schreiben Sie sauberen Code." "Vermeiden Sie unnötige Komplexität." "Halten Sie es einfach." "Gehen Sie bei Migrationen sorgfältig vor." Keine dieser Regeln lässt sich anhand einer konkreten Aktion prüfen, weder durch den Agenten noch durch Sie. Ein Agent, der eine Regel nicht anhand seiner eigenen Ausgabe prüfen kann, rät. Sie bewerten dieses Raten nach Gefühl.

Wenden Sie auf jede Zeile Ihrer Datei den folgenden Test an. Schreiben Sie den Shell-Befehl, der mit einem Exit-Code ungleich null beendet wird, wenn die Regel verletzt ist. Wenn Sie diesen Befehl nicht schreiben können, ist die Regel nicht prüfbar. Vergleichen Sie diese Paare:

• Nicht prüfbar: "Halten Sie Funktionen klein." Prüfbar: "Eine Funktion mit mehr als 60 Zeilen benötigt darüber einen Kommentar, der erklärt, warum sie so lang ist."
• Nicht prüfbar: "Testen Sie Ihre Änderungen." Prüfbar: "Führen Sie npm test aus und fügen Sie die Anzahl der Fehler ein, bevor Sie eine Aufgabe als abgeschlossen markieren."
• Nicht prüfbar: "Halten Sie die Dateien organisiert." Prüfbar: "HTTP-Handler liegen in src/api/handlers/. In diesem Verzeichnis darf sich nichts anderes befinden."
• Nicht prüfbar: "Formatieren Sie den Code korrekt." Prüfbar: "Verwenden Sie in Dateien unter .ts eine Einrückung mit 2 Leerzeichen."

"Vermeiden Sie unnötige Komplexität" geben Menschen als Erstes auf, weil die Korrektur nicht in einem kürzeren Satz besteht, sondern in einem längeren: Wenn Sie ausdrücklich festlegen, was die kleinste funktionierende Änderung bedeutet, erhält der Agent Kriterien, an denen er seinen eigenen Diff messen kann.

Größe ist dasselbe Problem unter einem anderen Namen. Die Empfehlungen von Claude Code zielen auf weniger als 200 Zeilen pro Anweisungsdatei ab und stellen direkt fest, dass längere Dateien die Befolgung verringern. Eine Datei mit 700 Zeilen enthält keine verbindlichere Anweisung. Sie enthält 700 Aussagen mit mehr Möglichkeiten für Widersprüche und wird bei jeder einzelnen Runde auf Ihr Kontextfenster angerechnet, was sich direkt in Ihrem Token-Verbrauch zeigt. Wenn Sie die Datei so strukturieren, dass jede Regel unter einer Überschrift steht, die ein Leser schnell erfassen kann, wird dies in Schreiben einer Anweisungsdatei, die ein Agent ausführen kann behandelt. Noch besser ist es, die beschreibenden Teile zu entfernen, die keine Anweisungen enthalten: Eine Übersicht der Verzeichnisse, in der die Speicherorte der Handler und Modelle beschrieben werden, ist eine Struktur, die der Agent bei Bedarf in einer geparsten Repository-Übersicht nachschlagen kann, statt sie in jeder Runde im Kontextfenster mitzuführen.

So diagnostizieren Sie das Problem in zehn Minuten

Führen Sie diese Schritte in der angegebenen Reihenfolge aus. Wer direkt zum letzten Schritt springt, endet oft mit einer langen Datei voller nachdrücklicher Regeln, die trotzdem nicht funktionieren.

1. Prüfen Sie, ob die Regel geladen wurde. Führen Sie /context aus und lesen Sie die Liste der Memory files. Wenn die Datei dort nicht aufgeführt ist, korrigieren Sie den Speicherort und beenden Sie die Diagnose. Die übrigen Schritte sind dann noch nicht relevant.
2. Reproduzieren Sie das Problem in einer neuen Sitzung. Starten Sie eine neue Sitzung und stellen Sie die kleinste Aufgabe, die die Regel auslösen sollte. Funktioniert die Regel dort, aber nicht in einer langen Sitzung, deutet das auf die Sitzungsdistanz oder eine Komprimierung hin. Tritt der Fehler auch dort auf, liegt das Problem in der Regel selbst.
3. Entfernen Sie konkurrierende Vorgaben. Fordern Sie dieselbe Änderung in einem Verzeichnis an, dessen vorhandener Code der Regel bereits folgt. Wird die Regel dort wieder eingehalten, haben die umgebenden Codevorgaben Ihre Formulierung überstimmt.
4. Suchen Sie nach einem Konflikt. Wenn zwei Dateien unterschiedliche Vorgaben für dasselbe Verhalten enthalten, ist das ein dokumentierter Fehler. Das Modell kann dann beliebig eine der Vorgaben auswählen. Es teilt Ihnen nicht mit, dass dies geschehen ist.
5. Formulieren Sie die Regel prüfbar und testen Sie erneut. Schreiben Sie die Regel mit einem konkreten Pfad und einer Bedingung neu. Ein deutlicher Anstieg bei der Einhaltung zeigt, dass die Formulierung die Ursache war.

Schritt 4 besteht aus einem Befehl. Durchsuchen Sie alle Quellen für Vorgaben nach dem Thema, nicht nur die Datei, die Sie gerade bearbeitet haben:

grep -rni "migration" --include="CLAUDE.md" --include="CLAUDE.local.md" .
grep -rni "migration" .claude/rules/ ~/.claude/CLAUDE.md ~/.claude/rules/ 2>/dev/null

Ein Treffer in zwei Dateien mit unterschiedlichen Vorgaben ist der Fehler. Löschen Sie eine der beiden Vorgaben. Versuchen Sie nicht, sie mit einer stärkeren Formulierung zu priorisieren, weil es keine Priorisierungslogik gibt, auf die Sie sich berufen können.

Die wirksamsten Maßnahmen in der richtigen Reihenfolge

Jeder folgende Schritt hat eine größere Wirkung als der vorherige und ist aufwendiger einzurichten. Beginnen Sie oben, wenn sich eine Regel mit geringem Aufwand umformulieren lässt. Gehen Sie zum nächsten Schritt über, sobald eine Regel so wichtig ist, dass gelegentliche Ausnahmen nicht akzeptabel sind.

1. Formulieren Sie die Regel konkret. Nennen Sie einen Pfad, einen Befehl oder eine Bedingung. Fügen Sie die Gegenbelege hinzu, die der Agent im Repository finden wird, wie zuvor gezeigt. Das kostet nichts und behebt überraschend viele Fälle.
2. Platzieren Sie die Regel näher an dem, was sie steuert. Verwenden Sie ein verschachteltes CLAUDE.md, eine auf einen Pfad begrenzte Regel in .claude/rules/ oder einen Kommentar am Anfang der Datei selbst. Die Regel wird dann beim selben Lesevorgang wie der Code geladen, für den sie gilt. Akzeptieren Sie den Nachteil: Alles, was auf diese Weise geladen wird, fällt bei der nächsten Komprimierung aus dem Kontext und kehrt beim nächsten passenden Lesevorgang zurück.
3. Verlagern Sie die Durchsetzung in einen Hook. Prosa bittet. Ein Hook entscheidet. Hooks werden bei festgelegten Ereignissen im Lebenszyklus als Code ausgeführt und greifen unabhängig davon, zu welchem Schluss das Modell kommt.
4. Übergeben Sie die Regel an ein deterministisches Tool und entfernen Sie die Prosa. Formatierung, Reihenfolge von Imports, Zeilenlänge, verbotene Imports, das Format von Commit-Nachrichten. ruff format, prettier --write, eslint, ein pre-commit-Hook. Der Formatter ist jedes Mal korrekt und verbraucht keine Tokens. Der Satz ist meistens korrekt und verbraucht bei jedem Durchlauf Tokens.

Schritt 3 im Detail. Angenommen, der Agent darf Migrationsdateien niemals bearbeiten. Tragen Sie dies in .claude/settings.json ein:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-migrations.sh"
          }
        ]
      }
    ]
  }
}

Und dies in .claude/hooks/guard-migrations.sh:

#!/usr/bin/env bash
set -euo pipefail

path=$(jq -r '.tool_input.file_path // empty')

case "$path" in
  */migrations/*)
    echo "Files under migrations/ are written by hand. Stop and ask first." >&2
    exit 2
    ;;
esac

exit 0

Führen Sie chmod +x .claude/hooks/guard-migrations.sh aus. Starten Sie anschließend eine neue Sitzung und bitten Sie den Agenten, eine Datei unter migrations/ zu bearbeiten. Die Bearbeitung wird verweigert, und Ihre Nachricht wird als Begründung zurückgegeben. Der Exit-Status 2 von PreToolUse blockiert den Tool-Aufruf, bevor er ausgeführt wird. Ihr stderr-Text wird dem Modell als Blockierungsnachricht übergeben. ${CLAUDE_PROJECT_DIR} wird zum Projektstammverzeichnis aufgelöst. Dadurch funktioniert der Hook unabhängig davon, in welchem Verzeichnis sich der Agent befindet. Der Agent muss der Regel nicht zustimmen, sich an sie erinnern oder sie noch im Kontext haben. Die Bearbeitung findet nicht statt.

Für ein pauschales Verbot ohne darin enthaltene Logik erledigt permissions.deny in Ihren Einstellungen dieselbe Aufgabe, ohne dass ein zu wartendes Script erforderlich ist. Die Berechtigungsmodi legen fest, was ohne Ihre vorherige Zustimmung ausgeführt wird. Wenn eine Anweisung tatsächlich auf der System-Prompt-Ebene statt in einer Benutzernachricht stehen muss, platziert --append-system-prompt sie dort. Sie muss jedoch bei jedem Aufruf übergeben werden, weshalb sie sich eher für Scripts als für interaktive Arbeit eignet.

Was Sie nicht wegweisen können

Machen Sie klar, welcher Teil in Ihrer Verantwortung liegt. Platzierung, Formulierung, Konflikte zwischen Dateien und Dateigröße sind Probleme des Autors und lassen sich vom Autor beheben. Der Rest ist Modellverhalten. Eine bessere Formulierung wird es nicht beseitigen.

Zustimmung ist keine Befolgung. Ein Agent wird eine Regel bestätigen, sie korrekt wiederholen und sie zwei Tool-Aufrufe später brechen. Die Bestätigung kostet nichts und sagt nichts voraus. Betrachten Sie sie nicht als Behebung und zählen Sie sie nicht als Test.

Manche Gewohnheiten bleiben bestehen. Kommentare hinzufügen, defensive Fehlerbehandlung ergänzen, eine abschließende Zusammenfassung schreiben, den naheliegenden nächsten Befehl ausführen. Diese Verhaltensweisen treten unter einer Regel, die sie verbietet, weiterhin auf, nur seltener statt gar nicht. Sie können Ihre eigene Rate messen: Führen Sie dieselbe Aufgabe zehnmal in frischen Sitzungen aus und zählen Sie die Verstöße. Wenn diese Zahl 0 sein muss, gehört die Regel nicht in den Prompt. Eine Aufgabe als abgeschlossen zu bezeichnen, obwohl ein Teil noch unerledigt ist, hat dieselbe Ursache. Die Behebung ist strukturell und nicht sprachlich: Das unlazy skill ersetzt den Satz durch einen Depth Tree und Gate-Dateien, die der Agent abarbeiten muss, bevor er die Aufgabe als abgeschlossen bezeichnen darf.

Ihre eigene Sitzung wird zu einem Beispiel. Wenn der Agent in Turn 12 gegen die Regel verstößt und Sie das zulassen, befindet sich dieser Verstoß nun als Demonstration im Kontext und ist deutlich aktueller als die Regel. Korrigieren Sie einen Verstoß sofort, sobald Sie ihn sehen. Ein unkorrigierter Verstoß beeinflusst den restlichen Verlauf der Sitzung.

Eine Anweisungsdatei ist keine Sicherheitsgrenze. Sie beeinflusst das Verhalten, setzt es aber nicht durch. Alles, bei dem ein Fehler kostspielig ist, etwa Zugangsdaten oder destruktive Befehle, gehört in Berechtigungen oder einen Hook. Halten Sie Geheimnisse außerhalb der Reichweite eines Agenten wendet dasselbe Prinzip auf Daten an: Bitten Sie einen Agenten nicht, eine Datei nicht zu lesen. Sorgen Sie dafür, dass die Datei nicht lesbar ist.

Die Kurzfassung: Beweisen Sie, dass die Datei geladen wurde, machen Sie die Regel überprüfbar, verschieben Sie sie neben das, was sie steuert, und entfernen Sie sie aus dem Fließtext, wenn die Fehlerquote weiterhin relevant ist. Eine Regel, die ein Agent nicht ignorieren kann, wurde nie vom Agenten verlangt.

FAQ

Warum ignoriert Claude Code meine CLAUDE.md?

Prüfen Sie zunächst, ob die Datei geladen wurde, bevor Sie annehmen, dass sie ignoriert wurde. Führen Sie /context aus und sehen Sie sich die Liste Memory files an. Eine dort nicht aufgeführte Datei ist nicht Teil der Konversation. Anweisungsdateien werden nach der Systemaufforderung als User-Nachricht übermittelt und als Kontext behandelt, nicht als verbindliche Konfiguration. Daher gibt es keine strikte Garantie für ihre Einhaltung. In der Praxis liegt meist eine von vier Ursachen vor: Die Datei befindet sich in einem Unterverzeichnis, aus dem der Agent nie gelesen hat, zwei Dateien widersprechen sich und das Modell hat willkürlich eine ausgewählt, die Regel ist zu ungenau, um eine Aktion daran zu prüfen, oder der umgebende Code zeigt das Gegenteil der Regel.

Ändert das Bearbeiten der Anweisungsdatei während einer Sitzung etwas?

Nicht für die Kopie, die sich bereits in der Konversation befindet. Dateien oberhalb Ihres Arbeitsverzeichnisses werden beim Start vollständig geladen. Der vom Modell gehaltene Text stammt daher vom Zeitpunkt des Starts. Um eine Änderung zu übernehmen, starten Sie eine neue Sitzung oder bitten Sie den Agenten, die Datei mit seinen normalen Dateiverwaltungswerkzeugen zu lesen. Dadurch wird die aktuelle Version als neue Nachricht in die Konversation eingefügt. Nach einer Komprimierung wird die Datei im Projektstamm erneut von der Festplatte gelesen. Auch auf diesem Weg wird dann die neue Version übernommen.

Welche Datei gilt, wenn sich eine CLAUDE.md im Stammverzeichnis und eine verschachtelte Datei widersprechen?

Keine von beiden zuverlässig. Erkannte Dateien werden an den Kontext angehängt, anstatt sich gegenseitig zu überschreiben. Sie werden in der Reihenfolge vom Dateisystemstamm bis zu Ihrem Arbeitsverzeichnis eingelesen. Die nächstgelegene Datei wird daher lediglich zuletzt gelesen. Es gibt keine Prioritätslogik, die Widersprüche auflöst. In der Dokumentation von Claude Code steht, dass widersprüchliche Regeln willkürlich aufgelöst werden können. Schreiben Sie verschachtelte Dateien als Ergänzungen und nennen Sie darin den von ihnen abgedeckten Pfad. Beseitigen Sie den Widerspruch, statt zu versuchen, eine andere Regel zu überstimmen.

Bleiben meine Anweisungen nach /compact erhalten?

Das hängt davon ab, wie sie geladen wurden. Die Datei im Projektstamm CLAUDE.md, Regeln ohne Geltungsbereich und der automatische Speicher werden nach einer Komprimierung von der Festplatte erneut eingefügt. Regeln mit paths:-Frontmatter und verschachtelte CLAUDE.md-Dateien in Unterverzeichnissen gehen verloren, bis wieder eine passende Datei gelesen wird. Alles, was Sie nur in den Chat eingegeben haben, bleibt nur erhalten, wenn der Zusammenfassungsprozess es beibehalten hat. Wenn eine Regel während der gesamten Sitzung gelten muss, legen Sie sie ohne paths:-Frontmatter in der Datei im Projektstamm ab.

Wann sollte eine Regel zu einem Hook statt zu Prosa werden?

Wenn die Prüfung deterministisch ist und die Kosten eines übersehenen Fehlers höher sind als die Kosten für ein kleines Script. Einschränkungen für Dateipfade, erforderliche Befehle vor einem Commit und verbotene Tool-Aufrufe erfüllen diese Bedingung. Ein PreToolUse-Hook, der mit Status 2 beendet wird, blockiert den Tool-Aufruf vollständig und übergibt den Inhalt von stderr als Begründung an das Modell. Die Regel gilt dadurch unabhängig davon, ob sie noch im Kontext vorhanden ist. Alles, was ein Formatter oder ein Linter entscheiden kann, sollte von diesem Tool übernommen und vollständig aus der Anweisungsdatei entfernt werden.