+180 XP

Codex auf GitHub und in der IDE

# Codex auf GitHub und in der IDE

Sie können Codex ein GitHub-Issue übergeben, weggehen und mit einem geprüften, getesteten Pull Request zurückkommen, der auf Ihre Freigabe wartet. Genau diesen Workflow bauen wir in dieser Lektion: Codex als Coding-Teamkollege, der in Ihrem Repository und Ihrem Editor lebt, nicht als Chat-Fenster, in das Sie Code hinein- und herauskopieren.

Codex ist der Software-Engineering-Agent von OpenAI. Er läuft an drei Stellen, die hier relevant sind: in der Cloud (eine Sandbox-Umgebung, die mit Ihren GitHub-Repos verbunden ist), in Ihrer IDE (über die offizielle Extension) und in der CLI / im Terminal. Alle nutzen denselben Agenten, unterscheiden sich aber darin, wie viel Autonomie Sie gewähren. Starten Sie mit der offiziellen Übersicht in den Codex-Docs.

Die zwei Surfaces: Cloud und lokal

Eine Unterscheidung sollten Sie vor allem anderen verinnerlichen.

Cloud Codex führt jede Aufgabe in einem isolierten Container aus. Der Agent klont Ihr Repo, bekommt ein eigenes Dateisystem und hat während der Aufgabe standardmäßig keinen Netzwerkzugriff. Hier lebt der Flow „Issue zuweisen, PR erhalten“.

Lokales Codex (die IDE-Extension und die CLI) läuft auf Ihrer Maschine, gegen Ihren echten Working Tree. Es sieht Ihre uncommitteten Änderungen und Ihr lokales Tooling. Hier arbeiten Sie live im Pairing, und Sie sehen jeden Diff.

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

Codex mit GitHub verbinden

Öffnen Sie in ChatGPT Codex, verbinden Sie Ihren GitHub-Account und geben Sie dann Zugriff auf bestimmte Repositories frei (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 Branch richten, und Codex kann Pull Requests zurück in dieses Repo öffnen.

Installieren Sie in Ihrem Editor die Codex Extension für VS Code (und Forks wie Cursor) oder das JetBrains-Plugin. Melden Sie sich mit Ihrem ChatGPT-Account an. Die Extension teilt Ihre Codex-Umgebung, eine in der IDE gestartete Aufgabe lässt sich also später im Cloud-Dashboard einsehen.

Durchlauf: ein Issue aufnehmen, einen PR öffnen

Hier der konkrete Ablauf. Nehmen wir an, 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 Test ergänzen.

1. Aufgabe zuweisen

Wählen Sie in der Codex-Cloud-Ansicht Repo und Branch aus und beschreiben Sie dann die Aufgabe. Das Wirksamste, was Sie tun können: das Issue einfügen und auf echte Dateien verweisen:

> Behebe Issue #214. In src/auth/validators.py sollen Passwörter abgewiesen werden, die leer sind oder nur aus Whitespace bestehen. Halte dich an das bestehende ValidationError-Muster, das validate_email verwendet. Ergänze einen Unit-Test in tests/test_validators.py.

Codex startet einen Container, liest die relevanten Dateien und plant. Weil die Umgebung eine Sandbox ist, kann der Agent Ihre Testsuite 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 bekommen Sie eine Zusammenfassung: was geändert wurde, welche Kommandos gelaufen sind und die Testausgabe. Lesen Sie den Diff. Behandeln Sie ihn genau wie den PR eines Junior-Engineers: der Agent ist schnell und unermüdlich, nicht unfehlbar.

3. Den Pull Request öffnen

Wenn der Diff passt, öffnen Sie per Klick direkt aus Codex einen PR. Codex schreibt Titel und Beschreibung, verlinkt Issue #214 und pusht einen Branch. Ihre üblichen 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, mit Ihnen als Gate.

Codex: assign a GitHub issue and review the PR

Watch on YouTube

Die Umgebung mit AGENTS.md konfigurieren

Codex kennt die Konventionen Ihres Projekts nicht von Zauberhand. Sie bringen sie ihm einmal bei, in einer Datei, die er automatisch liest: AGENTS.md im Repo-Root. Denken Sie daran wie an eine README, die für den Agenten statt für Menschen geschrieben ist.

Eine gute AGENTS.md sagt Codex, wie Dependencies installiert werden, wie Tests laufen und welche Konventionen gelten. Halten Sie sie knapp und sachlich.

yaml
# AGENTS.md (front-matter style config Codex reads)
setup:
  - pip install -e ".[dev]"

checks:
  test: pytest -q
  lint: ruff check .
  typecheck: mypy src/

conventions:
  - Follow PEP 8; format with ruff before committing.
  - All new functions need type hints and a docstring.
  - Tests go in tests/ and mirror the src/ path.
  - Never edit files under migrations/ by hand.

before_pr:
  - Run test, lint, and typecheck. All must pass.

Mit dieser Datei installiert Codex korrekt, führt Ihre echten Checks aus und rührt Verzeichnisse nicht an, die Sie gesperrt haben. Wenn pytest fehlschlägt, sieht der Agent den Fehler und versucht es erneut, bevor er Ihnen den PR übergibt. Das Ergebnis: weniger PRs, die CI sofort brechen.

Für Monorepos können Sie zusätzlich verschachtelte AGENTS.md-Dateien in Unterverzeichnissen ablegen; für Dateien in einem Pfad gilt die nächstgelegene.

Codex in der IDE: live im Pairing

Der Cloud-Flow ist Delegation. Der IDE-Flow ist Zusammenarbeit, und Sie greifen darauf zurück, wenn Sie die Arbeit mitverfolgen wollen.

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

> Refaktoriere OrderService.process und ziehe die Rabattlogik in eine Klasse DiscountCalculator. Verhalten identisch halten und die bestehenden Tests aktualisieren.

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

  • Read-only / suggest: schlägt Diffs vor, Sie wenden sie an.
  • Auto / agent: bearbeitet Dateien und führt Kommandos aus, fragt aber vor riskanten Schritten nach.
  • Full access: bearbeitet und führt im Workspace frei aus.

Für die tägliche Arbeit ist der mittlere Modus der Sweet Spot. Codex macht Änderungen und führt Ihre Tests aus, hält aber inne und fragt, bevor es etwa Dateien löscht oder ein Kommando ausführt, das nicht vorab freigegeben ist. Sie bleiben im Loop, ohne jeden Tastendruck zu bewachen.

Der IDE-Flow spielt auch beim Verstehen von Code seine Stärken aus. Markieren Sie eine sperrige Funktion, lassen Sie sie von Codex erklären oder Tests dafür schreiben, und er arbeitet an der Live-Datei mit vollem Projektkontext.

Wissenscheck

1. Was ist der grundlegende Unterschied zwischen Cloud Codex und lokalem Codex, wie er in der Lektion beschrieben wird?

2. Wann ist es laut Lektion am sinnvollsten, Cloud Codex gegenüber lokalem Codex zu bevorzugen?

3. Die Lektion betont, dass das Wirksamste beim Zuweisen einer Aufgabe ist, das Issue einzufügen und auf echte Dateien zu verweisen. Warum ist das relevant?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die korrekt beschreiben, wie Codex mit GitHub und der IDE verbunden wird.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Eigenschaften, die für lokales Codex (die IDE-Extension und die CLI) zutreffen.

Wählen Sie alle richtigen Antworten aus.

Safety-Guardrails, die Sie wirklich nutzen sollten

Codex ist standardmäßig auf Sicherheit ausgelegt, und die Defaults sind genau deshalb konservativ, damit Sie sie bewusst lockern können. Kennen Sie die echten Hebel.

Sandboxing und Netzwerk

Cloud-Codex-Aufgaben laufen während der Ausführung ohne Netzwerkzugriff, sofern Sie ihn nicht explizit aktivieren. Das ist ein bewusster Schutz: eine Aufgabe kann nicht unbemerkt Code exfiltrieren oder nicht vertrauenswürdige Pakete hereinziehen. Wenn Ihr Build tatsächlich Dependencies laden muss, aktivieren Sie Netzwerkzugriff für diese Umgebung und pinnen Sie möglichst, was erreichbar ist. Behandeln Sie breiten Netzwerkzugriff als Entscheidung, nicht als Default.

Approvals sind Ihr Kill Switch

In den lokalen Modi ist der Approval-Prompt das wichtigste Sicherheitsmerkmal, kein Ärgernis. Kommandos, die Ihr System verändern oder über den Workspace hinausgreifen, kommen zur Bestätigung. Widerstehen Sie dem Impuls, in einem Repo, das zählt, alles auf Full Access zu stellen. Reservieren Sie volle Autonomie für Wegwerf-Branches und Experimente.

Branch Protection macht die schwere Arbeit

Codex respektiert Ihr bestehendes GitHub-Setup. Weil jede Änderung als PR auf einem Branch ankommt, gaten Ihre Pflicht-Reviews, Status Checks und CODEOWNERS-Regeln weiterhin den Merge. Der Agent kann einen PR öffnen; ein geschütztes main kann er nicht umgehen. Genau deshalb ist das „PR öffnen“-Muster sicherer, als irgendein Tool direkt pushen zu lassen: Ihr menschlicher Review-Prozess bleibt unverändert.

Secrets bleiben aus dem Prompt

Fügen Sie keine API-Keys oder Credentials in Aufgabenbeschreibungen ein. Für Cloud-Umgebungen, die Secrets zum Ausführen der Tests brauchen, nutzen Sie die Secret-Konfiguration der Umgebung statt Inline-Werte. Alles im Prompt ist Teil des Aufgabenkontexts; Credentials gehören in den Secret Store.

Die GitHub App eng halten

Als Sie GitHub verbunden haben, haben Sie Zugriff auf bestimmte Repos gewährt. Behalten Sie das so. Es gibt keinen Grund, der Codex GitHub App Zugriff auf Repositories zu geben, die sie nie anfassen wird. Prüfen Sie die freigegebenen Repos regelmäßig in Ihren GitHub-Einstellungen.

Ein einfaches mentales Modell: Cloud + Sandbox + PR-Review für delegierte Arbeit, die Sie nicht beobachten, und lokal + Approvals für Arbeit, die Sie beobachten. In beiden Fällen ist das Merge-Gate Ihr bestehendes GitHub-Regelwerk, und das sollten Sie nie aufweichen, nur damit der Agent schneller wird.

Wann welches Surface

Eine kurze Entscheidungshilfe:

  • Klar umrissenes, abgeschlossenes Issue? Cloud Codex. Zuweisen, etwas anderes tun, PR reviewen.
  • Explorativer Refactor, bei dem Sie steuern wollen? IDE-Extension im Auto-Modus.
  • Skriptbare, wiederholbare Aufgabe in CI oder einem Terminal-Workflow? Die Codex CLI.
  • Ein ganzer Stapel kleiner Aufgaben (Versionen anheben, Lint-Fehler über Dateien hinweg beheben)? Cloud, je eine Aufgabe, dann den Stack an PRs reviewen.

Die Fähigkeit besteht darin, das Surface daran auszurichten, wie weit Sie der Aufgabe unbeaufsichtigt vertrauen. Für praktische Setup-Details und Limits halten Sie die Codex-Artikel im Help Center bereit, da sich die genauen Umgebungsoptionen weiterentwickeln.

Wichtigste Erkenntnisse

  • Steuern Sie den Loop, nicht die Tastatur. Weisen Sie ein GitHub-Issue mit konkreten Dateiverweisen zu, lassen Sie Cloud Codex einen PR erzeugen und reviewen Sie ihn wie die Arbeit eines Teamkollegen. Das Merge-Gate bleibt bei Ihnen.
  • Schreiben Sie eine `AGENTS.md`. Eine kleine Datei, die Codex sagt, wie installiert, getestet und gelintet wird und welche Verzeichnisse tabu sind, verbessert die PR-Qualität deutlich und hält CI grün.
  • Wählen Sie das Surface nach Autonomie. Cloud für delegierte, abgeschlossene Aufgaben; die IDE-Extension für Live-Pairing, bei dem Sie zusehen und freigeben wollen.
  • Behandeln Sie Approvals und Sandboxing als Features. Halten Sie Cloud-Aufgaben netzwerkisoliert, sofern sie Zugriff nicht wirklich brauchen, reservieren Sie Full-Access-Modi für Wegwerf-Branches und fügen Sie nie Secrets in Prompts ein.
  • Lassen Sie Branch Protection gaten. Weil Codex Ihnen PRs übergibt, schützen Ihre bestehenden Pflicht-Reviews, Status Checks und CODEOWNERS-Regeln main bereits. Weichen Sie sie nicht auf, um schneller zu sein.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Eine AGENTS.md mit Install, Test, Lint und Sperrverzeichnissen schreiben
  • Branch Protection einrichten: PR, Review und erfolgreiche Checks verpflichtend, bevor Codex läuft
Vollständiges Action Playbook ansehen →

Zurück

Codex: agentic coding in Ihrer Umgebung

Weiter

Loops und autonome Runs in Codex