ChatGPT · Codex auf GitHub und in der IDE

Sie kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Codex ein GitHub-Issue übergeben, sich anderen Dingen widmen und später einen getesteten Pull Request vorfinden, der auf Ihre Freigabe wartet. Diesen Workflow bauen wir in dieser Lektion auf: Codex als Coding-Teamkollege, der in Ihrem Repository und Ihrem Editor arbeitet, statt eines Chatfensters, in das Sie Code hineinkopieren.

Codex ist der Software-Engineering-Agent von OpenAI. Für uns sind drei Einsatzorte relevant:

• die Cloud, in einer Sandbox-Umgebung, die mit Ihren GitHub-Repos verbunden ist
• Ihre IDE, über die offizielle Extension
• die CLI in Ihrem Terminal

Alle drei nutzen denselben Agenten. Sie unterscheiden sich darin, wie viel Autonomie Sie ihm geben. Starten Sie mit der offiziellen Übersicht in der Codex-Dokumentation.

Die zwei Oberflächen: Cloud und lokal

Eine Unterscheidung sollten Sie sich vor allem anderen einprägen.

Cloud-Codex führt jede Aufgabe in einem isolierten Container aus. Es klont Ihr Repo, erhält ein eigenes Dateisystem und hat standardmäßig keinen Internetzugang, während der Agent arbeitet. Hier läuft der Ablauf „Issue zuweisen, PR bekommen“.

Lokales Codex (die IDE-Extension und die CLI) läuft auf Ihrem Rechner, direkt auf Ihrem tatsächlichen Working Tree. Es sieht Ihre nicht committeten Änderungen und Ihr lokales Tooling. Hier arbeiten Sie live gemeinsam an etwas und verfolgen jeden Diff.

Derselbe Agent, unterschiedlicher Blast Radius. Die Cloud ist für das Delegieren abgeschlossener Aufgaben. Lokal ist für die Zusammenarbeit im Moment.

Codex mit GitHub verbinden

Öffnen Sie in ChatGPT Codex und verbinden Sie Ihr GitHub-Konto. Gewähren Sie dann Zugriff auf bestimmte Repositories (nicht auf Ihre gesamte Organisation). Codex installiert eine GitHub App mit eingeschränkten Berechtigungen. Sobald die Verbindung steht, können Sie eine Aufgabe auf jeden beliebigen Branch richten, und Codex kann Pull Requests in diesem Repo ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen →öffnen.

Jedes Repo erhält außerdem eine Codex-Umgebung. In den Umgebungseinstellungen legen Sie das Setup-Skript fest (zum Beispiel pip install -e ".[dev]"), dazu Umgebungsvariablen, Secrets und ob Internetzugang erlaubt ist. Codex führt das Setup-Skript vor jeder Aufgabe aus, damit Tests im Container laufen können.

Installieren Sie in Ihrem Editor die Codex-Extension für VS Code (sie funktioniert auch in Forks wie Cursor und Windsurf). Melden Sie sich mit Ihrem ChatGPT-Konto an. Eine Aufgabe, die Sie aus der IDE starten, können Sie in die Cloud schicken und später im Codex-Dashboard prüfen.

Walkthrough: Issue übernehmen, PR eröffnen

So sieht der Ablauf konkret aus. Angenommen, Ihr Repo hat dieses Issue:

#214: Login-Formular akzeptiert Passwörter, die nur aus Leerzeichen bestehen Nutzer können ein Passwort abschicken, das nur aus Leerzeichen besteht. Validierung und einen Test hinzufügen.

1. Die Aufgabe zuweisen

Wählen Sie in der Codex-Cloud-Ansicht Repo und Branch aus und beschreiben Sie dann die Aufgabe. Am wirkungsvollsten ist es, das Issue einzufügen und auf echte Dateien zu verweisen:

Behebe Issue #214. Lehne in src/auth/validators.py Passwörter ab, die leer sind oder nur aus Leerzeichen bestehen. Folge dem bestehenden ValidationError-Muster, das validate_email verwendet. Füge einen Unit-Test in tests/test_validators.py hinzu.

Codex startet einen Container, führt Ihr Setup-Skript aus, liest die relevanten Dateien und plant. Da die Umgebung in einer Sandbox läuft, kann es Ihre Test-Suite während der Arbeit ausführen.

2. Arbeiten lassen, dann den Diff lesen

Codex bearbeitet die Dateien, führt die Tests aus und iteriert, wenn etwas fehlschlägt. Am Ende erhalten Sie eine Zusammenfassung: was geändert wurde, welche Befehle liefen und die Testausgabe. Lesen Sie den Diff. Behandeln Sie ihn genau wie den PR eines Junior Engineers. Der Agent ist schnell und unermüdlich, und trotzdem macht er Fehler.

3. Den Pull Request eröffnen

Wenn der Diff stimmt, eröffnen Sie den PR direkt aus Codex. Es schreibt Titel und Beschreibung, verweist auf Issue #214 und pusht einen Branch. Ihre Branch Protections, Pflicht-Reviewer und CI gelten weiterhin. Nichts wird gemergt, ohne dass Ihre bestehenden Regeln erfüllt sind.

Das ist der Loop: Issue rein, geprüfter PR raus, und Sie entscheiden über die Freigabe.

Direkt aus GitHub arbeiten

Sie können auch in GitHub starten. Sobald Codex verbunden ist, kommentieren Sie @codex review in einem Pull Request, und Codex postet ein Code Review, das Bugs und riskante Änderungen markiert, so wie es ein Reviewer tun würde. Erwähnen Sie @codex mit einer Anweisung (zum Beispiel @codex fix the failing test in tests/test_validators.py), und es startet eine Cloud-Aufgabe in der Umgebung dieses Repos. Sie können in den Codex-Einstellungen auch automatische Reviews für ein Repo aktivieren, sodass jeder neue PR einen ersten Durchgang bekommt, bevor ein Mensch ihn ansieht.

Codex Ihr Projekt mit AGENTS.md beibringen

Codex kennt Ihre Konventionen nicht von selbst. Sie bringen sie ihm einmal bei, in einer Datei, die es automatisch liest: `AGENTS.md` im Root des Repos. Es ist einfaches Markdown, eine README, die für den Agenten statt für Menschen geschrieben ist. Es gibt kein spezielles SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen →. Überschriften und kurze Aufzählungspunkte funktionieren am besten.

Eine gute AGENTS.md sagt Codex, wie es Checks ausführt, welchen Konventionen es folgt und was es nicht anfassen darf. Halten Sie sie kurz und sachlich.

# AGENTS.md

## Testing and checks
- Run tests with `pytest -q`.
- Lint with `ruff check .` and type-check with `mypy src/`.
- All three must pass before you propose a PR.

## Conventions
- Follow PEP 8; format with ruff.
- New functions need type hints and a docstring.
- Tests go in tests/ and mirror the src/ path.

## Off-limits
- Never edit files under migrations/ by hand.

Damit führt Codex Ihre echten Checks aus und hält sich aus Verzeichnissen heraus, die Sie gesperrt haben. Schlägt pytest fehl, sieht es den Fehler und versucht es erneut, bevor es Ihnen den PR übergibt. Sie bekommen weniger PRs, die CI brechen, sobald sie ankommen.

Zwei Details bringen Leute oft durcheinander. Die Installation von Abhängigkeiten für Cloud-Aufgaben gehört in das Setup-Skript der Umgebung, nicht in AGENTS.md. Und in einem Monorepo können Sie verschachtelte AGENTS.md-Dateien in Unterverzeichnissen ablegen: Die Datei, die der bearbeiteten Datei am nächsten liegt, hat Vorrang. Dieselbe Datei lesen auch die IDE-Extension und die CLI, sodass lokale und Cloud-Läufe denselben Regeln folgen.

Codex in der IDE: live zusammenarbeiten

Der Cloud-Ablauf ist Delegation. Der IDE-Ablauf ist Zusammenarbeit, und darauf greifen Sie zurück, wenn Sie der Arbeit zusehen wollen.

Öffnen Sie in VS Code mit der Codex-Extension die Codex-Seitenleiste und beschreiben Sie eine Änderung an Ihrem geöffneten Projekt. Eine typische lokale Aufgabe:

Refaktoriere OrderService.process, sodass die Rabattlogik in eine Klasse DiscountCalculator ausgelagert wird. Behalte das Verhalten identisch bei und aktualisiere die bestehenden Tests.

Der Unterschied zur Cloud sind die Freigaben. Lokales Codex läuft in Modi, die steuern, wie viel es ohne Rückfrage tun darf:

• Read only: Es liest und macht Vorschläge, und Sie entscheiden, was übernommen wird.
• Agent (Standard): Es bearbeitet Dateien und führt Befehle im Workspace aus und fragt nach, bevor es den Workspace verlässt oder das Netzwerk nutzt.
• Full access: Es bearbeitet, führt Befehle aus und greift ohne Rückfrage auf das Netzwerk zu.

Für die tägliche Arbeit ist der Standardmodus Agent der beste Kompromiss. Codex nimmt Änderungen vor, führt Ihre Tests aus und hält an, um nachzufragen, bevor es irgendetwas außerhalb des Workspace tut. Sie bleiben im Loop, ohne jeden Tastenanschlag freigeben zu müssen.

Die IDE eignet sich auch gut, um Code zu verstehen. Markieren Sie eine verzwickte Funktion, bitten Sie Codex, sie zu erklären oder Tests dafür zu schreiben, und es arbeitet mit der Live-Datei und dem vollen Projektkontext. Wird eine Aufgabe größer als erwartet, übergeben Sie sie aus der Extension an die Cloud und arbeiten lokal weiter.

Sicherheitsmechanismen, die Sie wirklich nutzen sollten

Codex kommt mit konservativen Standardeinstellungen, damit Sie diese bewusst lockern. Das sind die tatsächlichen Stellschrauben.

Sandboxing und Netzwerk

Cloud-Aufgaben laufen während der Agentenphase ohne Internetzugang, es sei denn, Sie aktivieren ihn für diese Umgebung. Eine Aufgabe kann also nicht unbemerkt Code abfließen lassen oder nicht vertrauenswürdige Pakete laden. Muss Ihr Build während der Aufgabe etwas herunterladen, aktivieren Sie den Zugang und beschränken ihn auf eine Allowlist von Domains (etwa Paket-Registries). Breiter Internetzugang sollte eine bewusste Entscheidung sein.

Freigaben sind Ihr Notschalter

In den lokalen Modi ist die Freigabeabfrage Ihre wichtigste Sicherheitsfunktion. Befehle, die über den Workspace hinaus oder ins Netzwerk gehen, werden zur Bestätigung vorgelegt. Widerstehen Sie der Versuchung, bei einem wichtigen Repo alles auf Full access zu stellen. Volle Autonomie gehört auf Wegwerf-Branches und in Experimente.

Branch Protection erledigt die Hauptarbeit

Codex respektiert Ihr GitHub-Setup. Jede Änderung kommt als PR auf einem Branch an, daher entscheiden Ihre Pflicht-Reviews, Status Checks und CODEOWNERS-Regeln weiterhin über den Merge. Der Agent kann einen PR eröffnen. Einen geschützten main kann er nicht umgehen. Deshalb ist das PR-Muster sicherer, als ein Tool direkt pushen zu lassen: Ihr menschlicher Review-Prozess bleibt unverändert. Ein @codex review-Kommentar fügt einen Reviewer hinzu. Er ersetzt Ihre menschlichen Reviewer nicht.

Secrets gehören nicht in den Prompt

Fügen Sie keine APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen →-Keys oder Zugangsdaten in Aufgabenbeschreibungen oder in AGENTS.md ein. Für Cloud-Umgebungen, die Secrets brauchen, nutzen Sie die Secrets-Einstellungen der Umgebung. Secrets stehen dem Setup-Skript zur Verfügung und werden entfernt, bevor der Agent zu arbeiten beginnt. Ein Grund mehr, sie dort aufzubewahren.

Die GitHub App eingrenzen

Beim Verbinden mit GitHub haben Sie Zugriff auf bestimmte Repos gewährt. Belassen Sie es dabei. Prüfen Sie die freigegebenen Repos alle paar Monate in Ihren GitHub-Einstellungen und entfernen Sie die, die Codex nie anfasst.

Das mentale Modell: Cloud, Sandbox und PR-Review für delegierte Arbeit, der Sie nicht zusehen; lokal plus Freigaben für Arbeit, der Sie zusehen. In beiden Fällen entscheiden Ihre bestehenden GitHub-Regeln über den Merge. Schwächen Sie diese nie ab, um den Agenten schneller zu machen.

Wann Sie welche Oberfläche nutzen

Eine kurze Entscheidungshilfe:

• Ein klar definiertes, abgeschlossenes Issue: Cloud-Codex. Zuweisen, etwas anderes tun, den PR prüfen.
• Ein exploratives Refactoring, das Sie steuern wollen: die IDE-Extension im Agent-Modus.
• Eine skriptfähige, wiederholbare Aufgabe in CI oder einem Terminal-Workflow: die Codex CLI (codex exec führt sie nicht interaktiv aus).
• Eine zweite Meinung zum PR eines Kollegen: @codex review auf GitHub kommentieren.
• Ein Stapel kleiner Routineaufgaben (Versionen anheben, Lint-Fehler über mehrere Dateien beheben): Cloud, je eine Aufgabe, dann den Stapel PRs prüfen.

Die Kunst besteht darin, die Oberfläche danach zu wählen, wie sehr Sie der Aufgabe zutrauen, unbeaufsichtigt zu laufen. Umgebungsoptionen und Limits ändern sich häufig, halten Sie also die Codex-Dokumentation und das Help Center griffbereit.

Das Wichtigste in Kürze

• Steuern Sie den Loop, nicht die Tastatur. Weisen Sie ein GitHub-Issue mit konkreten Dateiverweisen zu, lassen Sie Cloud-Codex einen PR erstellen und prüfen Sie ihn wie die Arbeit eines Kollegen.
• Schreiben Sie eine AGENTS.md in einfachem Markdown: wie getestet und gelintet wird, welchen Konventionen gefolgt wird, welche Verzeichnisse tabu sind. Die Installation von Abhängigkeiten gehört ins Setup-Skript der Umgebung.
• Nutzen Sie GitHub direkt, wenn es schneller geht: @codex review in einem PR für ein Code Review oder @codex plus Anweisung, um eine Aufgabe zu starten.
• Wählen Sie die Oberfläche nach Autonomie. Cloud für delegierte, abgeschlossene Aufgaben; die IDE-Extension für Live-Zusammenarbeit, bei der Sie zusehen und freigeben.
• Lassen Sie Cloud-Aufgaben offline, sofern sie keinen Zugang brauchen, bewahren Sie Secrets in den Secrets-Einstellungen auf und reservieren Sie Full access für Wegwerf-Branches. Ihre Branch-Protection-Regeln bleiben das letzte Tor vor main.