Claude Code und Codex: Projektwissen zwischen Sessions erhalten

Eine neue Session beginnt ohne das letzte Gespräch

Eine neu begonnene Claude-Code-Session startet laut Dokumentation mit einem frischen Kontextfenster. Codex stellt seine Anweisungen laut eigener Dokumentation bei jedem Start neu zusammen. Wer eine neue Session beginnt, statt ein früheres Gespräch fortzusetzen, hat dessen Verlauf also nicht im Kontext. Was dort besprochen, entschieden oder halb erledigt wurde, muss dann aus Projektdateien kommen, die das Werkzeug lädt oder liest. Das gilt erst recht, wenn ein anderes Werkzeug weitermacht: Dessen Gesprächsverlauf ist ohnehin ein anderer.

In einer Auswertung öffentlicher Beiträge auf X aus dem August bis Oktober 2026 kam diese Frage mehrfach vor: Wie trägt man Kontext von einer Agenten-Session in die nächste? Ein Beitrag fragte konkret, wie man ihn zwischen Claude Code und Codex teilt – mit einer gemeinsamen AGENTS.md, mit getrennten Dateien oder indem man alles neu erklärt.

Ich arbeite selbst mit mehreren Agenten-Werkzeugen am selben Bestand, an dieser Website zum Beispiel mit Claude Code und Codex. Dieser Artikel zeigt den Aufbau, der dafür trägt: vier Arten von Projektwissen getrennt ablegen, wissen, welches Werkzeug welche Datei tatsächlich lädt, und den nächsten Schritt so formulieren, dass ein Befehl entscheidet, ob er erledigt ist. Dazu gibt es ein kleines Beispielprojekt zum Herunterladen, an dem sich die Übergabe nachprüfen lässt.

Vier Informationen, vier Orte

Eine Übergabe zwischen Sessions transportiert vier verschiedene Dinge. Sie ändern sich unterschiedlich oft und werden unterschiedlich gelesen. Deshalb gehören sie nicht in dieselbe Datei.

Regeln: kurz, weil sie immer mitgeladen werden

Die Regeldatei landet bei jedem Start im Kontext. Die Claude-Code-Dokumentation empfiehlt, eine CLAUDE.md unter 200 Zeilen zu halten, weil längere Dateien mehr Kontext verbrauchen und schlechter befolgt werden. Codex liest Anweisungen laut Dokumentation nur bis zur Grenze project_doc_max_bytes, standardmäßig 32 KiB. Ob sie pro Datei oder für alle Anweisungsdateien zusammen gilt, beschreiben die AGENTS.md-Anleitung und die Konfigurationsseite (öffnet in neuem Tab) unterschiedlich. Begründungen und Verlauf haben in der Regeldatei deshalb nichts verloren.

Entscheidungen: mit Grund, damit niemand sie versehentlich zurückbaut

Eine Regel sagt, was gilt. Eine Entscheidung erklärt, warum, und schützt so vor einer Session, die eine scheinbar umständliche Lösung „vereinfacht“. Das Entscheidungsprotokoll wird nur ergänzt. Überholte Einträge bleiben stehen und bekommen einen Verweis auf ihren Nachfolger.

Aufgabenstand: überschreiben statt anhängen

Der Stand beschreibt nur die Gegenwart: erledigt, in Arbeit, nicht anfassen. Wer ihn fortschreibt, baut ein Tagebuch, in dem die nächste Session den aktuellen Stand suchen muss. Den Verlauf liefert git.

Nächster Schritt: mit Befehl und erwartetem Ergebnis

„Einwilligungsfilter fertig machen“ lässt offen, wann er fertig ist. „npm test meldet 3 bestandene und 0 fehlgeschlagene Tests“ lässt das nicht offen. Der Prüfbefehl ist außerdem der Teil der Übergabe, der unabhängig vom Werkzeug gleich wirkt. Dazu unten mehr.

Wie Claude Code und Codex Projektdateien laden

Die folgenden Angaben stammen aus der offiziellen Dokumentation beider Werkzeuge, abgerufen am 10. Oktober 2026. Beide Werkzeuge ändern sich schnell. Vor dem Einrichten lohnt ein Blick in die aktuelle Fassung: Claude Code: How Claude remembers your project (öffnet in neuem Tab) und Codex: Custom instructions with AGENTS.md (öffnet in neuem Tab).

Claude Code

• Beim Start lädt Claude Code CLAUDE.md und CLAUDE.local.md aus dem Arbeitsverzeichnis und allen Verzeichnissen darüber. Alle gefundenen Dateien werden aneinandergehängt, von der Wurzel nach unten. Was näher am Startverzeichnis liegt, steht zuletzt im Kontext.
• Dateien in Unterordnern lädt Claude Code erst, wenn es dort eine Datei liest oder bearbeitet. Dazu kommen die persönliche ~/.claude/CLAUDE.md und gegebenenfalls eine zentral verwaltete Datei der Organisation.
• Mit @pfad lassen sich weitere Dateien einbinden, relativ zur einbindenden Datei und höchstens vier Ebenen tief. Eingebundene Dateien werden beim Start mitgeladen und kosten deshalb genauso Kontext.
• Seit Version 2.1.277 liest Claude Code auch AGENTS.md, standardmäßig aber nur, wenn im Arbeitsverzeichnis und darüber keine CLAUDE.md, .claude/CLAUDE.md oder CLAUDE.local.md liegt. Gibt es eine CLAUDE.md, liest Claude nur diese, außer sie bindet @AGENTS.md ein oder die Einstellung „Project instructions“ steht auf beide Dateien.
• AGENTS.override.md, AGENTS.local.md und Dateien unter .agents/ liest Claude Code nicht.
• Welche Dateien geladen wurden, zeigt /context unter „Memory files“.

Codex

• Codex stellt seine Anweisungen bei jedem Start zusammen, in der interaktiven Oberfläche in der Regel einmal pro Session.
• Global liest Codex im Codex-Home (standardmäßig ~/.codex) AGENTS.override.md, falls vorhanden, sonst AGENTS.md.
• Im Projekt geht Codex von der Projektwurzel, meist der Git-Wurzel, bis zum Startverzeichnis. In jedem Ordner prüft es AGENTS.override.md, dann AGENTS.md, dann konfigurierte Ausweichnamen, und nimmt höchstens eine Datei pro Ordner. Unterhalb des Startverzeichnisses sucht es nicht weiter.
• Die Dateien werden von der Wurzel nach unten aneinandergehängt. Spätere, näherliegende Anweisungen gehen früheren vor. Leere Dateien überspringt Codex.
• Andere Dateinamen, etwa CLAUDE.md, liest Codex nur, wenn sie in project_doc_fallback_filenames in der config.toml stehen. Weil pro Ordner nur eine Datei zählt und AGENTS.md zuerst geprüft wird, käme ein solcher Ausweichname nur in Ordnern ohne AGENTS.md zum Zug.
• Eine Einbinde-Syntax wie @pfad beschreibt die Codex-Dokumentation nicht.
• Zum Prüfen schlägt die Dokumentation vor: codex --ask-for-approval never "Summarize the current instructions."

Eine Datei, zwei Durchsetzungen

Eine gemeinsame AGENTS.md ist ein guter Ausgangspunkt. Dass beide Werkzeuge sie gleich behandeln, folgt daraus nicht. Vier Unterschiede aus der Dokumentation:

1. Eine zusätzliche CLAUDE.md blendet die gemeinsame Datei aus. Liegt neben der AGENTS.md eine CLAUDE.md, liest Claude Code standardmäßig nur diese. Ohne die Zeile @AGENTS.md darin kommen die gemeinsamen Regeln bei Claude nicht an, bei Codex schon. Das gilt auch für eine persönliche, nicht eingecheckte CLAUDE.local.md.
2. Override-Dateien sieht nur Codex. Eine AGENTS.override.md ändert, was Codex in diesem Ordner liest. Claude Code ignoriert sie. Im selben Verzeichnis arbeiten die beiden dann nach verschiedenen Regeln.
3. Der Suchbereich ist verschieden. Claude Code lädt Dateien in Unterordnern nach, sobald es dort arbeitet. Codex liest nur den Pfad von der Projektwurzel bis zum Startverzeichnis. Eine Regel in src/AGENTS.md erreicht Codex nur, wenn es in src/ oder darunter gestartet wird.
4. Text ist Kontext, keine Sperre. Die Claude-Code-Dokumentation sagt ausdrücklich, dass CLAUDE.md als Kontext behandelt wird und nicht als erzwungene Konfiguration. Was unabhängig vom Modell blockiert werden soll, gehört dort in Hooks oder Berechtigungen. Die entsprechenden Mechanismen von Codex behandelt dieser Artikel nicht.

Daraus folgen zwei Arbeitsregeln. Erstens pro Werkzeug prüfen, was tatsächlich geladen wurde, statt es anzunehmen. Zweitens das, worauf es ankommt, an einen Prüfbefehl binden. npm test liefert dasselbe Ergebnis, egal welches Werkzeug den Code geändert hat. Im Beispiel unten wird deshalb auch eine Entscheidung durch einen Test abgesichert.

Das Beispielset

Regeln, für alle Werkzeuge

Kurz und werkzeugneutral. Der letzte Abschnitt ist die eigentliche Brücke zwischen den Sessions: Codex lädt docs/stand.md nicht von selbst, also sagt die Regel, dass es zuerst gelesen und geprüft wird.

# warteliste-export – Regeln für Coding-Agenten

Fiktives Beispielprojekt. Diese Datei enthält nur Regeln, die in jeder Session gelten.
Begründungen stehen in `docs/entscheidungen.md`, der Arbeitsstand in `docs/stand.md`.

## Projekt

Kleines Node-Modul ohne Abhängigkeiten. `src/export.js` wandelt
Wartelisten-Einträge in CSV um.

## Befehle

- Tests: `npm test` (eingebauter Test-Runner von Node, kein Build-Schritt)

## Regeln

- Keine npm-Abhängigkeiten hinzufügen.
- CSV-Vertrag aus E-004 erhalten: normale Werte unverändert, riskante
  Zellanfänge mit sichtbarem Apostroph. Andere Konsumenten separat prüfen.
- Jede Verhaltensänderung bekommt zuerst einen Test in `test/`.
- Bestehende Tests nicht abschwächen, um sie grün zu bekommen.
- Nur erfundene Adressen unter `example.com`, keine echten Personendaten.
- Eine Entscheidung aus `docs/entscheidungen.md` nicht stillschweigend ändern.
  Abweichung als neuen Eintrag vorschlagen und nachfragen.

## Zwischen Sessions

- Zu Beginn `docs/stand.md` lesen und den dort genannten Prüfbefehl
  ausführen, bevor du Code änderst.
- Am Ende `docs/stand.md` überschreiben: erledigt, in Arbeit,
  nächster prüfbarer Schritt mit Befehl und erwartetem Ergebnis.

Brücke für Claude Code

Die CLAUDE.md bindet die gemeinsamen Regeln ein und lädt zusätzlich den Arbeitsstand direkt in den Kontext. Ohne die erste Zeile würde Claude die AGENTS.md hier nicht lesen, weil eine CLAUDE.md existiert. Wer nichts Claude-Spezifisches braucht, kann die Datei mit aktuellen Versionen auch weglassen. Dann kommt der Arbeitsstand bei Claude wie bei Codex nur über die Regel an.

@AGENTS.md

## Nur für Claude Code

- Arbeitsstand direkt mitladen: @docs/stand.md

Entscheidungsprotokoll

E-002 enthält ein Detail, das leicht verloren geht: Gefiltert wird vor der Duplikatprüfung. Der fehlschlagende Test prüft genau diesen Fall. Die Entscheidung steht damit nicht nur im Text, sie wird auch gemessen.

# Entscheidungen – warteliste-export

Fiktives Beispielprojekt. Dauerhafte Entscheidungen mit Begründung.
Einträge nicht löschen; überholte als „ersetzt durch E-00x“ markieren.

## E-001 · Keine Abhängigkeiten

- Entscheidung: Nur Node-Bordmittel (`node:test`, `node:assert`).
- Grund: Das Modul soll ohne Installationsschritt laufen und prüfbar bleiben.
- Folge: CSV-Escaping ist selbst geschrieben und durch Tests abgedeckt.

## E-002 · Export nur mit Einwilligung

- Entscheidung: Ein Eintrag erscheint nur im Export, wenn `einwilligung === true`.
- Grund: Der Export ist für Mailings gedacht. Ohne Einwilligung soll niemand angeschrieben werden.
- Folge: Fehlt das Feld, zählt es wie `false`. Gefiltert wird vor der
  Duplikatprüfung (E-003), damit ein Eintrag ohne Einwilligung keinen
  späteren Eintrag mit Einwilligung verdrängt.

## E-003 · E-Mail-Adressen normalisieren

- Entscheidung: Adressen werden getrimmt und kleingeschrieben.
  Nach der Normalisierung gleiche Adressen gelten als Duplikat; der erste Eintrag bleibt.
- Grund: Dieselbe Person soll keine doppelte Mail erhalten.

## E-004 · CSV für einen geprüften Konsumenten (2026-10-13)

- Entscheidung: Ziel ist LibreOffice Calc 26.8.0.3 mit UTF-8, Komma als
  Separator und doppeltem Anführungszeichen als Textbegrenzer.
- Jede Zelle wird nach der bisherigen E-Mail-Normalisierung geprüft. Bei
  `=`, `+`, `-`, `@` (auch nach Leerraum), deren Vollbreitenvarianten
  sowie führendem Tab, CR oder LF wird ein Apostroph vorangestellt.
  Quotes werden verdoppelt; Komma, Quote, CR und LF werden CSV-zitiert.
- Grund: CSV-Quoting allein verhindert Formelauswertung nicht. Die Prüfung
  in Calc umfasst Standardspalten, aktive Formelauswertung und
  Speichern/Wiederöffnen als ODS sowie CSV; keine Textspalten-Voreinstellung.
- Folge: Normale CSV-Werte bleiben unverändert. Riskante Werte bleiben mit
  sichtbarem Apostroph erhalten; dieser ist Teil der Daten, kein unsichtbares
  Escape. Nicht automatisch entfernen. Calc normalisiert CR/CRLF zu LF;
  der direkte CSV-Roundtrip erhält sie dagegen exakt.
- Grenze: Keine universelle CSV-, Excel- oder andere Calc-Versionsfreigabe.
  Andere Konsumenten und Importoptionen zuerst separat prüfen. Für exakte
  Textzelltypen unabhängig vom Import eignet sich ein typisiertes Format.
  E-002 bleibt die absichtlich noch offene Übungsaufgabe.
- Quelle: https://community.owasp.org/attacks/CSV_Injection (13.10.2026).

Arbeitsstand mit nächstem prüfbarem Schritt

Der Schritt nennt Ausgangslage, Änderung und Abnahme jeweils mit Befehl und erwartetem Ergebnis. Er verrät die Lösung fast vollständig. Das ist Absicht: Eine Übergabe soll kein Rätsel sein.

# Arbeitsstand – warteliste-export

Fiktives Beispielprojekt. Diese Datei wird am Ende jeder Session
überschrieben, nicht fortgeschrieben. Den Verlauf zeigt git.

## Erledigt

- `toCsv()` schreibt Kopfzeile und escaped Kommas, Anführungszeichen, CR und LF (E-001).
- E-Mail-Normalisierung und Duplikate (E-003), Tests grün.
- CSV-Neutralisierung für den geprüften Calc-Konsumenten (E-004); vier
  zusätzliche Regressionstests grün. Die drei ursprünglichen Tests sind unverändert.

## In Arbeit

- Einwilligungsfilter (E-002). Der Test „überspringt Einträge ohne Einwilligung“
  ist geschrieben und schlägt absichtlich fehl. Die Implementierung fehlt.

## Nächster prüfbarer Schritt

1. Ausgangslage bestätigen: `npm test`
   Erwartet: 7 Tests, 6 bestanden, 1 fehlgeschlagen –
   „überspringt Einträge ohne Einwilligung“.
2. In `src/export.js` Einträge ohne `einwilligung === true` überspringen,
   und zwar vor der Duplikatprüfung (siehe E-002).
3. Fertig, wenn `npm test` 7 bestandene und 0 fehlgeschlagene Tests meldet
   und `git status --short test/` nichts ausgibt (Tests unverändert).

## Nicht anfassen

- Ob der Export später auch JSON liefern soll, ist nicht entschieden. Nicht vorziehen.

Die Übergabe, nachgeprüft

Geprüft wurde am 10. Oktober 2026 mit Node.js 26.8.2 unter macOS, in Kopien des Beispielprojekts außerhalb dieses Repositorys. Zuerst die Ausgangslage, so wie die nächste Session sie vorfindet:

✔ schreibt Kopfzeile und escaped Kommas und Anführungszeichen
✔ normalisiert E-Mail-Adressen und entfernt Duplikate
✖ überspringt Einträge ohne Einwilligung
ℹ tests 3
ℹ pass 2
ℹ fail 1

Dann die Frage, ob das Abnahmekriterium trennscharf ist. Dafür wurde der Schritt in zwei getrennten Kopien probeweise auf zwei Arten umgesetzt:

Der Befehl aus dem Arbeitsstand erkennt also nicht nur, ob gefiltert wird, sondern auch, ob die Entscheidung E-002 eingehalten ist. Das ZIP wurde zusätzlich frisch entpackt, als Git-Repository angelegt und liefert dieselbe Ausgangslage.

Diese Übergabeprobe dokumentiert den Stand vom 10. Oktober mit drei Tests. Der Download wurde am 13. Oktober um vier CSV-Regressionstests und die Entscheidung E-004 ergänzt: Jetzt sind sechs von sieben Tests grün, weiterhin fehlt allein der Einwilligungsfilter. Nach dessen korrekter Umsetzung müssen alle sieben Tests bestehen.

Fortsetzung durch das zweite Werkzeug

Das Beispiel ist in einer Claude-Code-Session entstanden. Am 10. Oktober 2026 fortgesetzt hat es eine bereits laufende Codex-Sitzung, gezielt auf eine unveränderte Kopie des Projekts verwiesen. Die Codex-CLI wurde dabei nicht verwendet; Version und Modell der Sitzung sind nicht festgehalten. Laut Rückmeldung der Sitzung las sie AGENTS.md, docs/stand.md, docs/entscheidungen.md sowie Code und Tests und führte vor jeder Änderung npm test aus: 2 bestanden, 1 fehlgeschlagen. Danach ergänzte sie eine Zeile vor der Duplikatprüfung und überschrieb den Arbeitsstand.

   for (const eintrag of eintraege) {
+    if (eintrag.einwilligung !== true) continue;
     const email = normalisiereEmail(eintrag.email);
     if (gesehen.has(email)) continue;

Das Ergebnis wurde anschließend im Projektordner selbst nachgeprüft: npm test meldet 3 bestandene und 0 fehlgeschlagene Tests, git status zeigt nur src/export.js und docs/stand.md als geändert, test/ ist unverändert. Der neue Arbeitsstand endet wieder mit einem prüfbaren Schritt für die nächste Übernahme:

## Nächster prüfbarer Schritt

1. Bei der nächsten Übernahme `npm test` ausführen.
   Erwartet: 3 bestandene und 0 fehlgeschlagene Tests.
2. Den Diff abnehmen: Nur der Filter in `src/export.js` und dieser Arbeitsstand
   wurden geändert; `git status --short test/` bleibt leer.

CSV: ein geprüfter Konsument, klare Grenzen

Der Export im aktuellen Download ist für LibreOffice Calc 26.8.0.3 unter macOS geprüft: UTF-8, Komma als Separator, doppeltes Anführungszeichen als Textbegrenzer und Standardspalten. „Zitierte Felder als Text“ war ausgeschaltet, die Formelauswertung eingeschaltet. Der unveränderte Kontrollfall =1+1 wurde in allen drei Spalten als Formel ausgewertet und ergab 2.

Der Export prüft jede Zelle. Bei riskanten Anfängen setzt er einen sichtbaren Apostroph voran, darunter = + - @, Tab, CR, LF, Vollbreitenvarianten und Formelzeichen nach Leerraum. Normale CSV-Werte und die vorhandene E-Mail-Normalisierung bleiben erhalten. Kommas, Quotes und Zeilenumbrüche werden zusätzlich CSV-zitiert. Der Apostroph ist Teil der exportierten Daten; es wird kein Eintrag deshalb verworfen.

Geprüft am 13. Oktober 2026: 66 synthetische Zeilen über alle drei Spalten, darunter 42 riskante Zellen. Diese blieben beim Import, nach ODS-Speichern und nach CSV-Speichern mit anschließendem Wiederöffnen Textzellen; im geschützten Datensatz gab es keine Formeln. Der direkte CSV-Roundtrip erhielt die Zellwerte exakt. Calc normalisierte CR und CRLF zu LF.

So probierst du es aus

1. ZIP holen. Zum Nachprüfen der Übergabe das ZIP verwenden: Es enthält das ganze Projekt mit Code und Tests, alle Dateien tragen bereits ihre echten Namen. Die Einzeldateien sind Vorlagen für das eigene Projekt und enthalten weder Code noch Tests. Sie heißen AGENTS.beispiel.md und CLAUDE.beispiel.md, weil Agenten Dateien namens AGENTS.md oder CLAUDE.md im Repository dieser Website als echte Anweisungen laden könnten. Für das eigene Projekt umbenennen: AGENTS.beispiel.md → AGENTS.md und CLAUDE.beispiel.md → CLAUDE.md in die Projektwurzel, entscheidungen.md und stand.md nach docs/.
2. Ausgangslage festhalten. Im entpackten Ordner git init && git add . && git commit -m "Ausgangslage", dann npm test. Erwartet: 6 bestanden, 1 fehlgeschlagen.
3. Session starten. Claude Code oder Codex in diesem Ordner öffnen und nur schreiben: „Setze die Arbeit in diesem Projekt fort.“ Beobachten, ob die Session den Arbeitsstand liest und npm test ausführt, bevor sie Code ändert.
4. Selbst abnehmen. npm test und git status --short. Fertig ist es bei 0 Fehlschlägen, unveränderten Tests und einem überschriebenen docs/stand.md.
5. Mit dem anderen Werkzeug wiederholen. Zurück auf die Ausgangslage (git stash -u oder eine neue Kopie) und dieselbe Übergabe an das zweite Werkzeug geben. So zeigt sich, ob die Dateien für beide tragen.

Für das eigene Projekt: Übergabe-Check am Session-Ende

• Ist der Arbeitsstand überschrieben, nicht ergänzt?
• Hat der nächste Schritt einen Befehl und ein erwartetes Ergebnis?
• Sind neue Entscheidungen mit Grund im Protokoll gelandet?
• Ist die Regeldatei noch kurz, oder ist Begründung hineingerutscht?
• Liegt neben der AGENTS.md eine CLAUDE.md ohne @AGENTS.md?

Am besten an einer kleinen, abgeschlossenen Aufgabe ausprobieren, nicht am größten offenen Umbau. Dort ist schnell sichtbar, ob die nächste Session ohne Nacherklären weiterkommt.

Grenzen

• Die Angaben zum Ladeverhalten stammen aus der Dokumentation vom 10. Oktober 2026. Das Ladeverhalten selbst wurde für diesen Artikel nicht nachgemessen. Ältere Versionen von Claude Code vor 2.1.277 lesen laut Dokumentation nur CLAUDE.md, in manchen Fällen auch die erste Session nach einem Update von einer solchen Version.
• Die Regel „zuerst den Arbeitsstand lesen“ ist Text. Kein Werkzeug garantiert, dass sie befolgt wird. Deshalb endet die Übergabe mit einem Befehl, den jede Session und jeder Mensch selbst ausführen kann.
• Claude Code hat zusätzlich ein automatisches Gedächtnis mit Notizen, die Claude selbst schreibt. Es liegt laut Dokumentation standardmäßig im Home-Verzeichnis unter ~/.claude/projects/ und ist damit kein gemeinsamer Ort für ein zweites Werkzeug. Für die Übergabe zwischen Werkzeugen zählt, was im Repository steht.
• Der Artikel vergleicht Ladewege, nicht die Qualität der Werkzeuge, und enthält keine Empfehlung für ein Abo oder einen Tarif.

Downloads

• Komplettes Beispielprojekt zum NachprüfenZIP

  Ganzes Projekt mit sieben Tests, davon ein absichtlich roter Consenttest. CSV für den dokumentierten Calc-Konsumenten geprüft. Entpacken, git init, npm test.

• Vorlage: RegelnMarkdown

  Einzeldatei ohne Code. Als AGENTS.md in die eigene Projektwurzel legen.

• Vorlage: Brücke für Claude CodeMarkdown

  Einzeldatei ohne Code. Als CLAUDE.md neben die AGENTS.md legen.

• Vorlage: EntscheidungsprotokollMarkdown

  Einzeldatei ohne Code. Im eigenen Projekt nach docs/entscheidungen.md.

• Vorlage: ArbeitsstandMarkdown

  Einzeldatei ohne Code. Im eigenen Projekt nach docs/stand.md.

Quellen

1. OWASP: CSV Injection (öffnet in neuem Tab)

   Konsumentenabhängige Neutralisierung und Speichern/Wiederöffnen. Abgerufen am 13. Oktober 2026.

2. Claude Code Docs: How Claude remembers your project (öffnet in neuem Tab)

   CLAUDE.md, Imports, AGENTS.md-Unterstützung, Auto Memory. Abgerufen am 10. Oktober 2026.

3. OpenAI Codex: Custom instructions with AGENTS.md (öffnet in neuem Tab)

   Ladereihenfolge, AGENTS.override.md, project_doc_max_bytes. Die frühere Adresse developers.openai.com/codex/guides/agents-md leitet hierher weiter. Abgerufen am 10. Oktober 2026.

4. OpenAI Codex: Advanced configuration (öffnet in neuem Tab)

   Beschreibt project_doc_max_bytes als Grenze pro AGENTS.md-Datei, abweichend von der Anleitung oben. Abgerufen am 10. Oktober 2026.

5. AGENTS.md (öffnet in neuem Tab)

   Offenes Format, von mehreren Coding-Agenten unterstützt.

6. Node.js: Test runner (öffnet in neuem Tab)

   Grundlage für npm test im Beispielprojekt.