Wann werden CLAUDE.md und AGENTS.md in Unterverzeichnissen geladen? KI im Monorepo an Regeln halten

Mehrere Websites in einem Repository, in jedem Website-Ordner eine Regeldatei für die KI (CLAUDE.md oder AGENTS.md), und die KI befolgt die Regeln der jeweiligen Website – so die naheliegende Annahme. Doch weder Claude Code noch Codex lesen die Regeln in untergeordneten Ordnern „immer“. Startet man im Stammverzeichnis des Repositorys, lädt Claude Code sie erst, wenn es Dateien in diesem Ordner berührt, und Codex lädt sie nicht automatisch (die KI kann sie von sich aus öffnen, garantiert ist das aber nicht). Dieser Artikel vergleicht Punkt für Punkt anhand der offiziellen Dokumentation beider Tools, wann diese Dateien geladen werden und wie man prüft, ob sie geladen wurden, und zeigt dann, wie man Regeln mit automatischen Prüfungen statt mit Dokumenten durchsetzt. Er beruht auf dem, was wir beim Entwurf dieses Aufbaus in einer Umgebung gelernt haben, in der KI-Agenten den Serverbetrieb und mehrere Projekte übernehmen.

Quellen: How Claude remembers your project von Anthropic und Custom instructions with AGENTS.md von OpenAI (beide geprüft am 1. November 2026).

1. Was wir aus Regeln im Ordner jeder Website gelernt haben

In einer Umgebung, in der KI-Agenten den Serverbetrieb und mehrere Websites übernehmen, haben wir einen Aufbau erwogen, bei dem mehrere Websites in einem Repository liegen und die Regeln jeder Website in deren Ordner stehen (Angaben, die Orte oder Namen erkennbar machen würden, sind weggelassen, und die technischen Inhalte sind verallgemeinert). Ziel war eine Arbeitsteilung: Die KI für blog liest nur die Regeln von blog und rührt shop nie an.

Beim Blick in die offizielle Dokumentation beider Tools zeigte sich jedoch, dass nicht garantiert ist, dass die abgelegten Regeln vor Arbeitsbeginn geladen werden. Welche Regeln geladen werden, hängt davon ab, aus welchem Ordner man startet. Hinzu kommt, dass die Dokumentation von Claude Code CLAUDE.md als Kontext beschreibt, nicht als durchgesetzte Konfiguration. Selbst wenn die Regeln geladen sind, garantiert nichts, dass sie befolgt werden.

1. !

   Regeln in Ordnern abzulegen reicht nicht, um Zuständigkeiten zu trennen

   Risiko

   Eine im Stammverzeichnis gestartete KI ändert Dateien, ohne die Regeln dieser Website gelesen zu haben, oder bevor sie sie liest

   Abhilfe

   Die Arbeit an einer Website im Ordner der Website starten und Änderungen außerhalb des Bereichs mit einer Release-Prüfung stoppen (Abschnitt 4)

   Kontrolle

   Mit den Tools prüfen, welche Regeln geladen wurden (Abschnitt 3), und absichtlich etwas außerhalb des Bereichs ändern, um zu sehen, ob das Release stoppt

Die allgemeinen Gründe, warum KI Regeln ignoriert, und was dagegen hilft, behandelt „Warum KI .md-Regeln ignoriert: Laden, Geltungsbereich und Ergebnisse prüfen“. Dieser Artikel konzentriert sich darauf, was passiert, wenn man Regeln auf mehrere Ordner verteilt. Zwei weitere Warnungen aus derselben Umgebung, die sich darauf beziehen, einer KI mehrere Repositorys zu übergeben, stehen in Abschnitt 5.

2. Wann werden Regeln pro Ordner geladen?

Ob die Regeln im Ordner jeder Website geladen werden, hängt davon ab, aus welchem Ordner Sie starten und welches Tool Sie verwenden. Hier steht nebeneinander, was die offizielle Dokumentation beider Tools sagt.

Quellen: How Claude remembers your project und Monorepos and large repos von Anthropic sowie Custom instructions with AGENTS.md von OpenAI (geprüft am 1. November 2026). Die Grenze von Claude Code für untergeordnete Ordner gilt ab v2.1.309. Bei einem Kontext von 1M Tokens liegt sie bei 150.000 Zeichen (200.000 bei Opus 4.6 und Sonnet 4.6). Claude Code liest AGENTS.md ab v2.1.277 direkt; eine AGENTS.md in einem untergeordneten Ordner wird gelesen, wenn dieser Ordner keine CLAUDE.md hat und Claude dort eine Datei mit dem Read-Tool öffnet. Damit beide gelesen werden, stellen Sie in /config Project instructions auf claude-md-and-agents-md.

Der Startordner bestimmt, welche Regeln geladen werden

Selbst im selben Repository hängt das Ergebnis davon ab, wo Sie starten. Starten Sie im Ordner einer Website, lesen beide Tools die Regeln dieser Website von Anfang an.

Leicht zu übersehen ist, was bei „bei Zugriff geladen“ als „Zugriff“ zählt. Als Lesen zählt die Dokumentation von Claude Code das Lesen, Schreiben oder Bearbeiten einer Datei mit seinen Tools sowie Befehle, die eine einzelne Datei anzeigen, etwa cat oder head. Vorgänge, die Dateien auf andere Weise ändern, etwa ein Suchen-und-Ersetzen über die Ordner mehrerer Websites, stehen nicht auf dieser Liste. Die Dateien einer Website können sich also ändern, bevor ihre Regeln gelesen werden.

Wenn Sie Codex im Stammverzeichnis des Repositorys starten und es bitten, „blog und shop zu korrigieren“, wird keine der AGENTS.md der Websites automatisch geladen. Laut Dokumentation beendet Codex die Suche, sobald es das aktuelle Arbeitsverzeichnis erreicht; die Regeln eines untergeordneten Ordners sind beim Start also nur dann sicher enthalten, wenn Sie in diesem Ordner oder darunter starten.

Allerdings weisen die Standardanweisungen (base_instructions/default.md) im Codex-Repository das Modell sinngemäß an, bei Arbeiten unterhalb oder außerhalb des aktuellen Arbeitsverzeichnisses die zutreffenden AGENTS.md zu prüfen. Die KI kann die AGENTS.md einer Website also von sich aus öffnen, doch das ist eine Entscheidung der KI, keine Garantie des Lademechanismus.

Auch Einstellungsdateien pro Ordner werden unterschiedlich vererbt

Über Regeldokumente hinaus unterscheiden sich die Tools auch darin, wie sie Ordner bei Einstellungsdateien wie den Berechtigungen behandeln.

Quellen: Claude Code settings und Monorepos and large repos von Anthropic sowie Config basics von OpenAI (geprüft am 1. November 2026).

3. Prüfen, ob die Regeln geladen wurden

Wenn die Regeln abgelegt sind, prüfen Sie nach dem Start, ob sie tatsächlich geladen wurden. Die Methode unterscheidet sich je nach Tool, und in Claude Code schaut man für beim Start geladene und später geladene Regeln an verschiedenen Stellen nach.

Quellen: der Abschnitt zur Fehlerbehebung in How Claude remembers your project von Anthropic und „Verify your setup“ in Custom instructions with AGENTS.md von OpenAI (geprüft am 1. November 2026). Nehmen Sie den Protokollordner in die .gitignore auf, damit er nicht in Git landet.

Um in Claude Code eine neu hinzugefügte Regeldatei in einem untergeordneten Ordner zu testen, folgen Sie dem Rat der Dokumentation: Legen Sie die Regeldatei in der Shell an, statt sie von der KI schreiben zu lassen, lassen Sie die KI dann eine Datei in diesem Ordner lesen und achten Sie darauf, ob eine Zeile Loaded erscheint.

4. Regeln mit automatischen Prüfungen durchsetzen, nicht mit Dokumenten

Wie Abschnitt 2 gezeigt hat, werden in Ordnern abgelegte Regeln je nach Startordner und Tool womöglich nicht geladen. Und selbst wenn sie geladen sind, garantiert nichts, dass sie befolgt werden. Denken Sie die Durchsetzung deshalb in drei Schichten.

In dieser Umgebung haben wir die unterste Schicht, die Release-Prüfung, zur entscheidenden Absicherung gemacht. Ob man das KI-Tool wechselt oder ein Mensch die Arbeit selbst erledigt: Alles läuft durch dieselbe Prüfung.

Den Bereich jedes Agenten mit einer Einstellung pro Worktree festlegen

Geben Sie jeder Website einen eigenen Worktree (git worktree) und legen Sie oben im Worktree eine kleine Einstellungsdatei (.agent-owner) ab, die die Ordner auflistet, die der dort arbeitende Agent ändern darf. Stünde der Bereich in einem Regeldokument im Repository, wäre er in jedem Worktree gleich und könnte nicht je nach Ort variieren. Halten Sie die Einstellungsdatei aus Git heraus (in .git/info/exclude eintragen) und schreiben Sie sie beim Anlegen des Worktrees.

Beachten Sie: Die KI wird nicht oben im Worktree gestartet, sondern im Website-Ordner darin. Oben im Worktree ist dasselbe wie das Stammverzeichnis des Repositorys; ein Start dort führt zum selben Ergebnis wie „Stammverzeichnis des Repositorys“ in Abschnitt 2.

# Vom Haupt-Checkout (/srv/repo) aus einen Worktree für sites/blog unter /srv/work-blog anlegen
cd /srv/repo
git worktree add /srv/work-blog -b blog-work
printf 'sites/blog/\n' > /srv/work-blog/.agent-owner
echo '.agent-owner' >> .git/info/exclude

# Die KI in sites/blog/ innerhalb des Worktrees starten
cd /srv/work-blog/sites/blog
claude        # oder codex für Codex

# Vor dem Release die Prüfung aus dem Haupt-Checkout oben im Worktree ausführen
cd /srv/work-blog
bash /srv/repo/tools/check-owner.sh origin/main

Führen Sie das Prüfskript aus dem Haupt-Checkout (in dem die KI nicht arbeitet) oder aus der CI aus, nicht die Kopie im Worktree. Führen Sie die Kopie im Worktree aus, käme eine KI, die das Prüfskript selbst umschreibt, glatt durch.

Das Release stoppen, wenn sich außerhalb des Bereichs etwas ändert

Setzen Sie die folgende Prüfung (oben tools/check-owner.sh) an den Anfang des Release-Vorgangs. Sie setzt voraus, dass Releases nur aus Commits erfolgen: Sie stoppt, wenn noch nicht committete Änderungen vorhanden sind, und sie stoppt, wenn der committete Diff gegenüber der Basis (origin/main o. Ä.) auch nur eine Datei außerhalb der zugewiesenen Ordner enthält. Sie liest .agent-owner, also führen Sie sie oben im Worktree aus.

#!/usr/bin/env bash
# Vor dem Release oben im Worktree ausführen: stoppen, wenn sich außerhalb der zugewiesenen Ordner etwas geändert hat
set -euo pipefail

base="${1:-origin/main}"
owner_file=".agent-owner"   # oben im Worktree, außerhalb von Git

if [ ! -s "$owner_file" ]; then
  echo "Keine Bereichsdatei ($owner_file). Release gestoppt" >&2
  exit 1
fi

# Stoppen, wenn nicht committete Änderungen vorhanden sind (Release nur aus Commits)
if [ -n "$(git status --porcelain)" ]; then
  echo "Es gibt nicht committete Änderungen. Release gestoppt" >&2
  exit 1
fi

# --no-renames: ein Verschieben aus einem anderen Ordner als Löschen plus Hinzufügen zählen
# An jeden Bereichseintrag ein / anhängen (damit sites/blog nicht auf sites/blog-old passt)
# Getestet mit gawk (Git Bash). BSD awk kann scheitern, wenn ein -v-Wert Zeilenumbrüche enthält
outside=$(git diff --name-only --no-renames "$base"...HEAD |
  awk -v list="$(tr -d '\r' < "$owner_file")" '
    BEGIN { n = split(list, own, "\n")
            for (i = 1; i <= n; i++) if (own[i] != "" && substr(own[i], length(own[i])) != "/") own[i] = own[i] "/" }
    { ok = 0; for (i = 1; i <= n; i++) if (own[i] != "" && index($0, own[i]) == 1) ok = 1
      if (!ok) print }')

if [ -n "$outside" ]; then
  echo "Dateien außerhalb des Bereichs wurden geändert. Release gestoppt:" >&2
  echo "$outside" >&2
  exit 1
fi
echo "Nur Änderungen innerhalb des Bereichs"

Dies sind die Ergebnisse, als Claude Code, das diesen Artikel geschrieben hat, am 1. November 2026 ein Test-Repository mit zwei Websites und einem gemeinsamen Ordner aufgebaut und die Prüfung mit Git 2.56 (Git Bash unter Windows) ausgeführt hat.

Dass Verschiebungen nicht durchrutschen, verhindert --no-renames. Ohne diese Option führt Git eine Änderung, die es als Verschiebung wertet, nur unter dem Zielnamen auf, sodass eine Änderung, die Dateien von einer anderen Website herüberholt, unbemerkt bleibt. Außerdem „stoppt“ die Prüfung, statt „durchzulaufen“, wenn die Einstellungsdatei fehlt, damit ein Worktree, dessen Bereich nie festgelegt wurde, nicht durchkommt.

Tool-Sperren ergänzen

Wer erst vor dem Release stoppt, merkt es erst, nachdem die KI bereits etwas außerhalb des Bereichs umgeschrieben hat. Um sie vor dem Schreiben zu stoppen, nutzen Sie zusätzlich die Funktionen der Tools selbst.

Quellen: Configure permissions und Hooks guide von Anthropic sowie Hooks und Rules von OpenAI (geprüft am 1. November 2026).

In Claude Code sehen Einstellungen, die den Worktree für blog daran hindern, die Bereichsdatei (.agent-owner), die Prüfskripte (tools/), die Regeln im Stammverzeichnis, shop und den gemeinsamen Ordner zu ändern, so aus (angenommen, der Worktree liegt unter /srv/work-blog). Pfade, die mit // beginnen, sind absolute Pfade. Da die Orte der Worktrees von Rechner zu Rechner verschieden sind, tragen Sie diese beim Anlegen des Worktrees in die Benutzereinstellungen des jeweiligen Rechners (~/.claude/settings.json) ein, nicht in die im Repository eingecheckten Einstellungen.

{
  "permissions": {
    "deny": [
      "Edit(//srv/work-blog/.agent-owner)",
      "Edit(//srv/work-blog/tools/**)",
      "Edit(//srv/work-blog/CLAUDE.md)",
      "Edit(//srv/work-blog/AGENTS.md)",
      "Edit(//srv/work-blog/sites/shop/**)",
      "Edit(//srv/work-blog/sites/shared/**)",
      "Edit(//srv/repo/**)"
    ]
  }
}

In Codex registrieren Sie das Prüfskript in der Hook-Konfiguration (Ihre persönliche ~/.codex/hooks.json, die .codex/hooks.json des Repositorys o. Ä.) unter PreToolUse, mit apply_patch als Matcher. Hooks laufen erst, wenn Sie sie in Codex mit /hooks geprüft und ihnen vertraut haben (nach einer Änderung muss ihnen erneut vertraut werden).

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "^apply_patch$",
        "hooks": [ { "type": "command", "command": "python3 ~/.codex/hooks/owner_guard.py" } ] }
    ]
  }
}

Das Prüfskript entnimmt die Zielpfade den Zeilen *** Add File:, *** Update File:, *** Delete File: und *** Move to: der Eingabe von apply_patch und gibt deny zurück, wenn einer davon außerhalb des Bereichs liegt oder geschützt ist. Hier ein Minimalbeispiel.

import json, posixpath, re, sys

# PreToolUse-Hook für Codex: apply_patch stoppen, wenn es Dateien außerhalb des Bereichs oder geschützte Dateien ändert
OWN = ["/srv/work-blog/sites/blog/"]                  # Bereich (mit abschließendem /)
PROTECT = ["/srv/work-blog/.agent-owner", "/srv/work-blog/tools/"]

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if isinstance(command, list):
    command = "\n".join(command)

bad = []
for m in re.finditer(r"^\*\*\* (?:Add File|Update File|Delete File|Move to): (.+)$", command, re.M):
    path = posixpath.normpath(posixpath.join(event.get("cwd", ""), m.group(1).strip()))
    if not any(path.startswith(o) for o in OWN) or any(path.startswith(p) for p in PROTECT):
        bad.append(path)

if bad:
    print(json.dumps({"hookSpecificOutput": {
        "hookEventName": "PreToolUse",
        "permissionDecision": "deny",
        "permissionDecisionReason": "Dateien außerhalb des Bereichs: " + ", ".join(bad)}}, ensure_ascii=False))

Claude Code, das diesen Artikel geschrieben hat, hat dieses Skript mit von Hand erstellten Eingaben im Format, das Codex übergibt (innerhalb des Bereichs, shop, .agent-owner, ein Verschieben nach shared und ein Löschen unter tools/), ausgeführt und bestätigt, dass nur die Änderung innerhalb des Bereichs durchlief. In Codex selbst haben wir es nicht ausgeführt.

Bash-Befehle lassen sich auf viele Arten schreiben, daher kann ein Hook nicht vollständig bestimmen, wohin sie schreiben. OpenAI selbst nennt Hooks „a useful guardrail, not a complete enforcement boundary“ (eine nützliche Leitplanke, keine vollständige Durchsetzungsgrenze). Sperren Sie Befehle, die Sie stoppen wollen, etwa rm, mit einer Regel mit decision = "forbidden", und überlassen Sie den Rest der Release-Prüfung. Regeln gehören in den Ordner rules/ einer Konfigurationsebene, etwa ~/.codex/rules/default.rules. Das .codex/rules/ eines Projekts wird nur gelesen, wenn dem Projekt vertraut wird.

Tool-Sperren müssen für jedes Tool neu geschrieben werden, und je nach Startordner und Vertrauenseinstellungen greifen sie womöglich nicht. Bauen Sie deshalb auf der Release-Prüfung auf, die jede Änderung am Ende passieren muss, und legen Sie Tool-Sperren darüber, um Probleme früher abzufangen. Wie man Hooks für Claude Code schreibt, steht in „Was sind Claude Code Hooks?“; zu schreibgeschützten Einstellungen siehe „Codex und Claude Code schreibgeschützt nutzen“.

5. Ebenfalls beachten: verwechselte Repositorys und Umgebungsvariablen

In derselben Umgebung ist zweierlei passiert, als einer KI mehrere Repositorys übergeben wurden. Beides wurde bemerkt, bevor daraus ein ernster Vorfall wurde, doch unabhängig davon, wie Sie die Regeln ablegen, sollten Sie dafür Abläufe festlegen.

Repositorys mit ähnlichen Namen an der Remote-URL unterscheiden

Eine KI hielt das Repository eines anderen Dienstes mit sehr ähnlichem Namen für „eine alte Kopie desselben Dienstes“ und verschob es an einen anderen Ort (es wurde sofort mit unverändertem Inhalt zurückgeholt). Ihre Begründung lautete „keine lokalen Änderungen, und die letzte Aktualisierung ist alt“, doch das zeigt nur, dass „nichts mitten in einer Änderung steckt“ und „niemand es in letzter Zeit bearbeitet hat“. Je stabiler ein Dienst läuft, desto seltener wird er aktualisiert.

Bevor Sie etwas verschieben oder löschen, führen Sie Folgendes im Zielordner und im produktiv genutzten Ordner aus und vergleichen die Ergebnisse nebeneinander.

# Remote-URL (in der URL eingebettete Tokens oder Passwörter vor der Anzeige entfernen)
git -C <Ordner> remote get-url origin | sed -E 's#://[^/@]+@#://#'

# Zuerst prüfen, dass es kein Shallow Clone ist (bei true ist das nächste Ergebnis unzuverlässig)
git -C <Ordner> rev-parse --is-shallow-repository

# Root-Commit (Kopien aus derselben Historie teilen ihn)
git -C <Ordner> rev-list --max-parents=0 HEAD

• Remote-URLs nach Host und Repository-Pfad vergleichen: https://github.com/org/app.git und git@github.com:org/app.git sind dasselbe Repository, nur anders geschrieben; umgekehrt kann dasselbe Repository bei Mirrors oder Host-Aliassen verschieden aussehen
• In einem Shallow Clone ist der Root-Commit nicht der echte erste Commit: In einem mit --depth 1 geholten Clone erhält man den ältesten geholten Commit (in unserem Test HEAD selbst)
• In der URL eingebettete Tokens nicht anzeigen: Eine Remote-URL kann ein Authentifizierungs-Token enthalten, und wer sie unverändert ausgibt, lässt ein Geheimnis in die Ausgabe durchsickern – genau wie bei den Umgebungsvariablen unten

Selbst wenn der Vergleich zeigt, dass es sich um „eine ungenutzte Kopie“ handelt, löschen Sie sie nicht sofort, sondern verschieben Sie sie zuerst an einen anderen Ort. Notieren Sie, wohin sie kam, wo sie lag und mit welchem Befehl man sie zurückholt, und löschen Sie sie erst, nachdem Sie eine Weile bestätigt haben, dass nichts kaputtgegangen ist. In dieser Umgebung ließ sich die Verwechslung gerade deshalb sofort rückgängig machen, weil der Ordner verschoben und nicht gelöscht worden war.

Bei Umgebungsvariablen nur die Namen ansehen

Eine KI führte einen Befehl zur Prüfung der Konfiguration eines Containers aus, der die Umgebungsvariablen samt Werten ausgab, und in der Ausgabe erschien ein Datenbank-Verbindungsstring (einschließlich Passwort). Sobald ein Wert in der Ausgabe erscheint, bleibt er im Gesprächsverlauf und wird auch an das Modell gesendet. Wenn Sie nur sehen wollen, was gesetzt ist, genügen die Namen.

docker inspect <Container>
docker exec <Container> printenv
docker exec <Container> sh -c 'env | cut -d= -f1'

docker inspect --format '{{range .Config.Env}}{{index (split . "=") 0}}{{println}}{{end}}' <Container>
docker exec <Container> awk 'BEGIN{for(k in ENVIRON) print k}'

docker compose config

docker compose config --no-interpolate

env
printenv
Get-ChildItem Env:

compgen -e                  # bash
(Get-ChildItem Env:).Name   # PowerShell

Dies sind die Ergebnisse, als Claude Code, das diesen Artikel geschrieben hat, am 1. November 2026 mit Dummy-Werten unter Docker 29.8 und Docker Compose v5.6 getestet hat. In einem Container mit einem Wert, der Zeilenumbrüche enthielt (die Form, in der man den Inhalt einer Schlüsseldatei übergibt), gab env | cut -d= -f1 die zweite und dritte Zeile des Werts unverändert aus, vermischt mit den Variablennamen. ENVIRON von awk und docker inspect --format zeigten die Werte nicht. docker compose config zeigte die in .env und env_file eingetragenen Dummy-Werte an; mit --no-interpolate erschien keiner davon, und nur der direkt in compose.yaml eingetragene Wert wurde angezeigt.

Zur Sicherheit schreiben Sie „bei Umgebungsvariablen nur die Namen ansehen“ in die Regeldokumente und sperren außerdem die Befehle, die Werte ausgeben, mit den Tool-Sperren aus Abschnitt 4. Wird dennoch ein Wert ausgegeben, behandeln Sie ihn als „gesehen“ und entscheiden, ob er ausgetauscht werden muss. Eine Codex-Einstellung, die verhindert, dass Umgebungsvariablen überhaupt an die Befehle der KI weitergegeben werden, beschreibt Abschnitt 6 von „Codex von geheimen Dateien fernhalten“.

6. Checkliste vor der Übergabe der Arbeit

• Festgelegt, dass die KI für die Arbeit an einer Website im Website-Ordner innerhalb des Worktrees gestartet wird
• Nach dem Start bestätigt, dass die Regeln der Website enthalten sind: Memory files in /context bei Claude Code, die Liste der aktiven Anweisungsdateien bei Codex
• Für im Stammverzeichnis gestartete Arbeit eine Möglichkeit vorbereitet, zu sehen, ob Regeln untergeordneter Ordner während der Sitzung geladen wurden (die Zeile Loaded von Claude Code, der Hook InstructionsLoaded)
• Eine Prüfung ergänzt, die das Release stoppt, wenn sich außerhalb der zugewiesenen Ordner etwas geändert hat, und beobachtet, dass sie bei einer absichtlichen Änderung außerhalb des Bereichs stoppt
• Den Bereich jedes Worktrees mit abschließenden Schrägstrichen geschrieben und dafür gesorgt, dass die Prüfung stoppt, wenn die Bereichsdatei fehlt
• Schreibzugriffe außerhalb des Bereichs und auf die Bereichsdatei mit Tool-Sperren gesperrt
• In die Regeln einen Ablauf geschrieben, vor dem Verschieben oder Löschen eines Ordners Remote-URL und Root-Commit mit der Produktivumgebung zu vergleichen und zu verschieben statt zu löschen
• In die Regeln die Befehle geschrieben, die nur die Namen der Umgebungsvariablen zeigen, und die Befehle, die Werte ausgeben, mit Tool-Sperren gesperrt

## Regeln für die Arbeit mit mehreren Projekten
- Der Bereich dieses Worktrees umfasst nur die in .agent-owner aufgeführten Ordner. Ändere keine Dateien außerhalb
  (Änderungen dort stoppen die Release-Prüfung)
- Vor dem Verschieben oder Löschen eines Ordners git remote get-url origin und
  git rev-list --max-parents=0 HEAD mit der Produktivumgebung vergleichen (auf Shallow Clones achten).
  Verschieben statt löschen und festhalten, wie man es wiederherstellt
- Bei Umgebungsvariablen nur die Namen ansehen. Nicht verwenden: env, printenv, docker inspect (ohne --format),
  docker compose config (ohne --no-interpolate)

Zusammenfassung

FAQ

F. Wird eine CLAUDE.md in einem Unterverzeichnis geladen?

A. Ja, aber nicht beim Start. Claude Code lädt die CLAUDE.md eines Ordners, wenn Claude eine Datei in diesem Ordner liest, schreibt oder bearbeitet. Sie erscheint dann nicht unter Memory files in /context; stattdessen erscheint im Terminal eine Zeile Loaded mit ihrem Pfad. Starten Sie in diesem Ordner, wird sie beim Start geladen und erscheint unter Memory files.

F. Wie bringe ich Codex dazu, eine AGENTS.md in einem Unterverzeichnis zu lesen?

A. Starten Sie Codex in diesem Ordner (in der CLI codex --cd <Ordner>). Beim Start liest Codex die AGENTS.md vom Projektstamm bis zum Startverzeichnis und sucht nicht darunter. Starten Sie im Stammverzeichnis, wird die AGENTS.md eines untergeordneten Ordners gelesen, wenn die KI sie von sich aus öffnet, doch die offizielle Dokumentation nennt keine Einstellung, die sie zuverlässig lädt.

F. Sollte ich in einem Monorepo die Regeldokumente in einer Datei im Stammverzeichnis zusammenfassen?

A. Die Dokumentation beider Tools empfiehlt, Regeln für das ganze Repo ins Stammverzeichnis und websitespezifische Regeln in den Ordner der Website zu legen. Die Regeln einer Website werden jedoch womöglich nicht geladen, wenn Sie nicht in diesem Ordner starten; verlagern Sie daher alles, was Probleme verursachen würde, wenn es ignoriert wird, aus den Dokumenten in die Release-Prüfung oder die Tool-Sperren.

F. Wie bringe ich Claude Code dazu, sowohl CLAUDE.md als auch AGENTS.md zu lesen?

A. Standardmäßig wird AGENTS.md nicht gelesen, wenn im Startverzeichnis oder darüber eine CLAUDE.md, .claude/CLAUDE.md oder CLAUDE.local.md liegt. Importieren Sie sie entweder mit einer einzigen Zeile @AGENTS.md in der CLAUDE.md, oder stellen Sie in /config Project instructions auf claude-md-and-agents-md.

Quellen

• Anthropic: How Claude remembers your project, Monorepos and large repos, Claude Code settings, Configure permissions, Hooks guide
• OpenAI: Custom instructions with AGENTS.md, Config basics, Hooks, Rules, Sandboxing
• Docker: docker inspect, docker compose config