Wenn Sie GPT-5.5 in Codex mit Ihrem ChatGPT-Konto verwenden, prüfen Sie vor dem 14.10.2026 Ihre Modellauswahl, Skripte und Teamvorgaben und testen Sie eine für Ihr Konto verfügbare Alternative. Die offizielle Modellbeschreibung nennt als betroffene Zugänge ChatGPT, ChatGPT Work und Codex mit ChatGPT-Anmeldung; die Nutzung über die OpenAI API bleibt demnach verfügbar (Modellübersicht). Entscheidend ist also Ihr Anmeldeweg – nicht allein, dass Sie Codex verwenden.
Dieser Leitfaden richtet sich an Sie, wenn Sie Codex mit einem ChatGPT-Konto nutzen und Ihre typischen Aufgaben vor der Umstellung absichern möchten.
Er ist ebenso für Sie gedacht, wenn Sie Codex-Skripte, eigene Agenten oder Teamvorgaben pflegen.
Verantworten Sie Modellzugriffe für ein Unternehmen, prüfen Sie zusätzlich, ob eine Alternative für die vorgesehenen Konten freigeschaltet ist.
Zuletzt geprüft am 13.10.2026 anhand der offiziellen Modellübersicht und der OpenAI-Änderungshinweise. Prüfen Sie vor der Umstellung erneut, ob dort Datum und betroffene Zugänge unverändert aufgeführt sind (OpenAI-Änderungshinweise).
GPT-5.5-Codex-Migration: Erst den Anmeldeweg klären
„Codex“ bezeichnet in diesem Zusammenhang nicht automatisch einen einzigen Zugang. Für die Entscheidung müssen Sie mindestens drei Fälle auseinanderhalten:
- Codex mit ChatGPT-Anmeldung: Laut offizieller Modellübersicht ist dieser Zugang vom Rückzug betroffen. Wenn Sie GPT-5.5 hier ausdrücklich auswählen oder als Teamvorgabe festlegen, planen Sie einen Wechsel vor dem genannten Datum ein.
- Codex-Sitzung mit API-Schlüssel: Laut Aufgabenabgrenzung und den offiziellen Angaben zur API bleibt GPT-5.5 über die API verfügbar. Prüfen Sie trotzdem, ob Ihr Codex-Client tatsächlich den API-Schlüssel verwendet und nicht unbemerkt mit einem ChatGPT-Konto angemeldet ist. Die API-Modellbeschreibung für GPT-5.5 dokumentiert den API-Zugang; die API-Änderungshinweise helfen, diesen von Produktänderungen in ChatGPT zu unterscheiden.
- Direkte API-Integration außerhalb von Codex: Auch hier ist der Rückzug aus den genannten ChatGPT-Zugängen nicht gleichbedeutend mit einer API-Abkündigung. Kontrollieren Sie die aktuelle API-Dokumentation und Ihre konkrete Modellkennung, bevor Sie eine Änderung an Produktionscode vornehmen.
Daraus folgt keine Garantie, dass ein Modell oder eine Anmeldeart dauerhaft unverändert bleibt. Die heute dokumentierte Ausnahme gilt für den genannten Rückzug. Sie ersetzt weder die Prüfung künftiger Änderungsmitteilungen noch eine Kontrolle Ihrer konkreten Konfiguration.
Wie erkennen Sie, ob Ihre Codex-Sitzung betroffen ist?
Prüfen Sie die Identität und Konfiguration in der Umgebung, in der Sie tatsächlich arbeiten. Eine gespeicherte Einstellung ist nicht immer ein Beleg dafür, wie eine Sitzung authentifiziert wird: Kontowechsel, Profile oder Umgebungsvariablen können dazu führen, dass Ihr Terminal und Ihre IDE unterschiedliche Zugänge verwenden.
Kontrollieren Sie deshalb nacheinander:
- Anmeldestatus im jeweiligen Client: Notieren Sie für CLI, IDE und Desktop-Anwendung, ob Sie mit ChatGPT angemeldet sind oder die Sitzung über einen API-Schlüssel betreiben. Verlassen Sie sich nicht allein auf die Konfiguration eines anderen Clients.
- Ausgewählte Modellkennung: Suchen Sie in den Einstellungen und Konfigurationsdateien nach einer festen GPT-5.5-Auswahl. Die Codex-Konfigurationsgrundlagen erklären die zentrale Konfiguration; die Konfigurationsreferenz dient zum Nachschlagen der verfügbaren Einstellungen.
- Berechtigungen im Team: Klären Sie mit der zuständigen Administration, welche Modelle für Ihre Konten und Arbeitsbereiche freigegeben sind. Ein Modell, das in einer Dokumentation erscheint, muss nicht automatisch in Ihrer konkreten Umgebung auswählbar sein.
- Tatsächliche Ausführung: Starten Sie eine kleine, ungefährliche Aufgabe und kontrollieren Sie, welches Modell und welcher Zugang verwendet werden. Halten Sie fest, ob die Sitzung erfolgreich startet und ob Modellwahl oder Anmeldung eine Fehlermeldung auslösen.
Wenn Sie GPT-5.5 in einer ChatGPT-angemeldeten Codex-Sitzung verwenden, behandeln Sie diese Sitzung als migrationspflichtig. Wenn eine Sitzung nachweislich über einen API-Schlüssel läuft, ist sie von genau diesem Produktrückzug laut Dokumentation nicht betroffen. Bleibt der Anmeldeweg unklar, klären Sie ihn erst, bevor Sie Skripte ändern.
Vor der Umstellung: Bestand und Vergleichsbasis erfassen
Die häufigste Ursache für eine unvollständige Migration ist nicht die Auswahl eines ungeeigneten Modells. Es ist eine übersehene feste Modellangabe in einem Skript, einem Editorprofil oder einer gemeinsamen Teamkonfiguration. Erstellen Sie daher zuerst ein Inventar, statt die Änderung nur in der sichtbaren Modellauswahl vorzunehmen.
GPT-5.5 finden, bevor eine Einstellung vergessen wird
Suchen Sie gezielt an diesen Stellen:
- Codex CLI: persönliche und projektbezogene Konfiguration, Startparameter sowie Skripte, die Codex aufrufen.
- IDE und Desktop-Anwendung: ausgewähltes Modell, Arbeitsbereichsvorgaben, gespeicherte Profile und Anmeldestatus.
- Aufgabenautomatisierung: CI/CD-Aufrufe, Zeitpläne, Shell-Skripte, Agenten-Workflows und Umgebungsvariablen.
- Teamverwaltung: Standardmodell, erlaubte Modellliste, Rollenvorgaben und interne Einrichtungsanleitungen.
- Fehlerbehandlung: Stellen, an denen ein Skript eine Modellkennung fest einträgt oder auf einen bestimmten Antworttext reagiert.
Für CLI-Aufrufe ist die Codex-CLI-Referenz die passende Dokumentation, um Parameter und Aufrufverhalten nachzuschlagen. Verwenden Sie sie nicht als Ersatz für das Lesen Ihrer eigenen Startskripte: Automatisierungen können zusätzliche Einstellungen aus ihrer Laufzeitumgebung übernehmen.
Erfassen Sie für jeden Fund mindestens den Speicherort, die verantwortliche Person, die Art der Authentifizierung und den Zweck der Einstellung. Vermerken Sie außerdem, ob es sich um eine lokale Nutzervorgabe oder eine gemeinsam genutzte Projektkonfiguration handelt. So verhindern Sie, dass eine persönliche Korrektur fälschlich als Teamänderung gilt – oder dass eine zentrale Vorgabe einzelne Nutzer überschreibt.
Eine belastbare Ausgangsbasis sichern
Wählen Sie typische Aufgaben aus Ihrer tatsächlichen Arbeit. Dazu können eine klar abgegrenzte Codeänderung, ein Testlauf, ein Fehlerbehebungsauftrag und eine Aufgabe mit Werkzeugaufruf gehören. Nutzen Sie keine synthetischen Beispiele, die in Ihrem Alltag nicht vorkommen. Sie sollen später erkennen, ob sich ein wichtiger Ablauf verändert, nicht eine allgemeine Modellrangliste erstellen.
Halten Sie für jede Aufgabe fest:
- Eingabe und relevanter Projektausschnitt, einschließlich der nötigen Abhängigkeiten.
- Erwartete Änderung und konkrete Abnahmekriterien, etwa bestandene Tests oder eingehaltene Schnittstellen.
- Verwendete Werkzeuge, Berechtigungen und erforderliche Bestätigungsschritte.
- Tatsächliches Ergebnis mit notwendigen manuellen Korrekturen und aufgetretenen Fehlermeldungen.
Bewahren Sie nur Daten auf, die Sie für diesen Vergleich brauchen. Entfernen Sie Geheimnisse, Zugangstoken und nicht erforderliche personenbezogene oder vertrauliche Inhalte. Beachten Sie Ihre internen Datenschutzvorgaben und die DSGVO, insbesondere wenn Sie Aufgaben mit Kundendaten oder geschütztem Quellcode prüfen. Die Vergleichsbasis muss reproduzierbar genug sein, um Unterschiede zu erkennen, aber sie darf keine sensiblen Daten unnötig vervielfältigen.
Beim Wechsel: Verfügbarkeit statt Empfehlung annehmen
Ein angekündigter Nachfolger ist nicht automatisch für jedes Konto, jeden Client und jede Aufgabe geeignet. Prüfen Sie erst, was in Ihrem Zugang auswählbar ist. Wählen Sie anschließend Kandidaten nur aus den derzeit offiziellen Modelloptionen und testen Sie sie gegen Ihre gespeicherten Aufgaben. Die offizielle Anleitung zur Modellmigration kann bei der Orientierung helfen; sie ist keine Zusicherung, dass ein bestimmtes Modell Ihre Codex-Aufgaben gleichwertig erledigt.
Entscheidung nach Zugang und Einsatzfall
Treffen Sie die Auswahl anhand dieser Bedingungen:
- Wenn Sie GPT-5.5 mit ChatGPT-Anmeldung in Codex verwenden: Wählen Sie ein in Ihrem Konto und Client verfügbares Alternativmodell. Ändern Sie die Einstellung zunächst nur in einer kontrollierten Umgebung und prüfen Sie Ihre Aufgabenstichprobe.
- Wenn Ihre Codex-Sitzung nachweislich einen API-Schlüssel verwendet: Ändern Sie die Modellkennung nicht allein wegen des Rückzugs aus ChatGPT. Lassen Sie die API-Konfiguration unverändert, bis eine konkrete API-Änderung oder ein eigener Migrationsgrund vorliegt.
- Wenn Sie die Authentifizierung nicht sicher zuordnen können: Unterbrechen Sie automatische Modelländerungen. Klären Sie zuerst Client, Profil und Anmeldestatus; protokollieren Sie den bestätigten Weg.
- Wenn die Alternative im Konto fehlt: Bitten Sie die Administration um Prüfung von Modellfreigabe, Kontoumfang und Clientversion. Legen Sie bis zur Klärung einen kontrollierten Rückfallweg fest, statt eine nicht verfügbare Kennung in Skripte einzutragen.
- Wenn eine Aufgabe vertrauliche Daten oder produktive Änderungen berührt: Lassen Sie sie nicht allein durch einen automatischen Modellwechsel laufen. Nutzen Sie die bestehende Freigabe und menschliche Prüfung weiter.
Schreiben Sie den gewählten Kandidaten und dessen Verfügbarkeit in die Teamdokumentation. Eine Empfehlung aus einer Mitteilung beschreibt eine mögliche Richtung, nicht die garantierte Eignung für Ihren Code, Ihre Werkzeuge oder Ihre Richtlinien.
Ändern Sie Modellkennung und Authentifizierungsweg nicht gleichzeitig, wenn Sie den Unterschied später noch nachvollziehen müssen. Bei getrennten Änderungen lässt sich ein Fehler eher der Modellwahl oder dem Zugang zuordnen.
Nach dem Wechsel: dieselben Aufgaben erneut prüfen
Führen Sie die gespeicherten Aufgaben mit derselben Eingabe, demselben Projektstand und möglichst denselben Werkzeugrechten aus. Halten Sie fest, welche Bedingungen sich gegenüber dem Ausgangslauf geändert haben. Wenn Sie Clientversion, Modell, Berechtigungen und Testdaten zugleich verändern, können Sie ein abweichendes Ergebnis keiner Ursache zuverlässig zuordnen.
Codex-Modellwechsel mit reproduzierbaren Kriterien abnehmen
Prüfen Sie jeden Lauf nach denselben Kriterien:
- Codeänderung: Entspricht der Patch den Anforderungen? Sind unnötige Änderungen, ausgelassene Dateien oder unerwünschte Nebenwirkungen zu erkennen?
- Testausführung: Wurden die erwarteten Tests tatsächlich gestartet? Prüfen Sie nicht nur, ob der Agent einen Testlauf erwähnt, sondern ob das Ergebnis im Arbeitsbereich vorliegt.
- Werkzeugaufrufe: Wurden Werkzeuge korrekt und im vorgesehenen Berechtigungsrahmen eingesetzt? Wurde vor einer riskanten Aktion die erforderliche Freigabe eingeholt?
- Fehlerverhalten: Hat der Agent bei fehlenden Abhängigkeiten, unklaren Anforderungen oder abgelehnten Werkzeugaufrufen einen verständlichen nächsten Schritt genannt?
- Menschliche Prüfung: Notieren Sie, welche Änderung Sie manuell korrigieren oder genauer begutachten mussten.
Bewerten Sie nicht nur die erzeugte Antwort. Bei agentischen Abläufen können auch nicht ausgeführte Tests, falsche Dateiauswahl, übersehene Abhängigkeiten und unklare Fehlerbehandlung wichtig sein. Dokumentieren Sie konkrete Abweichungen als Beobachtungen aus Ihren Läufen. Ohne eigene Messung sollten Sie daraus keine allgemeine Aussage ableiten, GPT-5.5 oder eine Alternative sei schneller, genauer oder leistungsfähiger.
Wenn eine Aufgabe nicht reproduzierbar ist, vereinfachen Sie sie zunächst oder erfassen Sie die fehlenden Voraussetzungen. Ein Test, der von nicht dokumentiertem Kontext abhängt, sagt wenig über die Migration aus. Erfassen Sie außerdem, ob das Ergebnis auf ein Modellverhalten, eine geänderte Berechtigung oder eine andere Clientkonfiguration zurückzuführen sein könnte.
API-Zugang und Rückfallweg getrennt behandeln
Kann die alternative ChatGPT-angemeldete Codex-Sitzung eine Aufgabe nicht übernehmen, wechseln Sie nicht automatisch auf einen API-Aufruf. API-Nutzung kann andere Zugangsdaten, Abrechnung, Berechtigungen, Protokollierung und Datenschutzprüfungen erfordern. Entscheiden Sie anhand Ihrer internen Freigaben, ob Sie die Sitzung erneut konfigurieren, eine andere offiziell verfügbare Option testen oder den Lauf bis zur Klärung stoppen.
Wenn Ihre Integration die API verwendet, prüfen Sie Modellkennung, Schlüsselverwaltung, Fehlerbehandlung und die Hinweise in der API-Dokumentation. Schützen Sie Schlüssel vor der Ablage in gemeinsam genutzten Skripten und Protokollen. Legen Sie fest, wer Berechtigungen ändern darf, wo Fehlermeldungen gespeichert werden und wie ein Schlüssel bei Verdacht auf Offenlegung gesperrt wird. Diese Kontrollen sind eigenständige Betriebsanforderungen und keine Folge davon, dass ein Modell in einer ChatGPT-Oberfläche nicht mehr auswählbar ist.
Für den Rückfallweg braucht Ihr Team keine pauschale Aussage wie „bei Fehlern API verwenden“. Schreiben Sie stattdessen auf, welche Person eine Umschaltung freigibt, welche Konfiguration dafür geändert wird und welche Aufgaben bis dahin manuell weiterlaufen. Ergänzen Sie Skriptkommentare und interne Anleitungen, damit niemand eine nicht mehr verfügbare ChatGPT-Modellwahl mit einer API-Abkündigung verwechselt.
Unterschiede nach Zugang und Testumgebung einordnen
Die passende Maßnahme hängt davon ab, wo Sie Codex ausführen und wie Ihr Team Tests betreibt. Die folgenden Fälle ersetzen keine Berechtigungsprüfung. Sie helfen dabei, die Migration auf den betroffenen Teil Ihres Arbeitsablaufs zu begrenzen.
| Einsatzfall | Bedeutung des Rückzugs | Was Sie prüfen sollten |
|---|---|---|
| Codex mit ChatGPT-Anmeldung | GPT-5.5 ist laut offizieller Modellübersicht im genannten Zugang betroffen. | Alternative im Konto verfügbar? Modellwahl in Client und Teamvorgabe aktualisiert? Aufgaben erneut abgenommen? |
| Codex-Sitzung mit API-Schlüssel | Der Rückzug aus den genannten ChatGPT-Zugängen bedeutet laut offizieller API-Dokumentation nicht, dass GPT-5.5 über die API entfällt. | Authentifizierung bestätigt? Modellkennung aktuell? Schlüssel, Richtlinien und Fehlerbehandlung weiterhin freigegeben? |
| Direkter API-Aufruf aus Skript oder Agent | Keine automatische Umstellung allein aufgrund der ChatGPT-Änderung ableiten. | API-Änderungshinweise prüfen, eigene Modellkennung inventarisieren und nur bei konkretem Anlass migrieren. |
| Gemischtes Team aus IDE, CLI und Automatisierungen | Verschiedene Komponenten können unterschiedliche Einstellungen und Anmeldewege nutzen. | Jede Ausführungsstelle einzeln inventarisieren; Verantwortliche und Rückfallweg dokumentieren. |
Teamübergabe: Änderungen nachvollziehbar halten
Schließen Sie die Migration erst ab, wenn die Zuständigkeiten und die geänderten Einstellungen schriftlich festgehalten sind. Dokumentieren Sie den bestätigten Zugang, die ausgewählte Alternative, den Umfang der durchgeführten Tests und bekannte Unterschiede. Halten Sie ebenso fest, welche Aufgaben noch menschlich geprüft werden müssen. So kann das Team den Wechsel später nachvollziehen, ohne aus einer einzelnen erfolgreichen Sitzung eine allgemeine Freigabe abzuleiten.
Nutzen Sie für jede Skriptänderung eine nachvollziehbare Versionsverwaltung und lassen Sie Konfigurationsänderungen von der zuständigen Person prüfen. Prüfen Sie, ob lokale und zentrale Einstellungen übereinstimmen. Wenn Ihr Team eine gemeinsame Einrichtungsseite pflegt, ergänzen Sie dort den Anmeldeweg, die erlaubten Alternativen und die Anweisung für den Fall, dass ein Modell nicht auswählbar ist.
Wenn Sie für Builds oder Integrationstests zusätzlich eine reproduzierbare Mac-Umgebung benötigen, können Sie die vmzig-Hilfe zur Nutzung als Ausgangspunkt für die Planung heranziehen. Das ist eine separate Umgebungsentscheidung: Sie ersetzt weder eine Codex-Modellfreigabe noch den Test des Modells selbst. Für temporäre Mac-Ressourcen ist Miete gegenüber einem zusätzlichen Kauf vor allem dann erwägenswert, wenn Sie ein begrenztes Testfenster oder eine klar abgegrenzte Aufgabe haben. Prüfen Sie dafür vorab die vmzig-Angebotsübersicht und vergleichen Sie den tatsächlichen Bedarf mit vorhandener lokaler Hardware oder einem direkten API-Zugang.
Bleibt Ihr bisheriger Ablauf unverändert lokal, vermeiden Sie unter Umständen einen zusätzlichen Umgebungswechsel, müssen aber lokale Ressourcen, Systempflege und den Zugriff für Teammitglieder selbst organisieren. Ein API-Zugang kann für automatisierte Abläufe passend sein, verlangt jedoch eine getrennte Prüfung von Zugangsdaten, Freigaben und Abrechnung. Wenn Sie dagegen für einen begrenzten Zeitraum einen Mac als Testumgebung brauchen, kann die Miete über vmzig den Kauf eines nur vorübergehend benötigten Geräts vermeiden. Für dauerhaft ausgelastete Workloads oder zwingend benötigte physische Schnittstellen ist Miete nicht automatisch die richtige Wahl. Treffen Sie diese Entscheidung unabhängig davon, ob Ihre GPT-5.5-Codex-Migration abgeschlossen ist.
Weiterlesen
vmzig M4 Remote-Knoten
Prüfen Sie vmzig für Ihre nächste Entwicklungsumgebung
Mit vmzig nutzen Sie einen exklusiven physischen Rechenknoten statt geteilter virtueller Ressourcen.