ki-codex/07-best-practices-troubleshooting.md

Kapitel 7

Best Practices und Troubleshooting

Kern in einem Satz: Kontext steuern, Sessions hygienisch halten, Symptom→Fix – und die Grenzen des Harness ehrlich einordnen; bei Drift schlägt die Doku das Buch.

---

7.1 Best Practices – kompakt

Wenn du nur eine Seite mitnimmst:

Hebel	Praxis
Scope eng	Dateien, Done-Kriterium, Nicht-Ziele, Stop-Regel
Diff lesen	/diff / git diff vor Commit und vor „fertig“
Enge Sandbox vor Full Access	Auto zuerst; --yolo Ausnahme in Isolation
Weich vs. hart	AGENTS.md bittet; Sandbox/Rules/Hooks erzwingen
Phasen	Explore → Plan → Code → Verify → Commit (Kap. 3)
Verify-Command wörtlich	aus AGENTS.md, nicht „teste mal“
Memory kurz	32 KiB-Cap und Startlast ernst nehmen
Skills statt Roman	Prozeduren on-demand (Kap. 5)
CI least privilege	read-only wo möglich; Keys nicht job-weit (Kap. 6)
Mensch merged	Agent schlägt vor

Vier Hebel aus der Einleitung – hier als Betriebssystem der Session, nicht als Poster.

---

7.2 Kontext-Management

Das Modell sieht nur, was im Fenster liegt: System/Harness, AGENTS.md-Kette, Skills/MCP-Metadaten, History, Tool-Outputs. Eloquenz füllt das Fenster genauso wie Nutzen.

{width=90%}

Startlast: Jede Session zahlt für geladene Instructions. Lange globale + Root- + nested-Dateien konkurrieren mit dem eigentlichen Ticket. Kürzen, splitten, Cap anheben nur bewusst (project_doc_max_bytes).

Während der Session:

Problem	Mittel
Thema gewechselt	/new oder /clear
Fenster voll / Antworten matschig	/compact (siehe 7.3)
Zu viel Noise	Subagent für Explore/Logs (Kap. 5)
Falsche Datei im Fokus	@ / /mention gezielt
Status unklar	/status (Model, Policy, Roots, Usage)

/usage zeigt Kontingent/Aktivität – nützlich, bevor du „noch eine Runde Full Reasoning“ startest.

---

7.3 Compact ist verlustbehaftet

/compact

Codex fasst frühere Turns zusammen, um Tokens freizugeben. Das ist kein verlustfreies Archiv.

{width=90%}

{width=90%}

Vor Compact (oder vor langem Lauf):

• Entscheidungen in PLAN.md, Issue oder Commit-Message
• Akzeptanzkriterien und Nicht-Ziele in Dateien
• Offene Risiken als Bullet-Liste im Repo, nicht nur im Chat

Hooks PreCompact / PostCompact können blocken oder Kontext anreichern – ersetzen aber keine Datei-Notizen. Nach Auto-Compact kann SessionStart mit source: compact greifen (Hooks-Doku).

Achtung: „Wir hatten doch beschlossen…“ nach Compact ohne Datei-Anker ist oft weg. Dateien > Chat-Mythos.

---

7.4 Session-Hygiene und Rollback

Ziel	Mittel
Fortsetzen	codex resume / /resume (--last, ID, --all)
Abzweigen	/fork, codex fork
Aufräumen	codex archive / unarchive
Endgültig weg	codex delete (permanent)
Umbenennen	/rename
Vorherigen User-Turn editieren	Esc zweimal (leerer Composer) → Fork ab dort

Rollback Workspace:

1. Git: git checkout -- Pfad, git restore, selektiver Reset – du bleibst Owner.
2. Session-Fork stellt Shell-Effekte außerhalb Git nicht magisch wieder her.
3. Cloud: codex apply nur nach Diff-Review.

History optional drosseln:

[history]
persistence = "none"

---

7.5 Sandbox-, Trust- und YOLO-Fallen

Falle	Gegenmittel
Full Access aus Bequemlichkeit	Auto-Preset; Config-Profile deep-review (read-only)
Session-Scope auf destruktive Tools	Scope eng; ablehnen + Feedback
Untrusted Project, aber .codex/ erwartet	Trust setzen oder User-Layer nutzen
Cloud = „sicher YOLO“	Environment-Policy lesen
MCP mit Write + weitem Token	enabled_tools, Approval-Mode, Secrets in Env
Hook untrusted → „läuft nicht“	/hooks reviewen
git commit fragt trotz write	.git protected – normal

---

7.6 Multi-Repo und Modelle

Szene: Monorepo + Library im Sibling-Ordner. Ein Full-Access-Session „für beide“ klingt effizient – und vermischt Trust, AGENTS.md und Secrets zweier Welten.

• Ein CWD pro Session – Policy und AGENTS.md hängen am Ordner (Kap. 4).
• Zweites Repo: neue Session oder Git-Worktree / isolierter Checkout – nicht „einfach Full Access“.
• Zusätzliche Schreibflächen: writable_roots / --add-dir (eng), nicht danger-full-access.
• Fremde Clones: erst untrusted/read-only explorieren, Trust bewusst.
• Modell/Effort der Task anpassen (Kap. 3); Review ggf. review_model.
• Custom Providers / openai_base_url nur nach Org-Vorgabe; Managed kann Provider und Profile einschränken (Kap. 6).

---

7.7 Symptom → Fix

Symptom	Typische Ursache	Fix
npm test im Python-Repo	AGENTS.md fehlt/leer/truncated/CWD falsch	Datei prüfen; Instructions-Prompt; Cap
Project-Config greift nicht	untrusted	Trust; /status
Config-Profile wirkt nicht	Legacy-Syntax; falscher Dateiname; mit Permission Profiles verwechselt	~/.codex/name.config.toml + --profile (Kap. 4.4)
Zu viele Approvals	enge Policy ohne erlaubte Routine	Auto; Rules allow eng; Session-Scope sparsam
Zu wenige Approvals / Überraschungen	YOLO / never / weites Session-Scope	zurück auf on-request; archive Session
MCP-Tool fehlt	disabled; Init fail; OAuth	codex mcp list; login; logs
Hook silent	untrusted; feature off; matcher	/hooks; [features].hooks
Antworten unscharf	Context voll; Thema vermischt	/compact + Datei-Anker; /new
Truncated Instructions	> Cap	kürzen, nested, project_doc_max_bytes
CI leakt Key	Job-Env + untrusted Steps	Action-Proxy; Key nur am Exec-Step (Kap. 6)
Cloud-Diff zerstört lokal	blind codex apply	Diff lesen; Branch
Linux-Sandbox-Warnung	kein bwrap / AppArmor	Sandboxing-Doku OS-Abschnitt
„Modell ignoriert Nie-Liste“	weich ≠ hart	Hook/Rule/Sandbox
Config/Feature „verboten“ trotz lokaler TOML	Managed requirements.toml / Org	/debug-config; Admin – nicht umgehen
Anderes Verhalten als Kollege	Trust, CODEX_HOME, Managed, anderes Profil	Layer vergleichen; Team-Baseline (Kap. 6)

Diagnose-Reihenfolge (5 Minuten):

1. pwd / CWD und Git-Root
2. /status – Model, Sandbox, Approvals, writable roots
3. /debug-config – Layer und ob Managed/Org greift
4. Instructions-Verify-Prompt („Summarize current instructions“)
5. codex doctor bei Install-/Runtime-Verdacht
6. Org-Verdacht: Managed/Team-Config im Runbook – nicht YOLO
7. Dann erst Config umbauen

---

7.8 Wenn Doku und Buch abweichen

Lesevertrag (Einleitung): Konzept behalten, Syntax der Doku.

1. codex --version notieren.
2. learn.chatgpt.com/codex, codex --help, / in der TUI.
3. Zweck des Flags im Buch behalten („nie ohne Nachfrage“), Literal anpassen.
4. Begleit-Service (Stand & Drift, Errata), falls gepflegt – parallel zu Docs, nicht statt dessen.

Typ	Bedeutung
Erratum	Buchfehler
Produkt-Drift	Codex/Doku geändert; Konzept oft stabil
Vereinfachung	Buch knapper, nicht falsch
Session-Drift	Context/Compact – dieses Kapitel

---

Checkliste – Troubleshooting-Session

• CWD und Trust klar
• /status gelesen
• Instructions vs. Policy getrennt gedacht
• Diff/Git-Stand geprüft
• Eine Änderung nach der anderen (nicht fünf Hebel gleichzeitig)
• Ergebnis in Datei oder Commit festgehalten

Häufige Fehler beim Debuggen selbst

Fehler	Besser
Alles auf YOLO drehen „zum Testen“	eng reproduzieren, dann weiten
Config und Prompt gleichzeitig ändern	eine Variable
Compact ohne Notizen	erst PLAN.md
Fremdrepo trusted aus Frust	Clone isolieren

So baust du ein internes Runbook nach

1. Symptom→Fix-Tabelle dieses Kapitels forken.
2. Eure Verify-Commands und MCP-Liste eintragen.
3. Org-Verbote (Managed) verlinken.
4. Eskalation: wer darf Full Access / Cloud-Internet freischalten.
5. Vierteljährlich an codex --version und Docs spiegeln.

Jetzt selbst machen

cd beispiele/todo-cli
codex

1. /status und Instructions-Zusammenfassung anfordern.
2. Absichtlich vagen Prompt senden, dann mit Scope+Stop-Regel wiederholen – Diff-Größe vergleichen.
3. Optional /compact nach drei Zeilen in PLAN.md.
4. Ein Symptom aus der Tabelle bewusst provozieren (z. B. falscher CWD) und beheben.

---

7.9 Grenzen, Trade-offs und kritische Einordnung

Kern in einem Satz: Ein guter Harness macht Codex steuerbar – er macht das Modell weder unfehlbar noch kostenlos noch anbieterunabhängig.

Bis hierher war das Buch konstruktiv: Scope, Diff, Sandbox, AGENTS.md, Sessions, CI. Das bleibt gültig. Es ersetzt aber keine ehrliche Einordnung: Was systematisch schwer bleibt, welche Trade-offs du kaufst, wann der Agent nicht laufen sollte – und warum dieses Buch bei Codex bleibt, ohne die Landschaft zu leugnen.

Was trotz guter Steuerung schiefgehen kann

Konfiguration und Disziplin senken die Fehlerquote. Sie heben die harte Decke nicht auf.

Kontextfenster. Wie in 7.2: Das Modell sieht nur, was im Fenster liegt. Lange History, fette Tool-Outputs und zu viele nested Instructions verdrängen das Ticket. /compact schafft Platz und verliert Nuancen (7.3). Gute AGENTS.md ist kein unendliches Arbeitsgedächtnis.

Halluzinationen trotz Verify. Ein grüner Test beweist die geprüften Pfade, nicht die ungeschriebenen. Falsche Stack-Befehle und „plausible“ APIs treten auch mit Verify-Command auf – seltener, nicht nie. Verify ist ein Filter, kein Freibrief.

Lange Tool-Ketten. Je mehr Schritte (suchen → editieren → testen → nachbessern), desto fester setzt sich ein früher Fehlschluss. Der Harness führt aus, was erlaubt ist; er korrigiert keine falsche Problemdeutung im dritten Turn.

Kosten und Multiplikation. Hoher Reasoning-Aufwand, breite Exploration und Subagents multiplizieren Tokens und Wartezeit. Parallelität ersetzt weder Plan noch Diff – bei unklarem Scope macht sie beides teurer (Kap. 5 und 6.6).

Enge Sandbox + Approvals als Bremse. read-only und on-request sind der richtige Default in fremden oder sensiblen Trees. Im vertrauten Repo spürst du die Reibung: Shell wartet, Netzwerk fragt. Das ist der Preis von Kontrolle – kein Policy-Bug. Wer aus Frust auf Full Access / never wechselt, tauscht Reibung gegen Review-Last und Vorfallrisiko.

Vendor-Abhängigkeit und Produkt-Drift. Auth, Kontingente, Modellnamen, Labels und Managed Policies liegen beim Anbieter und deiner Org. Was lokal greift, greift in Cloud oder CI nicht automatisch mit (Kap. 3 und 6). Lesevertrag (Einleitung, 7.8): Konzept behalten, Syntax der Doku. Du baust Rituale um ein Produkt, das sich bewegen darf.

Wann du Codex besser nicht oder nur eng einsetzt

• Produktionshotfix mit unklarem Blast Radius ohne reproduzierbare Verify-Schleife
• Security-/Compliance-kritische Änderungen, bei denen menschliche Review und Vier-Augen Pflicht sind – nicht „auch noch vom Agenten“
• Unbekannte Repos / Supply-Chain-Verdacht: erst read-only – oder gar kein Agent
• Rein politische Architekturentscheidungen ohne messbares Done-Kriterium
• Wenn du Diffs nicht mehr liest, weil „der Agent das schon macht“ – Ownership ist dann abgegeben

Trade-offs, die du nicht wegrationalisieren kannst

Jeder Hebel kauft etwas und verkauft etwas anderes. Sicherheit und Geschwindigkeit sind oft Gegenpole derselben Entscheidung – unten als getrennte Zeilen, weil du sie im Alltag separat spürst.

Achse	Mehr davon …	kostet typischerweise …
Sicherheit ↔ Geschwindigkeit	enge Sandbox/Approvals oder weite Rechte/YOLO in Isolation	Tempo und Klicks oder Review-Last, größere Diffs, teure Fehlversuche
Autonomie (Cloud, Subagents, lange Sessions)	parallele/async Arbeit	Kontext- und Kostenrisiko, weniger Live-Steuerung
Kontrolle (Plan, enger Scope, Diff vor Merge)	nachvollziehbare Schritte	mehr menschliche Minuten pro Ticket
Weiches Memory (AGENTS.md)	bessere Defaults	kein Zwang – „Nie“ wird gebeten, nicht erzwungen
Harte Boundaries (Sandbox, Rules, Hooks, Managed)	echte Verbote	Pflege, False Positives, Onboarding-Reibung

Lokal CLI vs. Cloud vs. Desktop/IDE-App ist dieselbe Engine mit anderen Orten und Isolationsgraden – kein Ranking „Cloud ist sicherer“. Lokal: Live-Steering und /diff. Cloud: async, environment-eigene Policy. App/IDE: niedrigere Einstiegshürde, dieselben Trust- und Ownership-Fragen. Surface-Wahl ist Workflow, nicht Moral.

Kern: Weich steuert Verhalten; hart begrenzt Schaden. Wer nur AGENTS.md pflegt und Sandbox aufweicht, hat Dokumentation – keine Boundary.

Orientierende Einordnung: Coding-Agents und übertragbare Prinzipien

Kern in einem Satz: Ein Vergleich kann Mehrwert liefern – aber nur als orientierende, prinzipienbasierte Einordnung, nicht als detaillierter Produktvergleich.

Feature-Listen und Punkt-für-Punkt-Produktvergleiche altern in Monaten. Labels, Preisstufen, Default-Policies und Integrationsflächen verschieben sich; was gestern „einzigartig“ wirkte, ist morgen Standard oder verschwunden. Eine prinzipienbasierte Einordnung hält länger: Sie fragt nach Einstieg, Steuerungsphilosophie und Workflow-Passung – nicht nach dem aktuellen Menüpunkt in der UI.

Dieses Buch bleibt bei OpenAI Codex (CLI primär, dazu IDE, ChatGPT und Cloud), weil Praxis Tiefe braucht: eine durchgängige Terminologie (Sandbox × Approvals, Project Trust, AGENTS.md, Sessions, CI), nachbaubare Configs und einen Lernpfad von Trust bis Merge. Andere Ansätze abzuwerten wäre unsachlich; drei Produkte halb zu erklären erzeugt nur Schein-Übersicht. Die Landschaft unten dient der Orientierung – nicht der Kaufberatung und nicht dem Ranking.

Landschaftsskizze (Stand Mitte/Ende 2026)

Coding-Agents teilen oft dieselbe Grundschleife (planen, editieren, Shell, iterieren), unterscheiden sich aber im Schwerpunkt des Einstiegs:

Kategorie	Schwerpunkt / typischer Einstieg	Beispiele (nicht abschließend)
Terminal-zentriert	Repo und Shell als Arbeitsfläche; Steuerung über CLI, Instructions und Permission-Grenzen	Codex CLI; Claude Code und vergleichbare Terminal-Agenten
IDE-zentriert	Editor, Diff-Ansicht und Projektsicht eng verwoben; niedrige Hürde im Alltagscode	Cursor und ähnliche IDE-Agenten
Diff-/Git-zentriert, leichtgewichtig	Kleine, nachvollziehbare Änderungen; Git-Disziplin und geringer Overhead	Aider und verwandte terminalnahe Tools
Cloud-/asynchron	Auftrag wegschicken, später Diff/Ergebnis prüfen; Isolation und Environment-Policy statt Live-Steering	Codex Cloud und vergleichbare async/remote Agenten

Die Zeilen beschreiben Einstiege, keine Feature-Vollständigkeit. Ein Produkt kann mehrere Kategorien berühren (Codex etwa lokal und in der Cloud) – die Frage bleibt: Wo steuerst du primär, und welche Boundary spürst du zuerst?

Wann eignet sich welcher Ansatz eher?

Die Matrix bezieht sich auf Workflow und Steuerungsphilosophie, nicht auf Modellqualität oder Feature-Score:

Dein Schwerpunkt …	Passt eher zu …	Typische Passung
Starke Terminal-Kontrolle und harte Boundaries (Sandbox, Approvals, Policy vor Tempo)	Terminal-zentrierte Agenten	Du willst Shell, Repo und Grenzen explizit steuern; Reibung ist akzeptierter Preis
Tiefer Editor-Bezug und visuelle Integration (Inline, UI-Diff, Projektsicht)	IDE-zentrierte Agenten	Der Alltag lebt im Editor; der Agent soll dort „mitlaufen“, nicht erst im Terminal starten
Maximale Diff- und Git-Disziplin bei geringem Overhead	Diff-/Git-zentrierte, leichte Tools	Kleine, reviewbare Schritte; wenig Setup, viel Commit-Hygiene
Asynchrone oder isolierte Cloud-Arbeit (Auftrag, warten, Diff prüfen)	Cloud-/async Agenten	Parallelität und Isolation; weniger Live-Steering, mehr Environment- und Apply-Disziplin

Keine Zeile bedeutet „Produkt A schlägt B“. Sie bedeutet: passender Einstieg und ehrlicher Scope. Wer fast nur Inline-Chat im Editor braucht, lernt Codex-CLI-Tiefe nicht als Erstes. Wer Sandbox und Approvals systematisch trainieren will, findet im Kernpfad dieses Buchs den roten Faden – unabhängig davon, welche Tools du zusätzlich im Stack hast.

Übertragbare Prinzipien

Produktfeatures kommen und gehen. Die folgenden Regeln gelten in jedem seriösen Coding-Agent-Setup – unter anderen Dateinamen und UI-Labels, aber mit derselben Logik:

1. Scope eng halten. Dateien, Done-Kriterium, Nicht-Ziele, Stop-Regel. Breite Aufträge multiplizieren Diff, Kosten und Fehldeutungen.
2. Diff lesen vor Merge und vor „fertig“. Tests und grüne Häkchen ersetzen keine menschliche Sicht auf was sich geändert hat – lokal, in der Cloud und vor dem Apply.
3. Weich vs. hart trennen. Bitten (Instructions, Conventions, „bitte nie …“) steuern Verhalten. Erzwingen (Sandbox, Approvals, Rules, Hooks, Managed Policy) begrenzt Schaden. Wer nur bittet und Boundaries aufweicht, hat Dokumentation, keine Grenze.
4. Menschliche Ownership an Merge, Secrets und Produktion. Der Agent schlägt vor und ändert im erlaubten Rahmen. Freigabe in den Mainline-Branch, Umgang mit Geheimnissen und produktive Eingriffe bleiben beim Menschen bzw. bei klaren Team-Prozessen.
5. Verify und Phasen vor blinder Autonomie. Explore → Plan → Code → Verify → Commit (oder das Äquivalent deines Tools) ist billiger als eine ungebremste Tool-Kette. Autonomie ohne Checkpoints spart Klicks und kauft Review-Last.

Kern: Diese Prinzipien sind langlebiger als jedes Feature-Release. Wer sie beherrscht, wechselt den Harness mit Lernkurve – wer nur Hotkeys und Default-Prompts kennt, startet bei jedem Produkt bei null und ohne Bremse.

Warum das wichtiger ist als einzelne Produktfeatures: Features erklären wie ein Tool etwas anbietet. Prinzipien erklären welche Fehlerklasse du vermeidest – Scope-Creep, ungeprüfte Diffs, weiche „Verbote“, abgegebene Ownership, blinde Autonomie. Genau diese Klassen bleiben, wenn die UI morgen anders heißt.

Trade-off – jeder Ansatz kauft etwas

Jeder Einstieg kauft etwas und verkauft etwas anderes. Terminal-Kontrolle und harte Boundaries kosten oft Klicks und Geduld. IDE-Nähe senkt die Einstiegshürde und kann Live-Review erleichtern – die Boundary-Frage verschwindet dadurch nicht. Diff- und Git-Disziplin mit wenig Overhead belohnt kleine Schritte, skaliert aber anders bei großen, multi-repo Refactors. Cloud und Asynchronität kaufen Parallelität und Isolation und verkaufen Live-Steering: Du steuerst über Auftrag, Policy und späteren Diff, nicht über jeden Zwischenschritt am Prompt. Wer beides maximal will – maximale Autonomie und maximale Kontrolle ohne Review – will zwei gegenläufige Achsen gleichzeitig. Das löst kein Produkt; das löst nur ehrliche Priorisierung.

Was du mitnehmen kannst

• Feature-Listen und Tiefenvergleiche veralten schnell; Einstieg + Steuerungsphilosophie halten länger.
• Vier grobe Kategorien reichen zur Orientierung: Terminal, IDE, Diff/Git-leicht, Cloud/async.
• Die Entscheidungsfrage lautet „welcher Workflow?“, nicht „welches Produkt gewinnt?“.
• Fünf Prinzipien (Scope, Diff, weich/hart, Ownership, Verify/Phasen) sind harness-übergreifend mitnehmbar.
• Dieses Buch vertieft Codex – nicht, weil die Landschaft leer wäre, sondern weil Tiefe einen Fokus braucht.

Typische Fehlerbilder – auch bei korrekter Config

Diese Fehlerbilder treten auf, obwohl Trust sitzt, AGENTS.md sinnvoll ist und die Sandbox nicht auf YOLO steht.

1. Grüne Tests, falsche Semantik. Die Suite ist grün, die Produktabsicht verfehlt (Edge Case, UX, stille Invariante).
   Tun: Akzeptanzkriterien und Nicht-Ziele in PLAN.md; kritischen Pfad manuell prüfen; Diff auf „was fehlt?“ lesen.

2. Approval-Müdigkeit. Nach dem zwanzigsten Dialog wird „Session“ aus Gewohnheit geklickt.
   Tun: Scope/Allowlist enger, nicht die Policy weiter; Session archivieren und mit Auto-Preset neu starten; destruktive Muster nie session-weit.

3. Tool-Schleife. Flaky Test oder unklare Meldung → Edit-Test-Schleife, Kontext voll Noise.
   Tun: stoppen; Fehler selbst reproduzieren; neuer Scope mit Stop-Regel; ggf. /new.

4. Subagent-/Reasoning-Spirale. Explore und hohe Effort-Stufen multiplizieren Kosten, ohne schärferes Ticket.
   Tun: /usage vorher; ein Explore-Pass mit klarer Frage; Plan in Datei; Code-Phase ohne parallele Explore-Sessions.

5. Kontext-Matsch nach Themenwechsel. Dieselbe Session, drittes Ticket – Antworten vermischen Repos.
   Tun: /new oder /clear; CWD/Trust prüfen; Compact nur mit Datei-Anker (7.3–7.4).

6. Lokal eng, remote weit. Lokal eng (Deny), Cloud/CI mit anderen Rechten – der Diff fühlt sich fertig an.
   Tun: Environment- und Job-Policy lesen; codex apply/Merge nie blind; least privilege pro Surface (Kap. 6).

Wann das Harness-Modell besonders stark ist – und wo es aneckt

Stark, wenn:

• das Problem abgrenzbar ist (Dateien, Done, Verify)
• du Diff und Tests als Eigentümer behandelst
• weiche Guidance und harte Boundaries zusammen sitzen
• Surfaces bewusst gewählt sind (lokal iterieren, remote nur mit Policy)

An Grenzen, wenn:

• das Ziel vage ist („mach es besser“) und niemand Ownership übernimmt
• Sicherheit und Tempo gleichzeitig maximal sein sollen
• niemand Version//status pflegt
• Kosten steigen, ohne dass Scope und Verify mitwachsen

Der Harness ist ein Steuerungssystem, kein Ersatz für Urteilsvermögen. Wer das akzeptiert, holt aus Codex mehr heraus – und schaltet ihn ab, wenn die Situation es verlangt.

---

Was du jetzt kannst

• Die kompakten Best Practices und vier Hebel im Alltag anwenden
• Kontextlast und Compact-Risiko steuern
• Sessions hygienisch resume/fork/archive/delete
• Workspace-Rollback von Session-History trennen
• Symptom→Fix-Raster für Trust, Config, MCP, Hooks, CI nutzen
• Bei Drift Doku vor Buch stellen und Version notieren
• Grenzen, Trade-offs und typische Fehlerbilder des Harness-Ansatzes benennen
• entscheiden, wann Codex eng bleibt, pausiert oder ein anderer Einstieg näherliegt

Nächste Schritte

• Kapitel 8 – Cheatsheets: Lookup ohne Erklär-Roman
• Anhang A: stabile Kernvorlagen
• Primärdoku und codex doctor als Dauerwerkzeuge behalten – bei Drift gilt 7.8, nicht Bauchgefühl

Primärquellen: Best practices (bzw. aktuelle Guides), Developer commands, AGENTS.md, Approvals & security, Non-interactive.