Was ist OpenAI Codex?

Codex ist der Codierungsagent von OpenAI. Er liest ein Repository, plant Änderungen, bearbeitet Dateien, führt Befehle in einer Sandbox aus und liefert Ihnen einen Diff zur Überprüfung – über vier Schnittstellen mit derselben Konfiguration: die Codex-App, eine IDE-Erweiterung, eine CLI und eine Cloud-/Webumgebung für länger laufende oder Hintergrundaufgaben. Da alle vier dieselben Daten lesen, … ~/.codex Eine einmal eingerichtete Konfiguration, ein MCP-Server oder ein Plugin, wird Ihnen sowohl im Terminal als auch in der IDE zur Verfügung gestellt.

Zusamenfassend: Codex ist weniger ein einzelnes Werkzeug als vielmehr eine Laufzeitumgebung – ein Ort, an dem Fähigkeiten, App-Verbindungen und MCP-Server um eine Codierungsaufgabe herum zusammengeführt werden, anstatt dass Sie in jedem Projekt dasselbe Setup neu aufbauen müssen.

Warum Entwickler Codex einsetzen

Die meisten Vergleiche von „KI-Programmierassistenten“ konzentrieren sich auf die Modellqualität, doch die interessantere Veränderung ist struktureller Natur. Codex trennt drei Dinge, die zuvor in einer einzigen großen Systemeingabeaufforderung zusammengefasst waren: Anweisungen (AGENTS.md), wiederverwendbare Verfahren (Fähigkeiten) und Werkzeugzugriff (Apps und MCP-Server). Diese Trennung ermöglicht Plugins – ein Plugin ist lediglich ein Paket dieser drei Komponenten, das man als Einheit installieren und deinstallieren kann, anstatt in jeden neuen Chat Standardcode einzufügen.

Das praktische Ergebnis: Ein Team kann standardisieren, wie Codex Pull Requests prüft, Sentry-Issues liest oder Dokumentationsentwürfe erstellt, und diesen Standard als installierbares Paket anstatt als Wiki-Seite veröffentlichen, die niemand liest.

Installation und Konfiguration von Codex

Die Befehlszeilenschnittstelle (CLI) ist der schnellste Ort, um die Auswirkungen der Konfiguration zu sehen. Codex speichert die Einstellungen in ~/.codex/config.toml standardmäßig (überschreiben mit CODEX_HOME für ein projektspezifisches Profil).

# Plugin-Browser im CLI-Codex öffnen /plugins # MCP-Server direkt über den CLI-Codex hinzufügen mcp add context7 -- npx -y @upstash/context7-mcp # Aktive MCP-Server in einer laufenden Sitzung anzeigen /mcp

Für eine detaillierte Steuerung – Timeouts, Werkzeug-Zulassungslisten, Genehmigungsmodi pro Werkzeug – bearbeiten config.toml direkt. Hier ist ein minimaler, realistischer Block für einen streamfähigen HTTP-MCP-Server:

[mcp_servers.figma] url = "https://mcp.figma.com/mcp" bearer_token_env_var = "FIGMA_OAUTH_TOKEN" [mcp_servers.figma] startup_timeout_sec = 20 tool_timeout_sec = 45

Plugins vs. Fähigkeiten vs. Apps vs. MCP

Diese vier Begriffe werden in Marketingtexten oft synonym verwendet, weshalb Anfänger häufig Schwierigkeiten haben. Hier ist der entscheidende Unterschied, wenn Sie entscheiden, was Sie installieren möchten.

Wenn also jemand sagt „Installiere das GitHub-Plugin“, kann das, was tatsächlich auf Ihrem Rechner landet, eine Fähigkeit, eine App-Verbindung, ein MCP-Server oder alle drei sein – das Plugin ist nur die Hülle, die es installierbar und teilbar macht.

Das Plugin-Verzeichnis

Codex ordnet Plugins in drei Gruppen ein, egal ob Sie sie in der App oder in der Befehlszeile durchsuchen:

• Zusammengestellt von OpenAI — überprüfte Plugins, die allen Codex-Benutzern zur Verfügung stehen.
• Mit Ihnen geteilt — Plugins, die ein anderes Mitglied Ihres ChatGPT-Arbeitsbereichs intern veröffentlicht hat.
• Von Ihnen erstellt — Plugins, die Sie selbst erstellt und Ihrem eigenen Arbeitsbereich hinzugefügt haben.

Die Installation erfolgt überall gleich: Öffnen Sie die Detailseite eines Plugins und wählen Sie „Installieren“ (oder Plugin installieren Verbinden Sie in der Befehlszeile (CLI) bei Aufforderung alle benötigten externen Anwendungen und starten Sie anschließend einen neuen Thread, bevor Sie diese verwenden. Ihre bestehenden Genehmigungseinstellungen bestimmen weiterhin, welche Aktionen das Plugin nach der Veröffentlichung ausführen darf – die Installation gewährt keine uneingeschränkten Berechtigungen.

Um ein Plugin zu deaktivieren, ohne es zu entfernen, ändern Sie dessen Eintrag in der Datei. config.toml:

[plugins."gmail@openai-curated"] enabled = false

Das Codex-Plugin-Ökosystem

Zum jetzigen Zeitpunkt konzentriert sich das von OpenAI kuratierte Verzeichnis auf eine ausgewählte Gruppe von Tools anstatt auf einen umfangreichen App-Store-Katalog – eine bewusste Entscheidung, da jedes kuratierte Plugin geprüft wurde. Plugins von Drittanbietern und aus dem Arbeitsbereich selbst gehen weit über diese Liste hinaus, bieten aber unterschiedliche Vertrauensgarantien. Daher ist es wichtig, die Unterschiede zu kennen.

Wie man eine Plugin-Karte liest

Jedes Plugin in diesem Leitfaden ist mit der Art der Vertrauensgrenze gekennzeichnet, hinter der es sich befindet:

Entwicklung

Dokumentation & Design

Produktivität

Debugging

Einsatz

GitHub-Integration

GitHub wird bevorzugt behandelt, da Codex sowohl ein speziell angepasstes Plugin als auch eine tiefere Integration direkt für GitHub bereitstellt – plus eine dedizierte GitHub-Aktion für CI-gesteuerte Ausführungen. In der Praxis bedeutet das drei separate Einstiegspunkte: Codex kann über die GitHub-Benutzeroberfläche einem Issue zugewiesen, über die Befehlszeile für ein ausgechecktes Repository aufgerufen oder über eine Workflow-Datei bei jedem Pull Request ausgelöst werden. Teams, die Codex für Code-Reviews standardisieren, beginnen üblicherweise mit der Aktion, da diese nicht erfordert, dass jeder Mitwirkende Codex lokal konfiguriert hat.

Figma-Integration

Figma verbindet sich über den eigenen MCP-Server mit Codex, anstatt über eine Codex-seitige Integration – sowohl lokal (Desktop-App) als auch remote (gehostet). Dies ist ein Paradebeispiel für das Plugin-Modell: OpenAI musste keine Figma-spezifischen Tools entwickeln, sondern lediglich MCP zuverlässig unterstützen; den Rest erledigt der Figma-Server. Der Nachteil: Serververhalten, Ratenbegrenzungen und Zuverlässigkeit liegen außerhalb der Kontrolle von OpenAI.

Begriffsintegration

Das speziell entwickelte Notion-Plugin vereint Lese- und Schreibzugriffe auf Seiten und Datenbanken mit Funktionen, die optimal auf die Umwandlung von Entwicklungsergebnissen – Commit-Logs, PR-Zusammenfassungen, Incident-Timelines – in strukturierte Notion-Inhalte abgestimmt sind. Für Teams, die Notion bereits als zentrale Entscheidungsgrundlage nutzen, ist dies ein klarer Vorteil, da der manuelle Aktualisierungsschritt entfällt.

Slack-Integration

Ähnlich wie GitHub bietet auch Slack sowohl ein speziell entwickeltes Plugin als auch eine tiefere native Integration. Der praktische Unterschied zeigt sich in latenzkritischen Arbeitsabläufen: Native Integrationen unterstützen in der Regel komplexere Auslöser (z. B. einen Codex-Lauf, der durch eine Slack-Nachricht gestartet wird, und nicht nur einen Codex-Beitrag in Slack), während ein Plugin allein typischerweise nur in eine Richtung – von Codex zum Kanal – funktioniert.

Sentry-Integration

Sentry ist wohl das wirkungsvollste Plugin für Teams, die bereits schnell arbeiten, da es die Schritte „Fehler erkennen → Stacktrace finden → Commit finden → Lösung vorschlagen“ in einer einzigen Dialogschleife zusammenfasst. Der Haken: Codex schlägt auch für veraltete oder doppelte Probleme eine Lösung vor, wenn die Abfrage nicht genauer spezifiziert wird (offene Probleme, letzte 24 Stunden, bestimmtes Projekt). Daher ist die Genauigkeit der Abfrage hier wichtiger als fast überall sonst in diesem Leitfaden.

Browserautomatisierung

Für alle Funktionen, die im Browser und nicht über eine API ablaufen – wie die visuelle Überprüfung von UI-Änderungen, das Auslesen von Seiten ohne öffentliche API oder die Steuerung von Anmeldevorgängen – greift Codex auf Browser-MCP-Server anstatt auf ein dediziertes Browser-Plugin zurück. Die Dokumentation hebt insbesondere Playwright und die Chrome-Entwicklertools hervor, die beide über MCP steuerbar sind. Die Codex-App enthält außerdem einen eigenen In-App-Browser und eine Chrome-Erweiterung für einen engeren Ablauf zwischen Seitenansicht und Codebearbeitung.

Terminal-Workflow

Die CLI ist der Ort, an dem die Plugin- und MCP-Konfiguration im Alltag tatsächlich durchgeführt wird. Einige Befehle, die man sich merken sollte:

/plugins # Plugins im Marketplace durchsuchen, installieren und aktivieren/deaktivieren /mcp # Aktive MCP-Server in dieser Sitzung auflisten codex mcp add # Neuen MCP-Server über die Shell hinzufügen codex mcp --help

Drücken Sie in den Tabs des Marktplatzes im Plugin-Browser die entsprechende Schaltfläche. Raum Bei einem installierten Plugin wird dieses für die aktuelle Sitzung ein- oder ausgeschaltet – nützlich, wenn Sie ein Plugin als Ursache eines unerwarteten Tool-Aufrufs ausschließen möchten, ohne es vollständig zu deinstallieren.

AGENTS.md

Die Datei AGENTS.md ist der am meisten unterschätzte Hebel in den meisten Codex-Konfigurationen. Codex liest sie, bevor er mit der eigentlichen Arbeit beginnt, und erstellt daraus eine Befehlskette. ~/.codex/AGENTS.md durchläuft jedes Verzeichnis zwischen dem Projektstammverzeichnis und dem aktuellen Arbeitsverzeichnis – wobei jede verschachtelte Datei die darüber liegenden Dateien überschreibt.

# AGENTS.md ## Erwartungen an das Repository - Führe `npm run lint` aus, bevor du einen Pull Request erstellst. - Dokumentiere öffentliche Hilfsprogramme in docs/, wenn du das Verhalten änderst.

Verschachtelt AGENTS.override.md Mit diesen Dateien kann ein bestimmtes Unterverzeichnis (z. B. ein Zahlungsdienst mit strengeren Regeln) die darüber liegenden Anweisungen vollständig ersetzen, anstatt sie zu ergänzen – nützlich in Monorepos, wo „Tests ausführen“ in jedem Paket etwas anderes bedeutet.

Erinnerung

Das lokale Speichersystem von Codex ist vom Web-Speicher von ChatGPT getrennt und standardmäßig deaktiviert. Nach der Aktivierung kann Codex den Kontext von inaktiven, berechtigten vergangenen Sitzungen in lokale Speicherdateien umwandeln. ~/.codex/memories/Dabei werden Geheimnisse fortlaufend geschwärzt und kurzlebige Chats übersprungen, damit keine noch laufende Arbeit zusammengefasst wird.

[features] memories = true

Zwei Einstellungen, die man kennen sollte: memories.use_memories steuert, ob vergangene Erinnerungen in neue Sitzungen einfließen, und memories.disable_on_external_context Dadurch werden Chats, die auf Web-Suchen oder MCP-Tool-Aufrufen basieren, vollständig aus der Speichergenerierung herausgehalten – praktisch, wenn Sie nicht möchten, dass eine Sentry-Triage-Sitzung den Speicher mit dem Stack-Trace einer anderen Person verschmutzt.

Prompt-, Kontext- und Schleifenentwicklung

Drei verwandte, aber unterschiedliche Fähigkeiten unterscheiden die Entwickler, die gegen Codex ankämpfen, von den Entwicklern, die damit einen Backlog im Handumdrehen abarbeiten.

Schnelle Entwicklung

Sagen Sie, was geändert werden soll und wie das Ergebnis aussieht, nicht nur die Symptome. „Den fehlerhaften Checkout-Test beheben“ ist weniger aussagekräftig als „Der Checkout-Test schlägt sporadisch bei der Rabattcode-Prüfung fehl – ​​reproduzieren Sie den Fehler, finden Sie die Race Condition und fügen Sie einen Regressionstest hinzu.“

Kontextgestaltung

Hier geht es darum, worauf Codex Zugriff hat, nicht darum, was Sie eingeben: den richtigen AGENTS.md-Bereich, die richtigen aktivierten MCP-Server, die richtigen geöffneten Dateien. Selbst eine perfekt formulierte Eingabeaufforderung schlägt fehl, wenn Codex die Konfigurationsdatei nicht finden kann, die das gewünschte Verhalten steuert.

Schleifentechnik

Die Praxis, wiederholbare Zyklen aus Vorschlag → Ausführung → Prüfung → Wiederholung anstelle von einmaligen Eingabeaufforderungen zu entwerfen – beispielsweise Codex so zu konfigurieren, dass die Testsuite nach jeder Änderung ausgeführt und so lange wiederholt wird, bis sie erfolgreich ist, anstatt jeden Versuch manuell zu überprüfen –, ist gängig. Das Codex-Kochbuch dokumentiert dieses Muster direkt für iterative Reparaturschleifen.

Workflows mit mehreren Agenten und Subagenten

Codex unterstützt Subagenten – Agenteninstanzen mit definiertem Aufgabenbereich, an die eine primäre Codex-Sitzung bestimmte Aufgaben delegieren kann. Der praktische Anwendungsfall besteht in der Parallelisierung unabhängiger Arbeitsschritte: Ein Subagent führt die Testsuite aus und meldet das Ergebnis zurück, während die primäre Sitzung die Bearbeitung fortsetzt, anstatt dass ein Agent alles nacheinander abarbeitet. Dies ist eine neuere und fortschrittlichere Schnittstelle als Plugins oder MCP und sollte als Optimierung betrachtet werden, sobald Ihr Single-Agent-Workflow bereits zuverlässig ist – nicht als Ausgangspunkt.

Reale Arbeitsabläufe, Schritt für Schritt

1. Erstellen Sie eine React-Anwendung mit Codex

Erstellen Sie zunächst ein Gerüst mit einer übersichtlichen AGENTS.md-Datei (Paketmanager, Testbefehl) und fordern Sie anschließend die gewünschten Funktionen anhand ihrer Ergebnisse an. Fordern Sie Tests parallel zur Komponente an, nicht erst im Nachhinein.

2. Beheben Sie Produktionsfehler mithilfe des Sentry-Plugins.

Den Umfang der Abfrage festlegen, vor einer Korrektur nach der Ursache fragen und einen Regressionstest im selben Diff verlangen.

3. Benutzeroberfläche direkt aus Figma generieren

Codex sollte auf einen bestimmten Frame und nicht auf eine ganze Datei ausgerichtet werden – große Dateien verlangsamen die MCP-Inspektion und erhöhen die Wahrscheinlichkeit, dass nicht zugehörige Komponenten miteinbezogen werden.

4. Dokumentation aus GitHub-Commits schreiben

5. Refaktorisierung einer bestehenden Codebasis

Bitten Sie um einen Plan, bevor Sie programmieren. Bei Legacy-Refactorings zeigt sich der wahre Wert von Schleifenoptimierung – lassen Sie Codex ein Modul refaktorisieren, führen Sie die Testsuite aus und fahren Sie erst fort, wenn sie erfolgreich war.

6. Pull-Anfragen automatisch überprüfen

Die GitHub-Aktion ist hier der richtige Ansatzpunkt – sie löst bei jedem Pull Request eine Codex-Überprüfung aus, anstatt sich darauf zu verlassen, dass jemand daran denkt, diese manuell anzufordern.

7. SQL-Migrationen generieren

Ohne ein speziell dafür entwickeltes Datenbank-Plugin läuft dies typischerweise über einen projektbezogenen MCP-Server für Ihre Datenbank, wobei die Migration immer manuell überprüft und angewendet und nicht automatisch ausgeführt wird.

8. Bereitstellung auf Vercel

Auch wenn Testbereitstellungen zur Routine geworden sind, sollte für Produktionsbereitstellungen weiterhin ein manueller Genehmigungsschritt erforderlich sein.

Bewährte Verfahren

Von der

• Halten Sie AGENTS.md klar definiert und präzise – eine eindeutige Regel ist besser als fünf vage.
• Neue Plugins starten in prompt Genehmigungsmodus vor dem Wechsel zu AutoDie
• Deinstallieren Sie Plugins, die Sie nicht aktiv nutzen – jedes installierte Tool stellt eine Angriffsfläche dar.
• Beschränken Sie die MCP-Server-Zugangsdaten auf das für die jeweilige Aufgabe erforderliche Minimum.

Was man nicht tun sollte

• Verlassen Sie sich bei Regeln, die immer gelten müssen, nicht auf Ihr Gedächtnis – verwenden Sie AGENTS.md.
• Gewähren Sie einem Plugin keine Schreibrechte für die Produktionsumgebung, „um einen Schritt zu speichern“ – denn der gespeicherte Schritt ist derjenige, der Fehler aufdeckt.
• Stapeln Sie nicht zusammengehörige MCP-Server nicht in einer Sitzung, nur weil sie installiert sind – jeder einzelne fügt dem Kontext Tokens hinzu und erhöht die Wahrscheinlichkeit von Tool-Verwirrung.

Fehler, die Anfänger machen

• Die Installation eines Plugins als einmalige Entscheidung zu behandeln, anstatt die Berechtigungen im Laufe der Projektentwicklung erneut zu überprüfen.
• Schreibanregungen, die das Symptom anstatt des gewünschten Endzustands beschreiben.
• Die Datei AGENTS.md wird komplett übersprungen und die Projektkonventionen werden in jeder einzelnen Eingabeaufforderung erneut erläutert.

Checkliste für die Repository-Organisation

• Eine AGENTS.md-Datei auf Stammebene mit Testbefehlen, Paketmanager und verbotenen Aktionen
• Verschachtelte AGENTS.override.md-Dateien werden nur dann verwendet, wenn sich ein Unterverzeichnis tatsächlich unterscheidet.
• Projektumfang .codex/config.toml für MCP-Server, die speziell für dieses Repository gelten
• Eine kurze Liste der für dieses Repository zugelassenen Plugins und deren Begründung

Häufig gestellte Fragen

Abschluss

Das Plugin-System macht Codex von einer sehr guten Autovervollständigung zu einem Agenten, der sich nahtlos in die Tools Ihres Teams – GitHub, Figma, Sentry, Slack, Notion – integrieren lässt, ohne dass Sie zusätzlichen Code dafür schreiben müssen. Das ersetzt jedoch nicht Ihr Urteilsvermögen: Überprüfen Sie die Änderungen, legen Sie die Genehmigungsmodi fest und halten Sie die AGENTS.md-Datei stets aktuell. Beginnen Sie mit einem Plugin, das Ihnen eine alltägliche Ärgernis erspart, machen Sie sich mit den Genehmigungseinstellungen vertraut und erweitern Sie Ihr Angebot nach und nach. Der Workflow, der Ihnen am meisten Zeit spart, ist selten der komplexeste – es ist der, den Sie tatsächlich nutzen.