Codex hat einen Plan.Leg ihn in eine Datei, die du prüfen kannst.

Was /plan in Codex macht

Der Befehl /plan schaltet Codex in den Plan Mode. Statt gleich Code zu schreiben, schlägt Codex zuerst einen Ausführungsplan vor. Die Aufgabe kannst du hinter den Befehl schreiben: /plan Propose a migration plan for this service. Der Befehl ist nicht verfügbar, solange Codex schon an etwas arbeitet; nutze ihn also zu Beginn einer Aufgabe.

Warum der Plan eine Datei sein sollte

Im Plan Mode kommt der Plan als Chat-Nachricht zurück. Die Dokumentation von OpenAI nennt keine Plandatei. Eine Chat-Nachricht lässt sich schlecht prüfen: Sie scrollt weg, du kannst nicht auf einen einzelnen Schritt zeigen, und niemand sonst kann sie lesen.

Eine Datei löst alle drei Probleme. Du kannst eine einzelne Zeile kommentieren, sie mit der Version davor vergleichen, committen und an einen anderen Agenten weitergeben. Verlange den Plan also als Datei, in einem Ordner deiner Wahl.

Der Prompt, der funktioniert

Nachdem Codex seinen Plan vorgeschlagen hat, oder gleich in derselben Anfrage, sag:

Write the plan to plans/<name>.md and send it to me in DotMD for review.

Codex schreibt die Datei und ruft request_review von DotMD auf. Die Datei erscheint in der Seitenleiste unter Needs You, und Codex wartet. Du liest den Plan gerendert, markierst einen Schritt, drückst zum Kommentieren ⌥⌘M und klickst auf Send. Codex bekommt deine Kommentare, korrigiert den Plan und gibt jeden Kommentar zurück. Du übernimmst oder öffnest jede Korrektur wieder und klickst auf Approve, wenn alles stimmt.

Sucht Codex die Kommentare im Projekt, statt sie aus DotMD zu lesen, erwähne DotMD in der Anfrage oder ergänze eine Zeile in AGENTS.md: siehe CLAUDE.md und AGENTS.md.

Codex einmal verbinden

Schalte den MCP-Server in DotMD unter Settings → MCP ein und trage DotMD dann in ~/.codex/config.toml ein:

[mcp_servers.dotmd]
url = "http://127.0.0.1:8089/mcp"
tool_timeout_sec = 3600

Mit tool_timeout_sec wartet Codex, während du liest. Ohne diese Angabe hört Codex nach etwa einer Minute auf zu warten. Starte Codex nach dem Eintrag neu. Die App, die CLI und die IDE-Erweiterung teilen sich eine Einrichtung; die Anleitung für Codex zeigt auch den Weg über die App.

Codex prüft den Plan von Claude Code, und umgekehrt

Zwei Agenten sehen mehr als einer. Lass Claude Code den Plan im Plan Mode schreiben und frag dann Codex: „Prüfe plans/migration.md in DotMD und kommentiere die Schritte, mit denen du nicht einverstanden bist.“ Seine Anmerkungen landen unter seinem eigenen Namen an den genauen Zeilen. Du behältst, änderst oder löschst sie, und Claude Code bekommt nur, was übrig bleibt. Umgekehrt funktioniert es genauso.

Die Agenten sprechen nie miteinander. Alles läuft über die Datei und ihre Kommentare, und du entscheidest. Mehr dazu in Agent prüft Agent.

Was du in einem Codex-Plan prüfen solltest

Einen Plan zu ändern ist billig, eine Implementierung nicht. Lies ihn deshalb einmal mit ein paar Fragen im Kopf:

• Fehlt ein Schritt? Tests, eine Migration, Dokumentation, ein Rollback.
• Stimmt die Reihenfolge? Ein Schritt, der das Ergebnis eines späteren braucht, ist ein Fehler im Plan.
• Stimmt der Umfang? Achte auf Dateien oder Bereiche, die Codex nicht anfassen sollte.

Schreibe jede Anmerkung als Kommentar an den Schritt, um den es geht, und sag, was sich ändern soll. Codex sieht nur deine Kommentare und die Datei, sonst nichts; „Nimm hier den vorhandenen Helper“ ist also besser als „Das ist falsch“. DotMD listet außerdem jede Änderung, um die du nicht gebeten hast, unter Other changes, damit du siehst, ob eine Korrektur weiter ging als nötig.

Fragen zu Codex-Plänen

Weitere Fragen