Codex mit GitHub richtig nutzen: Branches, Pull Requests und Code Reviews

OpenAI Codex kann erheblich mehr, als nur einzelne Funktionen oder Code-Snippets zu erzeugen. Der Coding-Agent kann komplette Aufgaben innerhalb eines Repositorys bearbeiten, Tests ausführen, Änderungen vorbereiten und zusammen mit GitHub in einen professionellen Entwicklungsworkflow eingebunden werden.

Genau hier entsteht allerdings eine wichtige Frage: Sollte man Codex einfach auf das Repository loslassen und Änderungen direkt in main schreiben lassen?

Für ernsthafte Projekte lautet die sinnvollere Antwort: nein. Ein Coding-Agent sollte genauso behandelt werden wie ein weiterer Entwickler im Team. Änderungen entstehen zunächst in einem eigenen Branch, werden über einen Pull Request sichtbar gemacht, automatisiert getestet und anschließend überprüft.

Git wird dadurch zur Sicherheits- und Kontrollschicht zwischen dem KI-Agenten und deinem produktiven Code.

Der passende Workflow sieht vereinfacht so aus:

Issue / Aufgabe
  → Feature Branch
  → Codex entwickelt
  → Tests + Linting
  → Commit
  → Push zu GitHub
  → Pull Request
  → CI + Codex Review + menschliches Review
  → Merge
  → main

Damit wird aus „KI schreibt Code" ein nachvollziehbarer Entwicklungsprozess.

Codex und GitHub: Was ist 2026 möglich?

Codex Cloud lässt sich mit GitHub-Repositories verbinden. Dabei bestimmst du, auf welche Repositorys Codex Zugriff erhält. Für Aufgaben können eigene Umgebungen eingerichtet werden, und Ergebnisse lassen sich als Diff überprüfen oder anschließend in einen Pull Request überführen. Ob du dafür lieber die Codex App, die CLI im Terminal oder eine IDE-Erweiterung verwendest, hängt vor allem von deinem Workflow ab – ein Vergleich der drei Oberflächen findet sich in Codex App vs. Codex CLI vs. IDE: Welche Variante eignet sich wofür? (Zum Artikel).

Besonders interessant ist die inzwischen verfügbare Integration für Pull-Request-Reviews. Innerhalb eines GitHub Pull Requests kann beispielsweise @codex review verwendet werden. Codex analysiert daraufhin den Pull-Request-Diff und veröffentlicht ein reguläres GitHub Code Review. OpenAI unterstützt außerdem automatische Reviews sowie repositoryspezifische Review-Regeln über AGENTS.md.

Damit kann Codex heute an mehreren Stellen des Entwicklungsprozesses eingesetzt werden: Code schreiben, Tests ausführen, Fehler beheben, Pull Requests vorbereiten, Pull Requests überprüfen und Review-Findings beheben. Diese Fähigkeiten machen GitHub-Strukturen wichtiger und nicht unwichtiger. Je leistungsfähiger der Agent wird, desto wichtiger werden nachvollziehbare Grenzen.

Die wichtigste Regel: Codex arbeitet nicht direkt auf main

Der Branch main beziehungsweise der zentrale Produktionsbranch sollte die stabile Version deines Projekts darstellen. GitHub beschreibt Branches ausdrücklich als Möglichkeit, Features, Fehlerbehebungen oder Experimente isoliert von anderen Änderungen durchzuführen. Änderungen können anschließend über Pull Requests verglichen, diskutiert und zusammengeführt werden.

Statt Codex also zu sagen „Implementiere das neue Login-System", ist ein sauberer Workflow:

git switch main
git pull
git switch -c feature/login-system

Erst anschließend startest du Codex. Damit befindet sich die gesamte KI-generierte Arbeit in feature/login-system und nicht direkt in main. Sollte Codex eine falsche Architektur wählen, unerwartet Dateien verändern oder eine Regression verursachen, bleibt der produktive Branch zunächst unberührt.

Gute Branch-Namen helfen Mensch und KI

Auch bei KI-generiertem Code sollte der Branch erkennen lassen, was geändert wird, zum Beispiel feature/user-dashboard, fix/login-timeout, refactor/database-layer oder security/update-authentication. Das hilft nicht nur Entwicklern – auch Codex bekommt dadurch zusätzlichen Kontext darüber, welche Art von Änderung gerade durchgeführt wird. Ein Branch wie codex-test-123 sagt dagegen praktisch nichts über die eigentliche Aufgabe aus.

Vor Codex: GitHub richtig absichern

Bevor ein Coding-Agent Schreibzugriff auf wichtige Repositorys erhält, sollte GitHub selbst entsprechende Schutzmechanismen besitzen. Protected Branches und GitHub Rulesets können unter anderem direkte Pushes einschränken, Pull Requests verlangen, erforderliche Status-Checks festlegen und Reviews vor einem Merge voraussetzen. GitHub unterstützt außerdem verpflichtende Code-Owner-Reviews, signierte Commits und das Auflösen offener Review-Diskussionen.

Für einen produktiven main-Branch bietet sich beispielsweise folgende Philosophie an: kein normaler direkter Push, Änderungen nur per Pull Request, CI muss erfolgreich sein, mindestens ein Review, offene Review-Kommentare müssen geklärt sein – danach erst der Merge. So kann ein Fehler des KI-Agenten nicht automatisch zum Fehler im Produktionsbranch werden. Wie sich Codex zusätzlich über Sandbox, Backups und Freigaben absichern lässt, zeigt Codex sicher verwenden: Git, Sandbox, Backups und Freigaben richtig einrichten (Zum Artikel).

AGENTS.md: Die Spielregeln für Codex

Eine der wichtigsten Dateien für Codex-Projekte ist AGENTS.md. Codex lädt solche Dateien als dauerhafte Projektanweisungen. Darin können unter anderem Repository-Struktur, Build-Befehle, Test-Befehle, Entwicklungsregeln, Verbote und Anforderungen für Pull Requests definiert werden.

Eine einfache Variante könnte so aussehen:

# AGENTS.md

## Repository
This is a production application.

## Development rules
- Never commit directly to main.
- Do not modify production secrets.
- Do not commit .env files.
- Keep changes limited to the current task.
- Avoid unrelated refactoring.

## Validation
Before considering a task complete:
- Run the unit tests.
- Run the integration tests if affected.
- Run the linter.
- Check git diff for unrelated changes.

## Pull Requests
Every functional change must be submitted through a pull request.
The pull request description must contain:
- What changed
- Why it changed
- Files affected
- Tests performed
- Known risks

Damit musst du diese Regeln nicht bei jeder neuen Aufgabe erneut erklären. Setzt du neben Codex auch Claude Code im selben Projekt ein, solltest du diese Regeln nicht doppelt pflegen: AGENTS.md vs. CLAUDE.md: Welche Datei braucht dein Projekt? (Zum Artikel)

Der ideale Codex-Prompt beginnt nicht mit „Mach das fertig"

Coding-Agenten arbeiten besser, wenn die Aufgabe klar begrenzt ist. Ein guter Auftrag enthält mindestens Ziel, Scope, Einschränkungen und Akzeptanzkriterien. Zum Beispiel:

Implementiere serverseitige Pagination für die Benutzerverwaltung.
Arbeite ausschließlich im aktuellen Feature-Branch.

Anforderungen:
- API unterstützt page und limit.
- Standardwert für limit ist 50.
- Maximalwert ist 200.
- Bestehende API-Aufrufe müssen kompatibel bleiben.
- Ergänze passende Tests.
- Ändere keine nicht betroffenen Komponenten.
- Installiere keine zusätzlichen Dependencies ohne Begründung.
- Führe Tests und Linter aus.

Prüfe anschließend den vollständigen git diff auf unbeabsichtigte Änderungen.
Erstelle keinen Merge nach main.

Das ist ein völlig anderer Arbeitsauftrag als „Mach Pagination." Je klarer die Aufgabe definiert ist, desto leichter lässt sich später auch der Pull Request überprüfen.

Codex arbeiten lassen – aber anschließend den Diff prüfen

Nach Abschluss der Aufgabe sollte nicht sofort committed werden. Zuerst git status, danach git diff, bei bereits gestagten Änderungen zusätzlich git diff --cached. Die entscheidende Frage lautet: Hat Codex ausschließlich das verändert, was für diese Aufgabe notwendig war?

Besonders aufmerksam solltest du bei Änderungen an diesen Bereichen sein: .env, Dockerfile, docker-compose.yml, package.json, requirements.txt, GitHub Actions, Deployment-Skripte, Datenbankmigrationen, Authentifizierung, Berechtigungen sowie Firewall-Regeln und Infrastructure as Code. Eine eigentlich kleine Aufgabe, die plötzlich zwölf Konfigurationsdateien verändert, verdient eine genauere Untersuchung.

Kleine Commits statt eines riesigen KI-Commits

Auch wenn Codex innerhalb weniger Minuten eine große Menge Code erzeugen kann, sollten Commits weiterhin logisch nachvollziehbar bleiben. Statt „Update project" ist beispielsweise feat(users): add server-side pagination deutlich hilfreicher. Bei einem Fehler kannst du später wesentlich leichter erkennen, warum eine Änderung durchgeführt wurde.

git add .
git commit -m "feat(users): add server-side pagination"
git push -u origin feature/user-pagination

Jetzt befindet sich die Änderung auf GitHub, aber noch immer nicht in main.

Pull Requests sind die eigentliche Kontrollstelle

Ein Pull Request ist nicht bloß der Knopf vor dem Merge. Er ist die zentrale Stelle für Diff, Commits, Diskussionen, Tests, CI, Code Reviews, Security Checks und die Merge-Entscheidung. GitHub kann automatisierte Tests, Builds und Code-Scanning direkt gegen die Änderungen eines Pull Requests laufen lassen. Erst wenn Reviews und notwendige Checks erfüllt sind, wird der PR zusammengeführt. Gerade bei KI-generiertem Code ist dieser Zwischenschritt besonders wertvoll.

Einen guten Pull Request von Codex vorbereiten lassen

Auch die Beschreibung des Pull Requests kann Codex vorbereiten. Ein sinnvoller Auftrag wäre:

Analyze the changes in the current branch compared with main.

Create a pull request description containing:
- Summary
- Reason for the change
- Important implementation details
- Files and components affected
- Tests executed
- Potential risks
- Manual verification steps

Do not exaggerate test coverage.
Only mention tests that were actually executed.

Der letzte Punkt ist wichtig. Eine PR-Beschreibung sollte nicht behaupten „All tests passed.", wenn tatsächlich gar keine Tests ausgeführt wurden.

Draft Pull Requests für größere Codex-Aufgaben

Bei größeren Änderungen kann ein Draft Pull Request sinnvoll sein. Damit wird früh sichtbar, woran gearbeitet wird, ohne den Eindruck zu erwecken, dass der Code bereits merge-fertig ist. Codex kann weiter Änderungen in denselben Branch pushen, während Entwickler bereits Architektur und Diff beobachten. Das reduziert das Risiko, nach mehreren Stunden oder Tagen festzustellen, dass der Agent grundsätzlich in die falsche Richtung gearbeitet hat.

Codex selbst als Code Reviewer einsetzen

Eine der interessantesten Funktionen der aktuellen GitHub-Integration ist das direkte Code Review. In einem Pull Request kannst du schreiben:

@codex review

Codex analysiert den Diff und veröffentlicht anschließend ein GitHub Review. Laut aktueller OpenAI-Dokumentation konzentriert sich das reguläre GitHub-Review dabei auf Probleme hoher Priorität. Du kannst die Analyse außerdem thematisch einschränken, beispielsweise mit @codex review for database migration risks oder @codex review focusing on authentication and authorization. Das ist besonders hilfreich bei Pull Requests, deren kritische Bereiche bereits bekannt sind.

Automatische Codex Reviews

Wenn Codex Code Review für das Repository aktiviert ist, können Reviews auch automatisch gestartet werden. Dann muss nicht jedes Mal manuell @codex review geschrieben werden – Codex überprüft neue Pull Requests entsprechend der konfigurierten Einstellungen automatisch. Ein möglicher Workflow sieht dann so aus:

Developer / Codex
  → Pull Request
  → GitHub Actions + Codex Review + Security Checks
  → Human Review
  → Merge

Damit wird die KI nicht zum Ersatz des Entwicklungsprozesses, sondern zu einem zusätzlichen Bestandteil davon.

Eigene Code-Review-Regeln über AGENTS.md

Besonders interessant wird Codex Code Review zusammen mit AGENTS.md über einen eigenen Bereich ## Code Review Rules. Codex sucht nach entsprechenden AGENTS.md-Dateien und kann abhängig vom Verzeichnis unterschiedliche Regeln anwenden. Repository-weite Vorgaben können im Root-Verzeichnis liegen, während beispielsweise ein besonders kritischer Payment-Service zusätzliche Regeln in seinem eigenen Verzeichnis erhalten kann.

## Code Review Rules

### Authentication
- Authentication endpoints must never log passwords,
  access tokens, refresh tokens or session cookies.

### Database
- Database migrations must remain backward compatible
  during rolling deployments.

### API
- Existing public API fields must not be removed
  without an explicit migration plan.

### Security
- Never expose internal exception details to API clients.

Damit kennt Codex Regeln, die ein allgemeiner Code Reviewer überhaupt nicht kennen könnte.

Linting gehört nicht in das KI-Review

Nicht jede Prüfung sollte von Codex übernommen werden. Deterministische Prüfungen wie Formatting, Linting, Type Checking, Unit Tests, Integration Tests, Build und Dependency Checks gehören weiterhin in die CI. OpenAI empfiehlt ebenfalls, mechanisch überprüfbare Regeln der CI zu überlassen und AGENTS.md-Review-Regeln vor allem für projektspezifische Risiken und Verhaltensanforderungen einzusetzen. Ein Linter kann zuverlässig erkennen, ob eine Formatierungsregel verletzt wurde. Codex sollte seine Rechenzeit lieber für Fragen verwenden wie: Kann diese Änderung zu einem Datenverlust führen? Oder: Verändert diese Implementierung unbeabsichtigt das Berechtigungsmodell?

Codex Security Review

Für sicherheitskritische Änderungen gibt es zusätzlich @codex security review. OpenAI beschreibt dieses Security Review aktuell als zusätzliche, ausführlichere Sicherheitsprüfung eines Pull Requests und kennzeichnet die Funktion als Research Preview. Interessant ist das beispielsweise bei Änderungen an Authentifizierung, Autorisierung, Session Management, API-Zugriff, Datei-Uploads, SQL-Abfragen, Secrets, Kryptografie, OAuth, Webhook-Verarbeitung und Infrastruktur. Das Security Review sollte trotzdem keine bestehenden Security-Werkzeuge ersetzen: SAST, Dependency Scanning, Secret Scanning und menschliche Sicherheitsprüfungen bleiben weiterhin wichtig.

Codex kann Review-Probleme auch beheben

Findet Codex bei einem Pull Request ein Problem, kann der Agent anschließend erneut eingebunden werden. Die aktuelle OpenAI-Dokumentation nennt beispielsweise @codex fix the P1 issue. Codex kann daraufhin einen Cloud-Chat mit dem Pull Request als Kontext starten und – bei entsprechender Berechtigung – eine Korrektur in den Branch zurückschreiben. Der interessante Teil beginnt danach: Denn die neue Änderung sollte wieder durch denselben Prozess laufen – Finding, Fix, CI, Diff, Review. Ein behobener Fehler kann schließlich einen neuen Fehler erzeugen.

Human Review bleibt wichtig

Codex Code Review ist eine zusätzliche Prüfinstanz und kein Grund, alle anderen Kontrollen abzuschalten. Auch OpenAI weist darauf hin, dass Code Review durch Codex Tests, Branch-Schutzregeln und erforderliche Genehmigungen nicht ersetzt. Menschen besitzen Kontext, den ein Coding-Agent möglicherweise nicht vollständig kennt: Warum wurde eine alte Schnittstelle absichtlich nicht modernisiert? Welcher Großkunde benötigt ein bestimmtes Legacy-Verhalten? Welche Änderung ist für den nächsten Release ausdrücklich ausgeschlossen? Welche Abhängigkeit darf aus Compliance-Gründen nicht verwendet werden? Ein technisch korrekter Diff kann aus betrieblicher Sicht trotzdem falsch sein.

CODEOWNERS für besonders kritische Bereiche

GitHub kann über Code Owners automatisch die zuständigen Entwickler oder Teams für bestimmte Dateien anfordern, etwa für /database/migrations/, /infrastructure/, /.github/workflows/, /auth/ oder /payment/. Ändert Codex dort Code, kann GitHub automatisch zusätzliche Reviews der zuständigen Verantwortlichen verlangen. GitHub unterstützt Code-Owner-Reviews zusammen mit geschützten Branches und Rulesets. Damit lässt sich ein sehr wirksames Prinzip umsetzen: Je kritischer der Code, desto stärker die Kontrolle vor dem Merge.

CI muss vor dem Merge entscheiden können

Ein professioneller Codex-Workflow sollte möglichst viele Fehler erkennen, bevor ein Mensch überhaupt den kompletten Diff lesen muss. Eine CI-Pipeline könnte beispielsweise Checkout, Dependencies, Lint, Type Check, Unit Tests, Integration Tests, Build und Security Scan nacheinander prüfen. GitHub Branch Protection kann verlangen, dass definierte Status Checks erfolgreich abgeschlossen sein müssen, bevor ein Pull Request gemerged werden darf. Dann kann Codex zwar fehlerhaften Code erzeugen und pushen. Er kommt aber nicht automatisch durch die Qualitätskontrolle. Genau das ist der gewünschte Effekt.

Vorsicht vor automatischem Merge

Automatisierung ist bequem. Ein Workflow nach dem Muster „Codex schreibt → Codex reviewed → CI grün → Auto-Merge → Produktion" ist jedoch nicht für jedes Projekt sinnvoll. Gerade bei Änderungen an Datenbanken, Authentifizierung, Infrastruktur oder Geschäftslogik kann ein technisch erfolgreicher Build trotzdem unerwünschte Auswirkungen besitzen. Deshalb sollte die Frage nicht lauten „Wie automatisiere ich möglichst viel?", sondern: Welche Schritte können zuverlässig automatisiert werden, und an welchen Stellen brauche ich bewusst eine Freigabe?

Welche Merge-Strategie eignet sich?

GitHub unterstützt unter anderem Merge Commits, Squash-and-Merge sowie Rebase-and-Merge. Bei vielen kleineren Codex-Branches kann Squash and merge attraktiv sein: Aus mehreren kleinen Zwischen-Commits wie fix validation, fix test oder final fix wird dann beispielsweise ein einziger Commit feat(api): add request validation. Bei Projekten, in denen einzelne Commits bewusst eine wichtige Entwicklungsgeschichte dokumentieren, können andere Strategien sinnvoller sein. Wichtig ist vor allem, dass das Team eine einheitliche Regel verwendet.

Ein kompletter Codex-GitHub-Workflow in der Praxis

Nehmen wir an, Codex soll einen CSV-Export für die Benutzerverwaltung implementieren. Zuerst:

git switch main
git pull
git switch -c feature/user-csv-export

Danach bekommt Codex folgenden Auftrag:

Implement a CSV export for the user administration.

Requirements:
- Work only in the current branch.
- Do not modify authentication or permissions.
- Only administrators may export users.
- Export only fields already visible in the admin interface.
- Use UTF-8.
- Add appropriate tests.
- Do not introduce new dependencies unless necessary.
- Run all relevant tests and linting.
- Review the final git diff for unrelated changes.

Do not merge into main.

Nach Abschluss: git status und git diff, danach Tests wie npm test und npm run lint beziehungsweise die für dein Projekt vorgesehenen Befehle. Wer die Codex CLI unter Linux bereits im Terminal einsetzt, findet die grundlegenden Befehle und die sichere Konfiguration in Codex CLI unter Linux installieren und richtig nutzen (Zum Artikel). Anschließend:

git add .
git commit -m "feat(users): add CSV export"
git push -u origin feature/user-csv-export

Jetzt wird der Pull Request erstellt. Dort kann zusätzlich @codex review ausgeführt werden. Bei sicherheitskritischen Änderungen: @codex security review. Danach folgen CI und menschliches Review. Erst wenn diese Prüfungen abgeschlossen sind, wird der Pull Request nach main gemerged. Das ist der Unterschied zwischen unkontrolliertem KI-Coding und KI-gestützter Softwareentwicklung.

Die häufigsten Fehler bei Codex und GitHub

Der gefährlichste Fehler ist nicht schlechter KI-Code. Der gefährlichste Fehler ist ein Workflow, in dem schlechter Code ohne ausreichende Kontrolle produktiv werden kann. Problematisch sind insbesondere direkte Schreibrechte auf main, fehlende Branch Protection, riesige Pull Requests, unklare Codex-Aufträge, fehlende Tests, mitcommittete Secrets und automatisches Deployment ohne geeignete Freigabeschritte.

Ein weiterer Klassiker ist der Auftrag „Improve the project." Codex kann das vollkommen anders interpretieren als du. Eine klar abgegrenzte Aufgabe wie „Fix issue #248 without changing the public API." ist wesentlich leichter zu implementieren und anschließend zu überprüfen.

GitHub ist bei KI-Coding mehr als Versionsverwaltung

Früher wurde Git häufig vor allem als Versionsverwaltung betrachtet. Mit Coding-Agenten übernimmt Git zusätzlich eine wichtige Governance-Funktion. Branches begrenzen Änderungen. Commits dokumentieren sie. Pull Requests machen sie sichtbar. CI prüft sie. Reviews hinterfragen sie. Branch Protection verhindert unerlaubte Abkürzungen. Und erst der Merge übernimmt die Änderung in die gemeinsame Codebasis.

KI-Agent → Git → GitHub → CI → Review → Freigabe → Produktion

Je autonomer Coding-Agenten werden, desto wertvoller wird diese Struktur.

Fazit: Codex braucht Leitplanken – und GitHub liefert sie

OpenAI Codex kann Entwicklungsarbeit erheblich beschleunigen. Der größte Produktivitätsgewinn entsteht aber nicht dadurch, dass man dem Agenten unbegrenzte Rechte gibt. Er entsteht durch einen guten Prozess: Branch erstellen, Codex eine klar abgegrenzte Aufgabe geben, Änderungen kontrollieren, Tests ausführen, Pull Request erstellen, CI und Code Review durchführen – erst danach mergen.

Mit AGENTS.md, GitHub Branch Protection, automatisierten Tests, Pull Requests und Codex Code Review lässt sich ein Workflow schaffen, bei dem KI sehr viel Arbeit übernehmen kann, ohne dass die Kontrolle über den Quellcode verloren geht. Genau darin liegt der Unterschied zwischen einfachem Vibe Coding und professioneller KI-gestützter Softwareentwicklung.

Codex darf schnell sein. GitHub sorgt dafür, dass schnell nicht automatisch unkontrolliert bedeutet.

FAQ: Codex mit GitHub

Kann Codex GitHub Pull Requests überprüfen?

Ja. Codex Code Review kann direkt in GitHub Pull Requests verwendet werden. Ein Review lässt sich unter anderem mit @codex review anfordern. Automatische Reviews können ebenfalls konfiguriert werden.

Was macht AGENTS.md?

AGENTS.md enthält dauerhafte Anweisungen für Codex. Darin können beispielsweise Build- und Testbefehle, Projektkonventionen, Einschränkungen und spezielle Code-Review-Regeln definiert werden. Codex kann abhängig vom Verzeichnis unterschiedliche AGENTS.md-Anweisungen berücksichtigen.

Sollte Codex direkt auf main entwickeln?

Für kontrollierte Entwicklungsprozesse ist ein eigener Feature- oder Bugfix-Branch sinnvoller. Dadurch bleiben Änderungen isoliert und können anschließend über einen Pull Request überprüft werden. GitHub empfiehlt Branches genau für diese Trennung von Entwicklungsarbeit.

Kann Codex Sicherheitsprüfungen durchführen?

OpenAI bietet mit @codex security review ein zusätzliches Security Review für Pull Requests an. Die Funktion wird aktuell als Research Preview beschrieben.

Ersetzt Codex einen menschlichen Code Reviewer?

Nein. Codex kann einen zusätzlichen Review-Durchgang liefern, aber OpenAI beschreibt Code Review ausdrücklich als Ergänzung zu Tests, Branch-Schutzregeln und notwendigen Genehmigungen.

Was passiert, wenn Codex beim Review einen Fehler findet?

Codex kann über einen weiteren Kommentar mit der Fehlerbehebung beauftragt werden. Bei entsprechender Berechtigung kann der Agent die Änderung wieder in den PR-Branch schreiben. Danach sollten CI und Review erneut ausgeführt werden.

Quellen und weiterführende Dokumentation

Dieser Artikel basiert auf dem aktuellen Funktionsstand der offiziellen OpenAI-Codex-Dokumentation sowie der GitHub-Dokumentation zu Branches, Pull Requests, Code Reviews und Branch Protection. Besonders relevant sind die aktuellen OpenAI-Dokumentationen zu Codex Code Review, AGENTS.md und Codex Cloud sowie die GitHub-Dokumentationen zu Protected Branches, Pull Requests und Rulesets.

Stand: September 2026.

Weiterführende Themen

Codex sicher verwenden: Git, Sandbox, Backups und Freigaben richtig einrichten (Zum Artikel)

AGENTS.md vs. CLAUDE.md: Welche Datei braucht dein Projekt? (Zum Artikel)

Codex App vs. Codex CLI vs. IDE: Welche Variante eignet sich wofür? (Zum Artikel)

Codex CLI unter Linux installieren und richtig nutzen (Zum Artikel)

Claude Code vs. OpenAI Codex: Welcher Coding-Agent ist besser? (Zum Artikel)