Codex-Hooks machen den Harness real

Mit Codex 0.150.1 (27. August 2026) registrieren Codex-Hooks zwölf Lifecycle-Events, führen keinen nicht verwalteten Hook aus, bevor Sie dessen exakte Definition geprüft und als vertrauenswürdig eingestuft haben, und sind standardmäßig aktiviert. Die Funktion, die im Launch-Paket vom 14. Mai zusammen mit der ChatGPT-Mobile-App die allgemeine Verfügbarkeit erreichte, ist zu einer Governance-Oberfläche gereift: PreToolUse kann einen Tool-Aufruf blockieren oder umschreiben, bevor er läuft, PermissionRequest kann eine Freigabe entscheiden, PostToolUse kann das Ergebnis ersetzen, das das Modell sieht, und Stop kann sich weigern, einen Turn abschließen zu lassen.²³

Codex sieht nicht mehr aus wie ein Coding-Assistent, der in einem einzelnen Terminal wartet. Es wirkt wie eine Betriebsschicht, die Arbeit über Maschinen, Freigaben, Projekte, Chats, Diffs, Tests, Screenshots, Plugins, Zugangsdaten und lokale Tools hinweg begleitet.⁴

Codex-Hooks machen den Harness real. Sobald der Agent vom Telefon aus arbeiten, entfernte Entwicklungsumgebungen erreichen und Lifecycle-Hooks ausführen kann, brauchen Teams ein Kontrollsystem um das Modell herum: Evidenz, Freigaben, Git-Custody, Quellendisziplin und Geschmack.

TL;DR

Codex unterstützt die Workflow-Form, die Agenten-Teams bisher privat gebaut haben: langlaufende Arbeit, Remote-Ausführung, mobile Steuerung, Freigaben, Hooks, begrenzte Zugangsdaten und Audit-Signale.²⁴⁵ Die Hooks-Engine registriert mit 0.150.0 zwölf Events, jeder nicht verwaltete Hook bleibt übersprungen, bis Sie seinem aktuellen Hash vertrauen, und Hooks laden aus hooks.json-Dateien oder Inline-[hooks]-Tabellen in config.toml.³⁷ Die praktische Frage lautet nicht „Wie prompten wir Codex?“ Die praktische Frage lautet „Was muss Codex beweisen, bevor wir dem Ergebnis vertrauen?“ Teams sollten Hooks und Konfiguration nutzen, um Review-Gates, Sicherheitsgrenzen, Standards für öffentliches Schreiben und Release-Disziplin zu kodieren. Private Maschinerie bleibt privat; veröffentlicht werden nur das Muster, die Akzeptanzkriterien und das verifizierte Ergebnis.

Zentrale Erkenntnisse

Für Engineering-Teams: - Behandeln Sie Codex-Hooks als Prozess-Infrastruktur, nicht als Dekoration. Der Trust-Review-Ablauf ist Teil dieser Infrastruktur, keine Reibung, die man umgeht. - Beginnen Sie mit Evidenz, Freigaben, Git-Custody und Release-Checks, bevor Sie clevere Automatisierung ergänzen.

Für Entwickler von Agenten-Tools: - Bauen Sie um die realen Oberflächen von Codex herum: mobile Steuerung, Remote-SSH-Hosts, Sandbox-Modi, Freigabe-Richtlinien, Projektanweisungen, Hooks, Telemetrie und Versionskontrolle. - Portieren Sie Jobs-to-be-done, nicht alte Slash-Command-Formen.

Für öffentlich Schreibende: - Nutzen Sie die offiziellen Docs unter learn.chatgpt.com für aktuelles Codex-Verhalten, und prüfen Sie den Engine-Quellcode, wenn die Docs einem Release hinterherhinken. - Beschreiben Sie private Praxis als Analyse des Autors, und lassen Sie private Prompts, Hook-Bodies, Dateipfade, Quellenlisten, Zugangsdaten und Scoring-Interna aus öffentlichen Texten heraus.

Woher kommen Codex-Hooks?

OpenAI veröffentlichte “Work with Codex from anywhere” (Arbeiten mit Codex von überall) am 14. Mai 2026.¹ Der Changelog-Eintrag der Docs zu diesem Datum hält das Launch-Paket fest: Codex wurde aus der ChatGPT-Mobile-App nutzbar, indem sie mit einem Mac verbunden wird, auf dem die Codex-App läuft, Hooks erreichten die allgemeine Verfügbarkeit, und Codex-Access-Tokens kamen für vertrauenswürdige Automatisierung hinzu.² Codex läuft vom verbundenen Host aus, sodass dieselben Projekte, Dateien, Zugangsdaten, Plugins, Skills und Konfigurationen vom Telefon aus verfügbar sind.²

Remote-Verbindungen erweitern die Reichweite über einen einzelnen Schreibtisch hinaus. Die Remote-SSH-Fähigkeit aus der Ankündigung landet in den Docs als SSH-Hosts: Die ChatGPT-Desktop-App kann Remote-Projekte von einem SSH-Host hinzufügen und Chats gegen Dateisystem und Shell des Remote-Rechners ausführen. Die Formulierung ist konkret: “Remote access uses the connected host’s projects, chats, files, credentials, permissions, plugins, Computer Use, browser setup, and local tools.” (Der Remote-Zugriff nutzt Projekte, Chats, Dateien, Zugangsdaten, Berechtigungen, Plugins, Computer Use, Browser-Setup und lokale Tools des verbundenen Hosts.)⁴

Die Hooks selbst gehen dem Launch als Experiment voraus und wuchsen danach über ihn hinaus. Die Docs definieren sie als Erweiterungs-Framework, das während der agentischen Schleife Skripte oder MCP-Tools ausführt, und benennen konkrete Aufgaben: Chats an eine Logging-Engine senden, versehentlich eingefügte API-Keys blockieren, Chats zu persistenten Erinnerungen zusammenfassen, eine Validierungsprüfung ausführen, wenn ein Turn stoppt, und Prompting pro Verzeichnis anpassen.³ Hooks sind inzwischen standardmäßig aktiviert; features.hooks in config.toml funktioniert als Kill-Switch, und features.codex_hooks überlebt nur als veraltetes Alias.³⁶

Diese Details zählen, weil sie Agentenarbeit von einem Chat-Austausch in gesteuerte Betriebsabläufe verwandeln.

Wie sehen Codex-Hooks in der Konfiguration aus?

Ein Beitrag über Hooks sollte einen Hook zeigen. Codex entdeckt Hooks neben aktiven Konfigurationsebenen, am nützlichsten ~/.codex/hooks.json, <repo>/.codex/hooks.json oder Inline-Tabellen in der config.toml einer der beiden Ebenen; existieren mehrere Quellen, laden und laufen alle passenden Hooks.³ Eine minimale hooks.json mit einem Tool-Gate und einem Abschluss-Gate:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "^Bash$",
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/pre_tool_use_policy.py",
            "timeout": 30,
            "statusMessage": "Checking Bash command"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/evidence_gate.py"
          }
        ]
      }
    ]
  }
}

Dieselbe Form inline in config.toml geschrieben:

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 ~/.codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking Bash command"

Drei Ebenen organisieren jeden Hook: ein Event, eine Matcher-Gruppe, die entscheidet, wann das Event greift, und ein oder mehrere Handler (command oder mcp_tool).³ Die aktuellen Events, mit der Zwölf-Einträge-Liste der Engine als Autorität:³⁷

Das Live-Hooks-Dokument dokumentiert weiterhin elf dieser Events; ein Interrupt-Abschnitt fehlt noch. Der 0.150.0-Changelog-Eintrag (#40511) und HOOK_EVENT_NAMES: [&str; 12] im Engine-Quellcode bei rust-v0.150.0 tragen das zwölfte.²⁷ Wenn eine Seite und die Engine sich widersprechen, vertrauen Sie der Engine.

Welche Tool-Aufrufe sehen Hooks tatsächlich?

Frühere Versionen der Docs warnten, PreToolUse decke kaum mehr als Shell- und MCP-Aufrufe ab. Das aktuelle Dokument weitet die Fläche: “PreToolUse and PostToolUse can observe more than shell and MCP calls. Most local function tools use the same hook path,” (PreToolUse und PostToolUse können mehr als Shell- und MCP-Aufrufe beobachten; die meisten lokalen Function-Tools nutzen denselben Hook-Pfad), sodass ein Matcher Tools wie update_plan direkt benennen kann und spawn_agent außerdem als Agent matcht.³ Shell-Befehle matchen als Bash, apply_patch-Dateiänderungen matchen als apply_patch, Edit oder Write, und MCP-Tools matchen Namen wie mcp__filesystem__read_file.³

Gehostete Tools bleiben außen vor: WebSearch und seine Verwandten durchlaufen den lokalen Function-Tool-Hook-Pfad nie.³ Das Dokument behält einen abgeschwächten Vorbehalt, der es verdient, vollständig zitiert zu werden: “Some specialized tool paths can opt out of the default hook path. Treat tool hooks as a useful guardrail, not a complete enforcement boundary.” (Einige spezialisierte Tool-Pfade können sich vom Standard-Hook-Pfad abmelden. Behandeln Sie Tool-Hooks als nützliche Leitplanke, nicht als vollständige Durchsetzungsgrenze.)³ Die harte Grenze gehört weiterhin dem Sandboxing; Hooks besitzen Review und Steuerung innerhalb davon.

Wie entscheidet Codex, welche Hooks laufen dürfen?

Hooks sind Code, der den Agenten steuert, also regiert Codex die Hooks selbst. Das Kontrollsystem um das Modell beginnt hier.

Bevor irgendein nicht verwalteter Hook läuft, verlangt Codex, dass Sie seine exakte Definition prüfen und ihr vertrauen. Vertrauen wird gegen den aktuellen Hash des Hooks festgehalten, sodass ein neuer oder bearbeiteter Hook zur Prüfung markiert und übersprungen wird, bis Sie ihm erneut vertrauen.³ Der /hooks-Befehl in der CLI öffnet die Review-Oberfläche: Hook-Quellen inspizieren, neue oder geänderte Hooks prüfen, ihnen vertrauen oder einzelne deaktivieren. Stehen beim Start Hooks zur Prüfung an, gibt Codex eine Warnung aus, die auf /hooks zeigt.³

Verwaltete Hooks aus System-, MDM-, Cloud- oder requirements.toml-Quellen stehen über diesem Ablauf: Sie gelten per Richtlinie als vertrauenswürdig und lassen sich im Benutzer-Hook-Browser nicht deaktivieren.³ Plugins stehen darin: Ein Plugin zu installieren oder zu aktivieren macht seine mitgelieferten Hooks nicht vertrauenswürdig; sie bleiben übersprungen, bis sie wie alle anderen geprüft sind.³ Projektlokale Hooks laden nur, wenn die .codex/-Ebene des Projekts vertrauenswürdig ist; ein nicht vertrauenswürdiges Projekt lädt weiterhin Ihre Benutzer- und System-Hooks.³

Automatisierung spürt dieselbe Regel. Ein codex exec-Lauf hat keine Review-UI, also wird ein nicht vertrauenswürdiger Hook still übersprungen, bis Sie ihm zuerst in einer interaktiven Session vertrauen; das Dokument sagt das noch nicht, aber die Startup-Review-Oberfläche der Engine existiert nur in der interaktiven TUI.⁷ Für Pipelines, die Hook-Quellen anderswo prüfen, führt --dangerously-bypass-hook-trust aktivierte Hooks für genau diesen einen Aufruf ohne persistiertes Vertrauen aus.³ Vertrauen Sie bewusst, oder sehen Sie zu, wie Ihr Gate nicht feuert: Der Harness entscheidet, welcher Code den Agenten steuern darf, bevor irgendetwas davon läuft.

Was passiert, wenn ein Hook blockiert, und wann ist es zu spät?

Das Timing entscheidet, was ein Hook noch ändern kann. Die meisten Hooks laufen synchron mit einem Standard-Timeout von 600 Sekunden; SessionEnd und Interrupt starten standardmäßig bei einer Sekunde und sind auf drei begrenzt: SessionEnd feuert, während die Session abgebaut wird, und Interrupt feuert, während der Benutzer wartet.³⁷

PreToolUse handelt, bevor irgendetwas passiert, und hält deshalb die stärksten Karten: den Aufruf verweigern oder ihn umschreiben, indem permissionDecision: "allow" mit updatedInput zurückgegeben wird. Die Verweigerungsform:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Destructive command blocked by hook."
  }
}

Exit-Code 2 mit der Begründung auf stderr blockiert ebenfalls.³

PostToolUse handelt, nachdem das Tool gelaufen ist, und kann Nebenwirkungen deshalb nicht rückgängig machen. Ein decision: "block" ersetzt das Tool-Ergebnis durch Ihr Feedback und setzt das Modell von dieser Nachricht aus fort, was den Kurs korrigiert, ohne so zu tun, als wäre der Befehl nie gelaufen.³ Stop verwandelt eine Weigerung in eine Fortsetzung: Blockieren Sie einen Abschluss, und Codex arbeitet weiter, mit Ihrer Begründung als neuem Prompt.³

Für Prüfungen, die nie auf dem kritischen Pfad sitzen sollten, setzen Sie async = true auf einem Command-Handler. Hintergrund-Hooks laufen, während Codex fortfährt, liefern Ausgabe am nächsten sicheren Punkt und können ausdrücklich nichts blockieren, freigeben oder umschreiben; halten Sie Tool-Richtlinien, Freigabeentscheidungen, Prompt-Zurückweisung und Turn-Fortsetzung synchron.³

Was hat sich in 0.149 und 0.150 verbessert?

Zwei stabile Releases Ende August haben die Governance-Geschichte gestrafft.

Codex CLI 0.149.0 (20. August 2026) zog die Freigabe-Richtlinie untrusted zurück (#39630); eine Konfiguration, die sie noch benennt, schlägt jetzt mit einem handlungsleitenden Fehler fehl, der Sie auffordert, die Einstellung zu entfernen.²⁷ Codex CLI 0.150.0 (26. August 2026) fügte das Interrupt-Hook-Event hinzu (#40511): “New Interrupt hooks can run commands or MCP handlers when an active top-level turn is interrupted.” (Neue Interrupt-Hooks können Befehle oder MCP-Handler ausführen, wenn ein aktiver Top-Level-Turn unterbrochen wird.) Interrupt-Hooks laufen nie für Subagenten.²⁷ Dasselbe Release unterband, dass nicht vertrauenswürdige Projekte projektweite AGENTS.md-Anweisungen liefern (#39837), was zur bestehenden Regel passt, dass projektlokale Hooks nur aus einer vertrauenswürdigen .codex/-Ebene laden.²³

Die Richtung ist konsistent: Ein nicht vertrauenswürdiges Verzeichnis bekommt immer weniger Autorität über den Agenten, der es betritt. Anweisungen, Hooks und Freigabe-Abkürzungen fließen jetzt alle durch explizite Vertrauensentscheidungen.

Warum zählen Hooks mehr als Mobile?

Mobiler Zugriff ändert, wo der Mensch eingreifen kann. Hooks ändern, was das System durchsetzen kann.

Ein Telefon lässt einen Operator eine Frage beantworten, während er nicht am Schreibtisch sitzt. Ein Hook kann den Agenten vor einer riskanten Aktion abfangen, nach einer Dateiänderung, vor dem Abschluss oder während eines Release-Checks. Das Telefon löst Latenz. Der Hook löst Standards.

Codex hat bereits First-Party-Kontrollflächen rund um Sandboxing und Freigaben. Die Sicherheits-Docs paaren den Sandbox-Modus, der definiert, was der Agent technisch tun kann, mit der Freigabe-Richtlinie, die definiert, wann Codex anhalten und fragen muss, bevor es handelt.⁵ Der Agent läuft standardmäßig mit abgeschaltetem Netzwerkzugriff, und der lokale Standardmodus workspace-write hält den Netzwerkzugriff aus, solange der Benutzer ihn nicht aktiviert.⁵ Hooks sitzen neben diesen Kontrollen als Review- und Steuerungsschicht, nicht als Ersatz für Sandboxing.

Hooks können lokale Standards ausführbar machen:

Das Modell kann eine Regel vergessen. Ein Hook kann die Regel genau in dem Moment erneut ausführen, in dem die Regel zählt.

Was gehört dem Harness und nicht dem Anbieter?

Ein Agent-Harness ist die Betriebsschicht um ein Modell: Berechtigungen, Gedächtnis, Tools, Hooks, Quellen-Checks, Release-Gates, Review-Pakete und Rollback-Disziplin. Der Begriff kann privat oder verschnörkelt klingen, aber die Aufgabe ist schlicht. Diese Schicht verwandelt Absicht in rechenschaftspflichtige Arbeit.

Codex legt inzwischen genug offizielle Fläche frei, um diese Schicht explizit zu machen. Remote-Verbindungen tragen die Host-Umgebung. Sandbox-Modi und Freigabe-Richtlinien definieren Handlungsgrenzen. Konfigurationsdateien definieren Modelle, Projekte, Berechtigungen, MCP-Server, Skills, Hooks, Telemetrie und Features.⁶ Der OpenTelemetry-Export bleibt Opt-in und standardmäßig aus; ist er aktiviert, sendet Codex strukturierte Events zu Chats, API-Anfragen, Stream-Aktivität, Benutzer-Prompts (standardmäßig geschwärzt), Tool-Freigabeentscheidungen und Tool-Ergebnissen.⁵⁸

Dieses Set an Flächen erzeugt eine nützliche Trennung:

Der Anbieter soll die Laufzeitumgebung weiter verbessern. Das Urteilsvermögen gehört weiterhin dem Team.

Was sollten Teams zuerst kodieren?

Beginnen Sie mit vier Gates. Sie zahlen sich sofort aus.

Evidenz-Gate

Der ursprüngliche Launch-Beitrag zu Codex betonte überprüfbare Evidenz: Terminal-Logs, Testausgaben und nachvollziehbare Schritte während der Aufgabenerledigung.⁹ Machen Sie diese Erwartung nicht verhandelbar. Ein bedeutungsvoller Abschluss sollte die geänderten Dateien, die ausgeführten Befehle, das beobachtete Verhalten, fehlgeschlagene Prüfungen und verbleibende Lücken benennen.

Für öffentliche Arbeit umfasst Evidenz Quellenlinks und die Übereinstimmung von Behauptung und Quelle. Für Web-Releases umfasst Evidenz gerenderte Routen, Metadaten, Schema, Discovery-Dateien, Deployment-Zustand, Cache-Frische und live geänderte Marker. Für Übersetzungen umfasst Evidenz Locale-Abdeckung, Qualitäts-Gates, Storage-Zeilen oder Cache-Dateien und, wo verlangt, den Status der muttersprachlichen Prüfung.

Freigabe-Gate

Verwenden Sie nicht eine einzige Freigabe-Haltung für jede Aktion. Die aktuelle Kombinationstabelle des Freigabe-Dokuments reicht vom Auto-Preset (workspace-write-Sandbox mit on-request-Freigaben) über sicheres Read-only-Browsing, nicht-interaktives Read-only-CI und den Auto-Review-Modus bis zum gefährlichen Vollzugriff.⁵ Eine Zeile hinkt der Realität hinterher: Die untrusted-Richtlinie erscheint noch auf der Seite, aber 0.149.0 hat sie zurückgezogen, und explizite Konfigurationen erzeugen jetzt Fehler.²⁵ Für eine Immer-fragen-Haltung kombinieren Sie heute die read-only-Sandbox mit on-request-Freigaben. Eine starke lokale Richtlinie behält dieselbe Form: Risikoarme Lesezugriffe passieren leise, Arbeit mit Nebenwirkungen bekommt Review, und destruktive oder nach außen sichtbare Arbeit bekommt explizite Evidenz.

Git-Custody-Gate

Agentenarbeit braucht Rollback-Griffe. Die Sicherheits-Docs von Codex selbst sagen, Codex funktioniere am besten mit Versionskontrolle: den Status vor dem Delegieren sauber halten, häufig committen, gezielte Verifikation ausführen, Diffs prüfen und Entscheidungen in Commit-Nachrichten dokumentieren.⁵

Dieser Rat sollte Prozess werden. Committen Sie nach kohärenten, verifizierten Sicherungspunkten. Stagen Sie exakte Pfade. Teilen Sie Commits nach unabhängig zurücknehmbaren Anliegen. Fragen Sie vor dem Push, sofern der Release-Ablauf nicht bereits Veröffentlichungsrechte gewährt. Kehren Sie keine fremden schmutzigen Dateien in einen Commit, nur weil der Agent sie zufällig gesehen hat.

Taste-Gate

KI-Coding macht Implementierung billiger. Billigere Implementierung erhöht den Wert von Geschmack.

Geschmack meint keine dekorative Vorliebe. Er meint, dass die Arbeit das Gesamtprodukt verbessert. Er meint, dass der Agent einen technisch möglichen Weg ablehnen kann, der das Ergebnis schwächt. Er meint, dass öffentliches Schreiben private Maschinerie, unbelegte Behauptungen und Füllmaterial vermeidet. Er meint, dass ein korrekter lokaler Patch trotzdem durchfallen kann, wenn der benutzersichtbare Pfad kaputt bleibt.

Ein Taste-Gate sollte fragen:

Was beweist Mozillas Firefox-Arbeit?

Mozillas Beitrag vom 7. Mai über das Härten von Firefox mit Claude Mythos Preview macht denselben Punkt von einem anderen Stack aus. Das Team sagt, frühe Versuche mit LLM-Code-Audits zeigten Potenzial, hatten aber zu viele False Positives, um zu skalieren. Agentische Harnesses änderten die Ökonomie, weil sie reproduzierbare Testfälle erstellen und ausführen konnten, um Bug-Hypothesen dynamisch zu testen.¹⁰

Mozillas wichtiger Satz handelt nicht vom Modell allein. Das Team sagt, die Entdeckung war notwendig, aber nicht hinreichend. Das nützliche System musste sich in den vollständigen Lebenszyklus von Sicherheits-Bugs integrieren: Ziele, Deduplizierung, Bug-Tracking, Triage, Fixes und Release.¹⁰ Die Autoren sagen außerdem, die Pipeline spiegelte die Semantik, das Tooling und die Prozesse der Firefox-Codebasis wider.¹⁰

Das ist die Lektion für Codex. Bessere Modelle zählen. Das operative System um das Modell herum entscheidet, ob aus der Arbeit vertrauenswürdiger Output wird.

Was gehört nicht in öffentliche Texte?

Ein öffentlicher Codex-Artikel sollte nicht das private Arbeitssystem auskippen.

Halten Sie diese Dinge aus öffentlichen Texten heraus:

• private Prompts und Hook-Bodies;
• sensible lokale Pfade;
• exakte Quellenkarten und Scoring-Interna;
• Kontokennungen und den Umgang mit Zugangsdaten;
• private Workflow-Abkürzungen;
• unveröffentlichtes Plugin-Verhalten;
• alles, was einem Fremden hilft, interne Abläufe zu rekonstruieren.

Veröffentlichen Sie stattdessen das Muster: was das Gate schützt, welche Evidenz es verlangt, welchen Fehler es abfängt und wie ein Team die Idee mit offiziellen Codex-Flächen umsetzen kann.

Diese Linie schützt Vertrauen. Sie verbessert auch das Schreiben. Private Maschinerie liest sich meist wie Folklore. Öffentliche Akzeptanzkriterien helfen anderen Teams, über ihre eigenen Systeme nachzudenken.

Wie sieht eine minimale Codex-Harness-Karte aus?

Bauen Sie die kleinste Kontrollkarte, die nützliche Arbeit beweist.

Beginnen Sie explizit. Führen Sie eine echte Aufgabe aus. Halten Sie fest, wo das Gate geholfen hat und wo es im Weg stand. Befördern Sie nur die Teile, die das benutzersichtbare Ergebnis verbessern.

Kurzfassung

Codex-Hooks, Remote-SSH, mobile Steuerung, Sandboxing, Freigaben, Konfiguration, Telemetrie und Versionskontrolle zeigen in dieselbe Richtung: Coding-Agenten brauchen Betriebssysteme um sich herum.²⁴⁵⁶ Der Agent kann Code schreiben. Der Harness entscheidet, was als Arbeit zählt.

Die besten Teams werden nicht gewinnen, indem sie den meisten Agenten-Output produzieren. Sie werden gewinnen, indem sie Agentenarbeit inspizierbar, umkehrbar, belegt, geschmackssicher und veröffentlichungswürdig machen.

FAQ

Was sind Codex-Hooks?

Codex-Hooks führen während der agentischen Schleife Skripte oder MCP-Tools aus, geladen aus hooks.json-Dateien oder Inline-[hooks]-Tabellen in config.toml. Die Docs benennen die Aufgaben klar: Chats an eine Logging-Engine senden, versehentlich eingefügte API-Keys blockieren, Chats zu persistenten Erinnerungen zusammenfassen, Validierung ausführen, wenn ein Turn stoppt, und Prompting pro Verzeichnis anpassen.³ Die Engine registriert mit 0.150.0 zwölf Events, von PreToolUse, PermissionRequest und PostToolUse über Stop bis zum neuen Interrupt; die Dokumentseite listet noch elf, während sie aufholt.³⁷

Warum zählen Codex-Hooks?

Hooks lassen Teams Standards an Entscheidungspunkte setzen, statt sich nur auf Prompts zu verlassen. Ein Hook kann Evidenz, Quellenqualität, Git-Zustand oder Release-Reife prüfen, wenn der Agent handelt oder abzuschließen versucht.

Warum lief mein Hook nicht?

Die übliche Antwort ist Vertrauen. Codex überspringt jeden nicht verwalteten Hook, dessen aktuellen Hash Sie nicht geprüft haben, gibt in interaktiven Sessions eine Startwarnung aus und überspringt in codex exec-Automatisierung still.⁷ Öffnen Sie /hooks, um ihn zu prüfen und ihm zu vertrauen, oder übergeben Sie --dangerously-bypass-hook-trust nur in Pipelines, die Hook-Quellen anderswo prüfen.³

Ersetzt Codex Mobile den lokalen Agenten-Workflow?

Nein. Mobile Steuerung lässt Benutzer Arbeit abseits des Schreibtischs lenken, aber der verbundene Host liefert weiterhin die Projekte, Chats, Dateien, Zugangsdaten, Berechtigungen, Plugins und lokalen Tools.⁴ Teams brauchen weiterhin lokale Richtlinien, sichere Zugangsdaten, Versionskontrolle und Verifikation.

Was sollte ein Codex-Harness zuerst enthalten?

Beginnen Sie mit Projektanweisungen, einer Sandbox- und Freigabe-Haltung, einer Secret-Grenze, einem Evidenz-Stopp-Gate, Git-Custody mit exakten Pfaden, Quellenverifikation für öffentliche Behauptungen und einem Release-Gate für benutzersichtbare Arbeit.

Sollten Teams ihre Codex-Hooks veröffentlichen?

Veröffentlichen Sie Muster und Akzeptanzkriterien, keine privaten Hook-Bodies oder sensiblen Workflow-Details. Ein nützlicher öffentlicher Beitrag kann die Aufgabe eines Hooks erklären, ohne private Pfade, Quellenkarten, Prompts, Zugangsdaten oder Scoring-Regeln offenzulegen.

Referenzen