Codex-Browser funktioniert nicht: Zwei Wiederherstellungsfälle

Die Seite war sichtbar, aber Codex konnte den Browser nicht steuern. Zwei Probleme auf demselben Computer – eine fehlende Browserverbindung und eine zurückgebliebene Fehlerseite – erforderten unterschiedliche Schritte zur Wiederherstellung. Dieser Artikel erklärt die Reihenfolge der Prüfungen und was tatsächlich wieder funktionierte.

Integrierter Browser, Chrome-Anbindung und Websuche

Die Aufforderung an Codex, etwas „im Browser nachzusehen“, nutzt nicht immer denselben Mechanismus. Festzustellen, welche Funktion ausfällt und welche Handlung nicht gelingt, hilft unnötige Einstellungsänderungen zu vermeiden.

Die offizielle Browserdokumentation von OpenAI beschreibt, dass Codex in der Desktop-App den integrierten Browser öffnen, klicken, tippen und Seiten untersuchen kann. Sie sagt nicht, dass CLI oder IDE-Erweiterung selbst einen integrierten Browser besitzen. Zuerst ist also zu unterscheiden, wo Sie Codex verwenden.

Der integrierte Browser hat ein eigenes Profil, getrennt vom gewöhnlichen Browser. Eine installierte Chrome-Erweiterung belegt daher keine aktive Verbindung zur Steuerung des integrierten Browsers. Umgekehrt gibt ein funktionierender integrierter Browser nicht automatisch bestehende Chrome-Tabs frei. OpenAIs Erklärung zu Browser und Profil

In dieser Untersuchung hatte der integrierte Browser Vorrang. Mit Chrome prüften wir einen getrennten Verbindungsweg. Seitenanzeige, Browserverbindung und die Bedienung einer einzelnen Website wurden nicht zu einem einzigen „funktioniert oder funktioniert nicht“ zusammengefasst.

Die Seite öffnet sich, aber Codex findet den Browser nicht

Auslöser waren Berichte von Codex, dass zuvor funktionierende Browseraktionen nicht mehr möglich seien. Der Browser war in den App-Einstellungen aktiviert, und Chrome zeigte die Erweiterung als installiert an. Seiten ließen sich im integrierten Browser auch tatsächlich öffnen.

Die Bestandsabfrage der Steuerschnittstelle konnte jedoch weder den integrierten Browser noch Chrome abrufen. Sichtbar war nur ein Ziel für eine separate MCP-Apps-Oberfläche. Die für den Benutzer sichtbare Ansicht entsprach nicht den für Codex verfügbaren Steuerzielen.

Zur Bestätigung der Wiederherstellung mussten wir neben der Anzeige prüfen, ob Codex den Tab abrufen, seinen Inhalt lesen und Links verwenden konnte.

Zunächst drei Symptome unterscheiden

Ein Verbindungsproblem wie in diesem Fall erfordert andere Prüfungen als ein Fehler auf nur einer Website. Stellen Sie zuerst fest, wie weit die Bedienung gelingt.

Formulieren Sie den Test genauer als „Browser reparieren“: Fordern Sie öffentliche Seite öffnen → Überschrift lesen → sichtbaren Link anklicken → zurückgehen. So werden eine erfolgreiche Websuche und erfolgreiche Browserklicks nicht verwechselt.

Ein anderer Chat, in dem einfaches Neuladen half

In einem anderen Entwicklungs-Chat blieb nach dem Stopp eines lokalen Servers die Seite „Diese Website ist nicht erreichbar“ im Tab zurück. Auch nachdem der Server wieder lief, wurde Codex beim Abruf des Tabs abgewiesen, weil das URL-Format nicht erlaubt war.

Die reguläre Tab-Bestandsabfrage meldete als tatsächliche URL das Format data:, das HTML direkt enthält. Als der Benutzer denselben Tab normal neu lud, war die tatsächliche URL wieder HTTP, und Codex konnte Überschriften und Schaltflächen lesen. Weder ein Neustart der gesamten App noch eine Berechtigungsänderung war nötig.

Das unterscheidet sich von einer in der Bestandsabfrage fehlenden Browserverbindung. In jenem Chat wurde nur das Lesen der Inhalte bestätigt, nicht das Betreten oder Steuern des Spiels. Auch die interne Ursache zuvor protokollierter Fehler beim Verbindungsweg blieb ungeklärt.

Änderungen vor der Wiederherstellung

Auf diesem Computer lagen die tatsächlichen Codex-Home-Daten bereits unter D:\CodexHome. Das standardmäßige %USERPROFILE%\.codex war eine Junction zu Laufwerk D. Die benutzer- und systembezogenen Variablen CODEX_HOME waren jedoch nicht gesetzt.

OpenAI dokumentiert CODEX_HOME als Stammverzeichnis für Einstellungen, Authentifizierung, Protokolle, Sitzungen, Skills und zugehörige Zustandsdaten. Wir testeten hier damit die direkte Angabe des vorhandenen tatsächlichen Pfads auf Laufwerk D. Als spezieller Schalter zur Browserreparatur ist es nicht dokumentiert. OpenAIs Dokumentation der Umgebungsvariablen

1. Wir beendeten die App und zugehörige Codex-Prozesse. Nachdem der Benutzer bestätigt hatte, dass die Arbeit in anderen Chats abgeschlossen war, sicherten wir die Daten bei beendeten Prozessen.
2. Wir kopierten Home und weitere Daten und prüften den Inhalt. Für etwa 68.6GB in 445,279 Dateien verglichen wir Dateianzahl, Größen und Änderungszeiten sowie zusätzlich die Hashes von 144 wichtigen Dateien.
3. Wir gaben für einen einzelnen Start den tatsächlichen Pfad auf Laufwerk D an. Nach dem vollständigen Beenden starteten wir dieselbe App-Version und prüften, dass Shell und erzeugte Steuerungskonfiguration auf Laufwerk D verwiesen.
4. Wir testeten den integrierten Browser und Chrome getrennt. Beide ließen sich abrufen; das Lesen von Seiten und die Bedienung von Links gelangen.
5. Wir prüften auch den normalen Start. Nach der Zustimmung setzten wir die Benutzerumgebungsvariable. Eine neue, über die Taskleiste gestartete App-Instanz nutzte dieselben Verweise und bestand dieselben Bedienprüfungen.

Wichtig ist die Reihenfolge: Wir verschoben nicht zuerst die App selbst auf ein anderes Laufwerk. Die Browserwiederherstellung wurde vor dem App-Umzug bestätigt. Während dieses späteren Umzugs trat ein anderer Fehler auf. Dieser Fall stützt daher nicht den Einsatz der Windows-App-Verschiebefunktion zur Browserreparatur.

Wir löschten auch keine Junction und schrieben die MCP-Konfiguration nicht von Hand um. Stattdessen lasen wir die nach dem Start erzeugten Verweise, um ihre Übereinstimmung mit dem vorgesehenen Zustand zu prüfen. Den Unterschied zwischen Home und App selbst erklärt unser Bericht über den Wechsel von Laufwerk C auf ein anderes Laufwerk.

Bedienprüfungen zur Bestätigung

Nach der Wiederherstellung prüften wir nicht nur, ob der Browser in der Bestandsliste erschien, sondern bedienten öffentliche Seiten. Dafür waren weder Anmeldung, Kauf noch Datei-Upload durch den Benutzer nötig.

Eine Liste bestehender privater Chrome-Tabs bewahrten wir nicht als Artikelbeleg auf. Ein neu erstellter Testtab genügte zur Bestätigung der Wiederherstellung. Eine Browseruntersuchung erfordert nicht das Sammeln geöffneter E-Mails oder interner Unternehmensseiten.

Auch gespeicherte Zustandsdaten wurden geprüft. Ausgewählte Einträge, darunter 2 angeheftete Chats, 18 angeheftete Projekte und 63 lokale Projekte, stimmten mit der Sicherung überein. Die Prüfung des CLI-Anmeldestatus war ebenfalls erfolgreich. Verlauf musste nicht neu aufgebaut und Anmeldung nicht wiederholt werden.

Ein App-Neustart unterscheidet sich von einem PC-Neustart. Ersteren haben wir geprüft; Prüfungen nach einem PC-Neustart und künftigen App-Updates wurden auf einen passenden Zeitpunkt verschoben. Die Ergebnisse betreffen unmittelbare Wiederherstellung und normalen App-Start.

Was Sie anfangs vermeiden sollten

Das Löschen von App-Daten oder Browserprofilen, bevor Verbindungs-, Website- und Speicherortprobleme getrennt wurden, kann Anmeldungen und Einstellungen verlieren lassen und Vergleichsbelege entfernen. In diesem Fall löschten wir zur Wiederherstellung weder sämtliche Browserdaten noch installierten wir die App neu.

Auch alte Browser-Skills wiederherzustellen war nicht unsere Standardmaßnahme. Auf dem untersuchten Computer gehörte ihr Fehlen zur Umstellung auf einheitliches Computer Use. Eine fehlende alte Datei allein reicht nicht aus, um sie als Fehlerursache zu identifizieren.

Wir verwendeten keine undokumentierten internen Einstellungen, patchten keinen App-Code und ersetzten keine ausführbaren Dateien. Ein Versionswechsel könnte eine Funktion scheinbar wiederherstellen; es wäre dann aber kein Vorher-nachher-Vergleich mit derselben Version wie hier.

Ebenso mussten wir Sicherheitseinstellungen nicht schrittweise lockern, da die nötigen Berechtigungen für integrierten Browser und Chrome bereits aktiviert waren. Die Erlaubnis zur Steuerung einer Website ist davon getrennt, ob ihrem Inhalt vertraut werden sollte. Wählen Sie für den Wiederherstellungstest eine Seite ohne sensible Informationen oder folgenreiche Aktionen.

Was bei anhaltenden Fehlern festzuhalten ist

Für Support oder weitere Untersuchungen ist eine Aufzeichnung, wie weit einzelne Schritte gelangen, hilfreicher als ein allgemeines „funktioniert nicht“. Der wichtige Unterschied hier: Zuvor ließen sich Seiten anzeigen, aber Steuerziele nicht abrufen; nach der Wiederherstellung funktionierte selbst die Linknavigation.

• App-Version und Verwendung als Desktop-App, CLI oder in der IDE.
• Ob das Problem den integrierten Browser, Chrome oder beide betrifft.
• Ob die Seite manuell geöffnet werden kann und ob Codex sie lesen und darin klicken kann.
• Ob nur eine Website oder auch öffentliche Seiten ohne Anmeldung betroffen sind.
• Ob die App vollständig beendet und als neue Instanz gestartet wurde sowie ob ein anderes Laufwerk oder eine eigene Home-Einstellung verwendet wird.
• Zeitpunkt des Fehlers und tatsächliche Fehlermeldung. Rohprotokolle mit Geheimnissen ausschließen.

Unterscheiden Sie beim Prüfen des Home-Speicherorts zwischen $env:CODEX_HOME der Shell, der Windows-Benutzereinstellung und dem Wert der laufenden App. Wer keinen eigenen Speicherort verwendet, muss diesen Fall nicht nachahmen und auf einen leeren Ordner auf Laufwerk D verweisen.

Wenn sich der Verlauf nicht öffnen lässt oder nur das Senden fehlschlägt, liegt nicht zwingend ein Browsersteuerungsproblem vor. Abhängig von der angezeigten Meldung hilft auch unser bestehender Artikel Codex thread not found und Prüfung des Verlaufs.

Eine aus diesem Fall abgeleitete Prüfreihenfolge

Prüfen Sie zunächst, wo Sie Codex verwenden und um welchen Browser es geht. Bleibt nach der Serverwiederherstellung eine Fehlerseite zurück, laden Sie diesen Tab normal neu. Testen Sie anschließend Anzeige, Lesen und Klicken getrennt auf einer öffentlichen Seite. Fehlt jede Browserverbindung, sichern Sie Ihre Arbeit und erwägen vollständiges Beenden und Neustarten der App. Bei Computern mit eigenem Home-Speicherort kann auch die Prüfung des referenzierten Pfads helfen.

Auf diesem Computer half die Kombination aus direkter Angabe des tatsächlichen, bereits vorhandenen Home-Pfads auf Laufwerk D und einem Start nach vollständigem Beenden. Die Wiederherstellung ist belegt, die Junction jedoch nicht als alleinige Ursache. Reversible Änderungen einzeln zu prüfen ist praktikabler, als App-Umzüge oder Datenlöschung als allgemeine Lösung zu behandeln.

Häufige Fragen

Wenn ich die Seite sehe, kann Codex sie dann steuern?

Auf diesem Computer war die Seite sichtbar, ließ sich aber nicht als Steuerziel abrufen. Prüfen Sie zusätzlich das Lesen von Inhalten und Anklicken von Links.

Repariert die Installation der Chrome-Erweiterung den integrierten Browser?

Integrierter Browser und Chrome-Anbindung verwenden getrennte Wege. Prüfen Sie, welcher ausfällt. Auch wir haben beide separat getestet.

Hilft CODEX_HOME immer?

Das haben wir nicht festgestellt. Hier wurden tatsächlicher Pfad und vollständiges Beenden mit Neustart gemeinsam geändert, danach funktionierte es wieder. Daraus folgt keine Empfehlung, bei unverändertem Speicherort zuerst das Home-Verzeichnis umzuziehen.

Muss ich die App zur Wiederherstellung auf Laufwerk D verschieben?

Der Browser funktionierte vor dem Verschieben der App selbst wieder. Das Verschieben einer Windows-App ist von der Reparatur der Browsersteuerung zu trennen.