Codex Cloud mit GitHub: Pull Requests erstellen und prüfen

Mit Codex Cloud kannst du ein GitHub-Repository in eine vorbereitete Cloud-Umgebung einbinden, Codex eine klar eingegrenzte Änderung bearbeiten lassen und den daraus entstehenden Pull Request selbst prüfen. Dafür brauchst du ein berechtigtes Konto und musst die Umgebung vor dem Start veröffentlichen. Die Standardressourcen der virtuellen Maschine unterscheiden sich je nach Plan.

Voraussetzungen für Codex Cloud und GitHub

OpenAI führt Codex Cloud für Plus, Pro, Business und Enterprise/Education auf. Der Zugriff über einen API-Schlüssel ist nicht vorgesehen; außerdem gelten die Berechtigungen des jeweiligen Workspace. Prüfe diese Voraussetzungen, bevor du mit der Einrichtung beginnst. OpenAIs Übersicht zu Plänen und Funktionen

Wähle ein GitHub-Repository aus, auf das du zugreifen kannst. Überlege außerdem, welche Laufzeitumgebungen, Abhängigkeiten, privaten Paketquellen oder Zugangsdaten dein Projekt benötigt. Dann kannst du den Einrichtungsbericht gezielt kontrollieren, statt fehlende Voraussetzungen erst beim ersten Task zu entdecken.

Umgebung vorbereiten und veröffentlichen

1. Lege eine Cloud-Umgebung an und wähle das Repository aus. Im Web- oder Desktop-Ablauf führt der Weg über Work in → Cloud → Select environment → Create environment. Verbinde GitHub, falls Codex dich dazu auffordert, und wähle das gewünschte Repository.
2. Prüfe die Einrichtung. Codex untersucht das Repository, richtet Abhängigkeiten und Werkzeuge ein und testet den Ablauf. Lies die Konfiguration und den Einrichtungsbericht durch. Kläre fehlende Angaben und prüfe besonders die benötigten Befehle, Laufzeiten, Dienste und Zugriffsrechte.
3. Veröffentliche die geprüfte Umgebung. Erst danach startest du einen Task. Das Veröffentlichen speichert einen wiederverwendbaren Ausgangspunkt für neue Tasks; es stellt deine Anwendung nicht bereit. Soll die Umgebung geändert werden, bearbeitest, testest und veröffentlichst du sie erneut. Neue Tasks beginnen mit der veröffentlichten Umgebung, während bestehende Tasks ihren eigenen Zustand behalten. OpenAIs Anleitung zu Cloud-Umgebungen

Mehr Hintergrund zu wiederverwendbaren Umgebungen bietet auch NeoTeos Artikel zu Codex Cloud auf Spanisch.

Eine kleine, überprüfbare Änderung anfordern

Bitte Codex zuerst, das Repository und die betreffende Stelle zu erklären. Formuliere danach eine konkrete Änderung: Beschreibe das erwartete Verhalten, relevante Regressionstests und die Befehle, mit denen sich das Ergebnis prüfen lässt. Grenze außerdem ab, welche Dateien oder Bereiche unberührt bleiben sollen und ob neue Abhängigkeiten ausgeschlossen sind.

Der HackerNoon-Beitrag von proflead beschreibt diesen Ansatz an einem JavaScript-Beispiel: Auf eine Erklärung des Repositorys folgt eine gezielte Korrektur an Suchgrenzen. Das ist ein einzelner Arbeitsablauf, kein Maßstab für die Qualität anderer Tasks. Der Walkthrough von proflead

Diff, Tests und Pull Request kontrollieren

Sieh dir die geänderten Dateien und den Diff an, also die konkreten hinzugefügten und entfernten Zeilen. Prüfe auch die Testfälle selbst und nicht nur die angezeigte Ausgabe. Führe die im Projekt vorgesehenen Prüfungen aus und kontrolliere, ob sie zum erwarteten Verhalten passen.

Lass anschließend den Pull Request erstellen und öffne ihn in GitHub. Kontrolliere den Quell- und Ziel-Branch, den Diff, die Beschreibung und die CI-Ergebnisse. Ein konfliktfreier Merge-Status sagt nichts darüber aus, ob die Änderung fachlich richtig ist. Die Prüfung bleibt also bei dir.

Pull Request lokal auschecken

Wenn du die Änderung in deiner lokalen Arbeitskopie prüfen möchtest, kontrolliere zuerst mit git status, ob du ungesicherte Änderungen hast. Die von proflead beschriebene Folge lautet:

git remote -v
git fetch origin
git switch --track origin/your-task-branch

Ersetze your-task-branch durch den Branch-Namen des Pull Requests. Führe die Tests anschließend in deiner lokalen Kopie erneut aus.

VM-Ressourcen, gespeicherter Zustand und Zugangsdaten

OpenAI nennt je nach Plan unterschiedliche Standardressourcen pro Task. Die Angaben helfen dir einzuschätzen, ob die vorgesehene VM zu den Anforderungen deines Projekts passt. Für einen Leistungsvergleich müssen VM-Größe und Testbedingungen gleich sein.

Gespeicherter VM-Zustand kann laut OpenAI bis zu sieben Tage nach dem Start des letzten Task-Turns oder nach dem Fortsetzen des Tasks wiederhergestellt werden. Er ersetzt keine Versionskontrolle: Sichere wichtige Änderungen weiterhin in Git.

Bei Zugangsdaten unterscheidet OpenAI zwei Wege:

Eine freigegebene Zieladresse verleiht allein weder Zugangsdaten noch Berechtigungen beim jeweiligen Dienst. Prüfe deshalb getrennt, ob das Ziel erlaubt ist und ob die nötige Authentifizierung eingerichtet wurde.

Die Cloud-Umgebung übernimmt weder Dateien, laufende Prozesse oder Browser-Sitzungen deines Laptops noch dessen bestehende VPN-Verbindung. OpenAI beschreibt separat konfigurierbaren VPN-Zugang mit Tailscale; dafür müssen sowohl die VPN-Regeln als auch die Netzwerkeinstellungen der Umgebung passen. Cloud-Umgebungen unterstützen derzeit keine Browser- oder Computernutzung sowie weder GitLab noch selbst gehostete GitHub Enterprise Server.