Für Teams, die in Codex noch GPT-5.4 fest eingestellt haben, steht im August eine kleine, aber wichtige Aufräumaktion an. OpenAI nimmt GPT-5.4 und GPT-5.4 mini am 31. August 2026 aus Codex heraus, wenn die Anmeldung über ChatGPT erfolgt. Wer eigene Agenten, geplante Aufgaben oder verwaltete Konfigurationen nutzt, sollte nicht bis zum letzten Arbeitstag warten.
Die zweite Nachricht ist weniger dringend, langfristig aber spannender: Codex kann Änderungen über mehrere verbundene Repositories hinweg gemeinsam prüfen. Zusätzlich lassen sich wiederkehrende, projektspezifische Review-Regeln in AGENTS.md festhalten. Damit verschiebt sich der Schwerpunkt ein Stück weiter vom reinen Erzeugen von Code zur Frage, wie Teams Änderungen zuverlässig prüfen und steuern.
Dieser Beitrag fasst die offiziellen Codex-Neuigkeiten vom 20. bis 31. Juli zusammen und ordnet ein, was davon im August praktisch relevant wird. Stand der Informationen ist der 4. August 2026.
Die wichtigsten Codex-Neuigkeiten im Überblick
- Modellwechsel mit Frist: GPT-5.4 und GPT-5.4 mini entfallen am 31. August in Codex-Sitzungen mit ChatGPT-Anmeldung.
- API bleibt verfügbar: Die Modelle bleiben laut OpenAI über die API und in Codex-Sitzungen mit eigenem API-Schlüssel nutzbar.
- Empfohlene Nachfolger: OpenAI nennt GPT-5.6 Terra als Ersatz für GPT-5.4 und GPT-5.6 Luna als Ersatz für GPT-5.4 mini.
- Multi-Repo-Review: Die Desktop-App kann Änderungen aus mehreren Ordnern und Repositories in einer Review-Ansicht zusammenführen.
- Eigene Prüfregeln: Codex Code Review kann gezielte Repository-Regeln aus
AGENTS.mdberücksichtigen und in einem Fund auf die Regel verweisen. - Codex CLI 0.146.0: Die neue Version bringt unter anderem benannte und angeheftete Sitzungen, Thread-Forks, Plugin-Erweiterungen und robustere Verbindungen.
Was am 31. August wirklich endet
Die Formulierung „GPT-5.4 wird eingestellt“ wäre zu pauschal. Die Änderung betrifft Codex-Nutzer, die sich mit ihrem ChatGPT-Konto anmelden. In diesem Zugangspfad stehen GPT-5.4 und GPT-5.4 mini ab dem 31. August nicht mehr zur Auswahl.
Nicht betroffen sind nach OpenAIs Angaben die OpenAI API und Codex-Sitzungen, die mit einem eigenen API-Schlüssel authentifiziert werden. Das ist für Unternehmen wichtig, weil ein API-Workflow nicht automatisch am selben Tag ausfällt. Trotzdem lohnt sich auch dort die Frage, ob ein älteres Modell langfristig die richtige Grundlage bleibt.
Handlungsbedarf besteht vor allem dort, wo das Modell nicht jedes Mal bewusst ausgewählt wird. OpenAI nennt ausdrücklich:
- Standardmodelle in Arbeitsbereichen
- gespeicherte Modelleinstellungen
- zentral verwaltete Konfigurationen
- eigene Agenten
- geplante Aufgaben und wiederkehrende Läufe
Ein interaktiver Chat fällt schnell auf, wenn ein Modell fehlt. Eine geplante Aufgabe kann dagegen nachts oder am Wochenende scheitern. Deshalb sollte die Suche nach festen Modellnamen Teil der normalen Konfigurationsprüfung sein und nicht erst nach einer Fehlermeldung beginnen.
Terra und Luna sind Nachfolger, keine identischen Kopien
OpenAI empfiehlt GPT-5.6 Terra als Ersatz für GPT-5.4. Terra ist innerhalb der GPT-5.6-Familie die ausgewogene Variante für tägliche Arbeit, bei der starke Werkzeugnutzung und vernünftige Kosten zusammenkommen sollen. Für GPT-5.4 mini nennt OpenAI GPT-5.6 Luna. Luna ist schneller und günstiger und richtet sich stärker an klar umrissene, wiederholbare Aufgaben.
Das ist eine Migrationshilfe, aber keine Garantie für identisches Verhalten. Prompts, Laufzeit, Kosten und Ergebnisse können sich ändern. Gerade bei automatisierten Aufgaben sollte ein Team deshalb einige typische Fälle mit dem neuen Modell erneut ausführen und nicht nur den Namen in der Konfiguration ersetzen.
Die Unterschiede zwischen GPT-5.6 Sol, Terra und Luna haben wir bereits ausführlich eingeordnet. Für diese Umstellung ist die einfache Zuordnung ein guter Start: Terra für bisherige GPT-5.4-Aufgaben, Luna für bisherige Mini-Aufgaben. Die endgültige Wahl sollte sich aber am konkreten Ergebnis orientieren.
Eine Migration, die in einer Stunde beginnen kann
- Feste Modellnamen suchen. Prüfen Sie
config.toml, Projektdateien, Startbefehle, Agenten, Automationen und verwaltete Einstellungen aufgpt-5.4odergpt-5.4-mini. - Aufgaben nach Risiko sortieren. Ein interner Entwurf ist weniger kritisch als ein geplanter Lauf, der Code ändert, Daten verarbeitet oder Ergebnisse an Dritte sendet.
- Mit echten Beispielen testen. Verwenden Sie typische Aufgaben aus dem Alltag, einschließlich eines schwierigen Falls und eines Falls, der bewusst abgelehnt oder eskaliert werden soll.
- Zeit, Qualität und Verbrauch vergleichen. Ein schnelleres Modell ist nicht automatisch günstiger, wenn mehr Nacharbeit nötig wird. Umgekehrt braucht eine klare Routineaufgabe nicht immer das stärkste Modell.
- Rückfalloption festhalten. Dokumentieren Sie die bisherige Einstellung, das Testdatum und die verantwortliche Person, damit eine problematische Umstellung nachvollziehbar zurückgenommen werden kann.
- Vor dem 31. August umstellen. Lassen Sie geplante Aufgaben nach der Änderung mindestens einmal kontrolliert laufen.
Multi-Repo-Reviews lösen ein echtes Alltagsproblem
Viele Softwareänderungen halten sich nicht an Repository-Grenzen. Eine neue Funktion kann gleichzeitig Backend, Weboberfläche und Dokumentation betreffen. Bislang musste ein Reviewer solche Änderungen häufig in getrennten Ansichten zusammensuchen. Seit dem Desktop-Update 26.727 kann Codex die Diffs aller Repositories eines lokalen Projekts in einer gemeinsamen Review-Ansicht zeigen.
Dafür lassen sich einem lokalen Projekt mehrere Ordner hinzufügen. Einer davon ist der primäre Ordner. Er dient als Standard für Git-Aktionen und für die automatische Suche nach AGENTS.md, Skills und config.toml. Weitere Ordner kann Codex lesen und bearbeiten, ihre Projektdateien werden jedoch nicht automatisch als übergreifende Anweisungen erkannt.
Diese Grenze ist leicht zu übersehen und praktisch wichtig. Wer Frontend und Backend verbindet, sollte klar festlegen, welches Repository primär ist und welche Regeln jeweils lokal gelten. Pull-Request- und Worktree-Aktionen zielen auf das primäre Repository. Remote-Projekte unterstützen derzeit laut OpenAI nur einen Ordner.
Meine Einschätzung: Die gemeinsame Review-Ansicht ist wertvoller als ein weiterer kleiner Geschwindigkeitsgewinn beim Generieren von Code. Sie hilft dort, wo in echten Projekten Fehler entstehen: an Schnittstellen, bei gemeinsam geänderten Verträgen und durch unvollständigen Überblick.
AGENTS.md wird vom Arbeitszettel zur Review-Grundlage
Codex kann AGENTS.md schon länger als Projektanweisung nutzen. Neu ist, dass Codex Code Review gezielte Repository-Regeln daraus bei der Prüfung anwenden und auf die passende Regel verweisen kann. Gemeint sind keine allgemeinen Sätze wie „Schreibe guten Code“, sondern Wissen, das sonst nur erfahrene Teammitglieder im Kopf haben.
Geeignete Regeln wären zum Beispiel:
- Ein bestehendes API-Feld darf nicht ohne abwärtskompatiblen Übergang umbenannt werden.
- Kundendaten dürfen in diesem Dienst nicht in Protokollen erscheinen.
- Eine bestimmte Schnittstelle wird bereits von einem anderen System genutzt, obwohl sie noch als experimentell markiert ist.
- Eine Änderung an Zahlungs- oder Berechtigungslogik benötigt einen festgelegten zusätzlichen Test.
OpenAI empfiehlt kleine, klar eingegrenzte Regelsätze. Regeln für das ganze Repository gehören an die Wurzel, dienstspezifische Hinweise in eine passende untergeordnete AGENTS.md. Mechanische Prüfungen wie Formatierung bleiben besser in Linter und CI. Repository-Regeln sind für Konsequenzen gedacht, die sich nicht zuverlässig in eine einfache technische Prüfung gießen lassen.
In einer internen Evaluierung meldet OpenAI, dass Varianten mit solchen Regeln 98 Prozent der vorgesehenen projektspezifischen Funde erkannten; die Kontrollvariante ohne diese Hilfe kam auf 58,3 Prozent. Das ist ein Herstellerergebnis aus einer eigenen Testsuite, keine unabhängige Studie und kein Versprechen für jedes Repository. Interessant ist weniger die einzelne Zahl als die Richtung: Präziser lokaler Kontext kann Reviews deutlich nützlicher machen, zu breite Regeln erzeugen dagegen schnell Lärm.
OpenAI betont selbst, dass Codex ein zusätzlicher Reviewer bleibt. Tests, Branch-Schutz und verpflichtende menschliche Freigaben sind weiterhin die verbindlichen Kontrollen. Diese Trennung ist richtig. Eine Regel in einer Textdatei kann Aufmerksamkeit lenken, aber keine technisch erzwungene Sicherheitsgrenze ersetzen.
Was Codex CLI 0.146.0 für Vielnutzer bringt
Die am 29. Juli veröffentlichte Codex CLI 0.146.0 ist kein einzelner großer Neustart, sondern eine Sammlung sinnvoller Verbesserungen für längere Arbeit:
- Sitzungen können benannt und angeheftet werden.
- Nebenunterhaltungen lassen sich wechseln, ohne sie zu schließen.
- Threads können einschließlich temporärer Varianten verzweigt werden.
- Agent-Plugin-Manifeste, Veröffentlichung im Arbeitsbereich und zusätzliche Plugin-Marktplätze werden unterstützt.
- Verbindungen über Proxys, MCP, WebSockets und Remote-Ausführung wurden robuster gemacht.
- Nachrichten, Fehler und Freigabeeinstellungen sollen Unterbrechungen und Wiederaufnahmen zuverlässiger überstehen.
- Unternehmenspläne werden besser erkannt; Administratoren erhalten mehr Kontrolle über Aktualisierungen in der Anwendung.
Gerade die unspektakulären Korrekturen zählen. Ein Agent, der lange läuft, braucht verlässliche Zustände, nachvollziehbare Freigaben und stabile Verbindungen. Neue Modellleistung hilft wenig, wenn eine Sitzung nach einer Unterbrechung ihren Kontext oder ihre Genehmigungseinstellung falsch wiederherstellt.
Browser-Kontext wird bequemer und sensibler
Mit demselben Desktop-Update verbessert OpenAI den eingebauten Browser und die Chrome-Erweiterung. Besuchte Seiten lassen sich über die Adressleiste wiederfinden, offene Tabs und markierter Seitentext können in einen Chat übernommen werden. Das erleichtert Recherche und Fehlersuche, erweitert aber den möglichen Datenzugriff.
Browser-Verläufe können interne Adressen und Suchbegriffe enthalten. Unternehmen sollten deshalb bewusst entscheiden, ob Codex den eingebauten Browser, ein separates Browserprofil oder den bereits angemeldeten Chrome-Kontext nutzen darf. Bequemlichkeit ist hier keine ausreichende Berechtigungsstrategie.
Unsere Einordnung: Der Engpass wandert vom Schreiben zum Prüfen
Die Codex-Neuigkeiten dieses Monats erzählen zusammen eine klare Geschichte. Modelle wechseln schneller, Agenten bearbeiten mehr Dateien und Projekte, und der Umfang erzeugter Änderungen wächst. Der entscheidende Engpass ist deshalb nicht mehr nur das Schreiben von Code. Es sind Überblick, Regeln und Review-Kapazität.
Das ist eine gesunde Entwicklung, wenn Teams die neuen Möglichkeiten nicht mit automatischer Richtigkeit verwechseln. Multi-Repo-Review schafft Kontext. AGENTS.md hält lokales Wissen fest. Tests und Freigaben setzen Grenzen. Erst gemeinsam entsteht ein belastbarer Ablauf.
Für Unternehmen bedeutet das: Der nächste sinnvolle Codex-Schritt ist oft kein größeres Modell, sondern ein besser vorbereitetes Repository. Klare Aufgaben, kleine Berechtigungen, reproduzierbare Tests und zwei oder drei wirklich wichtige Review-Regeln bringen im Alltag mehr als eine lange Liste allgemeiner Anweisungen.
Wer diesen Ablauf für ein bestehendes Produkt aufsetzen möchte, findet bei unserer Softwareentwicklung für Unternehmen Unterstützung. Für die Auswahl eines sinnvollen und kontrollierten KI-Einstiegs ist unsere KI-Beratung für den Mittelstand der passende Ausgangspunkt.
Häufige Fragen zum Codex Update im August 2026
Wird GPT-5.4 am 31. August vollständig abgeschaltet?
Nein. Die Änderung betrifft Codex-Nutzer mit ChatGPT-Anmeldung. Laut OpenAI bleiben GPT-5.4 und GPT-5.4 mini über die OpenAI API sowie in Codex-Sitzungen mit eigenem API-Schlüssel verfügbar.
Welches Modell ersetzt GPT-5.4 in Codex?
OpenAI empfiehlt GPT-5.6 Terra als Ersatz für GPT-5.4. Für GPT-5.4 mini wird GPT-5.6 Luna empfohlen. Automatisierte Aufgaben sollten nach dem Wechsel mit realen Beispielen erneut getestet werden.
Was ist ein Multi-Repo-Review?
In einem lokalen Projekt können mehrere Ordner und Repositories verbunden werden. Die Review-Ansicht der ChatGPT-Desktop-App zeigt die Änderungen dieser Repositories gemeinsam, sodass zusammengehörige Diffs nicht getrennt geprüft werden müssen.
Kann Codex Regeln aus AGENTS.md verbindlich durchsetzen?
Codex Code Review kann passende Regeln berücksichtigen und auf Verstöße hinweisen. Die Regeln sind jedoch keine harte Durchsetzung. Tests, CI, Branch-Schutz und menschliche Freigaben bleiben für verbindliche Kontrollen notwendig.
Ist Codex CLI 0.146.0 für die Modellumstellung erforderlich?
OpenAI nennt kein verpflichtendes CLI-Update als Voraussetzung für den Modellwechsel. Die neue Version bringt jedoch Verbesserungen für Sitzungen, Plugins, Verbindungen und die Wiederherstellung längerer Arbeitsläufe.
Fazit
Das Codex Update für August ist weniger spektakulär als ein neues Spitzenmodell und gerade deshalb wichtig. Bis zum 31. August müssen fest eingestellte GPT-5.4-Modelle im ChatGPT-Zugang geprüft und sinnvoll ersetzt werden. Parallel werden Multi-Repo-Reviews und projektspezifische Regeln zu Werkzeugen, die echte Teamarbeit verbessern können.
Mein Fazit fällt nüchtern aus: Codex wird nicht nur stärker, sondern organisatorischer. Der Nutzen entsteht dort, wo ein Team Modellwechsel kontrolliert, Projektwissen knapp dokumentiert und Änderungen über Repository-Grenzen hinweg sauber prüft. Genau diese Fähigkeiten entscheiden, ob aus schneller erzeugtem Code auch dauerhaft gute Software wird.
Redaktion und Einordnung: PRPG. Stand: 4. August 2026. Produktverfügbarkeit und Modellzugänge können sich ändern; maßgeblich sind die verlinkten Angaben von OpenAI.
Offizielle Quellen:
- OpenAI: ChatGPT & Codex Changelog, Einträge vom 29. bis 31. Juli 2026
- OpenAI: Codex-Modelle, Empfehlungen und Hinweise zur GPT-5.4-Ablösung
- OpenAI: Lokale Projekte, mehrere Ordner und Repository-Reviews
- OpenAI Developers: Eigene Code-Review-Regeln für Codex, 20. Juli 2026
- OpenAI: Eingebauter Browser und Umgang mit Browserdaten
- OpenAI: Chrome-Erweiterung für ChatGPT und Codex