Codex: Neuer Chat scheitert mit „Cannot serialize value“ – was prüfen?

Wenn ein neuer Codex-Chat mit Cannot serialize value: (couldn't stringify value) scheitert, notieren Sie zuerst die installierte Version und suchen Sie nach einem Update. Besteht der Fehler weiterhin, vergleichen Sie im selben Projekt einen neuen Local-Chat mit einem neuen Worktree-Chat. Löschen Sie nicht als Erstes den Chatverlauf, tauschen Sie keine API-Schlüssel aus und setzen Sie das Repository nicht zurück.

Genau dieser Fehler wurde im Oktober 2026 in der Desktop-App gemeldet. Der zugehörige Issue ist inzwischen geschlossen; Nutzer berichten für bestimmte macOS- und Windows-Builds von einer Behebung. Deshalb ist ein Versionsabgleich sinnvoller als die Annahme, der damalige Fehler betreffe weiterhin jede Installation.

Diese Anleitung behandelt neue Chats, bei denen bereits das Absenden scheitert, insbesondere im Modus Worktree. Sie stützt sich auf öffentliche Berichte und ein vorsichtiges Diagnoseverfahren. Ofox hat den ursprünglichen Fehler nicht in einer kontrollierten Installation reproduziert. Die folgenden Schritte sind Prüfungen und bedingte Ausweichmöglichkeiten, keine allgemeingültige Reparatur und keine Behauptung, ein Ofox-API-Schlüssel könne Codex reparieren.

Vor einem alten Workaround zuerst die Version prüfen

Die folgende Zusammenfassung beruht auf Issue #55744 im OpenAI-Repository, geprüft am 28. Oktober. Es handelt sich um Nutzerberichte, nicht um eine plattformübergreifende Support-Matrix.

Der macOS-Kommentar zur Behebung und der Windows-Kommentar zur Behebung sind getrennte Beobachtungen. Zeigt der Updater bei einem älteren Build „aktuell“ an, beschreibt das nur, was diese Installation derzeit beziehen kann. Es beweist nicht, dass die für eine andere Plattform gemeldete Korrektur installiert ist.

Speichern Sie den noch nicht gesendeten Prompt an einem privaten Ort, beenden oder pausieren Sie laufende Arbeiten und nutzen Sie dann die vorgesehene Update-Funktion der Anwendung. Notieren Sie die Version davor und danach. Starten Sie die App neu, wenn der Updater dies verlangt, öffnen Sie dasselbe Projekt und senden Sie erneut eine kleine Testnachricht. Laden Sie kein älteres App-Paket von einem inoffiziellen Spiegelserver herunter und verändern Sie keine installierten Anwendungsdateien.

Prüfen, ob es wirklich derselbe Fehler ist

„Serialisierung“ bezeichnet das Umwandeln eines Werts für die Übertragung oder Speicherung. Aus dem Wortlaut allein geht nicht hervor, welcher Wert betroffen ist, ob eine Modellanfrage gesendet wurde oder ob Ihr Repository beschädigt ist.

Halten Sie drei Dinge fest, bevor Sie Einstellungen ändern:

1. Zeitpunkt: Öffnet sich die App nicht, lässt sich die erste Nachricht nicht absenden oder scheitert eine bereits laufende Aufgabe später?
2. Modus: Wurde der neue Chat in Local oder Worktree angelegt? War er mit einem Git-Projekt verbunden?
3. Genaue Meldung: Kopieren Sie die vollständige kurze Fehlermeldung einschließlich des Textes in Klammern. Erfassen Sie daneben angezeigte Fehler getrennt.

Lautet die Meldung tatsächlich couldn’t load workspace settings, prüfen Sie die Initialisierung des Arbeitsbereichs. Meldet die Erweiterung couldn’t load its resources, verwenden Sie die Anleitung zum Laden der Ressourcen. Steht im Eingabebereich permission mode is unavailable, folgen Sie der entsprechenden Checkliste zum Absenden. Ein ähnlicher Zeitpunkt belegt keine gemeinsame Ursache.

Der Issue enthält Untersuchungen zur clientseitigen Serialisierung, darunter eine Hypothese zu Attributen von Rich-Text-Dokumenten. Diese Berichte helfen, eine mögliche Fehlerstelle einzugrenzen. Sie rechtfertigen nicht, allen Nutzern das Entfernen von Satzzeichen oder chinesischem Text oder das Umschreiben der JSON-Dateien eines Repositorys zu empfehlen. Ein kurzer Prompt als einfacher Text eignet sich als Kontrolltest, nicht als garantierte Lösung.

Local und Worktree vergleichen, ohne Projektänderungen zu riskieren

Verwenden Sie einen reinen Diagnose-Prompt statt der eigentlichen Aufgabe:

Antworte ausschließlich mit OK. Lies oder ändere keine Dateien,
führe keine Befehle aus, installiere keine Abhängigkeiten und beginne
keine Projektaufgabe.

Lassen Sie Konto, Projekt und Version unverändert. Testen Sie zuerst einen neuen Local-Chat, danach einen neuen Worktree-Chat mit demselben Prompt. Beim Anlegen eines Worktrees kann der konfigurierte Setup-Prozess eines Projekts ausgeführt werden. Prüfen Sie diese Konfiguration vorher und verwenden Sie ein unkritisches Test-Repository, falls das Setup Nebenwirkungen hätte. Wiederholen Sie den Test nicht in mehreren Produktionsprojekten, nur um weitere Beispiele zu sammeln.

Beenden Sie die Versuche, sobald sich ein aussagekräftiger Unterschied zeigt. Wiederholtes Klicken auf „Senden“ erzeugt zusätzliche Meldungen und erschwert es, den ersten Fehler zu erkennen. Eine Modellantwort in Local belegt nur, dass dieser Weg zu diesem Zeitpunkt funktioniert hat. Sie prüft weder die Isolation noch das Worktree-Setup.

Wenn Local funktioniert: die Übergangslösung bewusst wählen

Local arbeitet im ausgewählten Checkout. Ein separater Worktree stellt ein anderes Arbeitsverzeichnis bereit. Der Wechsel zu Local ändert somit, wo Projektoperationen stattfinden können; er bietet nicht dieselbe Isolation.

Für ein rein lesendes Gespräch kann ein funktionierender Local-Chat ausreichen. Bevor Sie Änderungen zulassen, prüfen Sie den Checkout und stimmen Sie sich mit anderen Arbeiten ab, die ihn nutzen. Sichern Sie nicht committete Änderungen und nicht versionierte Dateien. Verwenden Sie git reset --hard, git clean oder das Löschen von Caches nicht als allgemeine Reparatur für Serialisierungsfehler.

Für Aufgaben, die Isolation erfordern, finden sich im Issue Berichte über den Start in Local mit anschließender Erstellung eines von der App verwalteten Worktrees. Das ist eine bedingte Alternative: Nutzen Sie sie nur, wenn Ihre installierte App diese Funktion tatsächlich bereitstellt, und prüfen Sie das zurückgegebene Verzeichnis vor jeglichen Änderungen. Eine geeignete Anweisung lautet:

Ändere den aktuellen Checkout nicht. Ermittle zuerst den vorgesehenen
Start-Branch oder Commit und nenne den aufgelösten Commit. Erstelle
über die unterstützte App-Funktion einen separaten verwalteten
Worktree, falls diese Funktion verfügbar ist. Nenne sein absolutes
Verzeichnis und seinen HEAD. Führe alle späteren Projektoperationen
in diesem Verzeichnis aus. Wenn Erstellung oder Zuordnung scheitert,
stoppe vor jeder Dateiänderung und melde den Fehler.

Setzen Sie als Startrevision diejenige ein, die Ihre Aufgabe tatsächlich erfordert; übernehmen Sie nicht blind master. Ein neuer Worktree enthält nicht automatisch die uncommitteten Änderungen des ursprünglichen Checkouts. Werden diese benötigt, planen Sie ihre Übertragung ausdrücklich, nachdem Sie sie gesichert haben.

Prüfen Sie vor dem Fortfahren den zurückgegebenen Pfad mit rein lesenden Git-Befehlen:

git -C /absolute/path/to/worktree rev-parse --show-toplevel
git -C /absolute/path/to/worktree rev-parse HEAD
git -C /absolute/path/to/worktree status --short
git -C /absolute/path/to/worktree worktree list

Verwenden Sie Ihren tatsächlichen Pfad und setzen Sie ihn bei Leerzeichen in Anführungszeichen. Prüfen Sie, ob es ein separates Verzeichnis ist, ob der Commit der vereinbarten Startrevision entspricht und ob etwaige anfängliche Änderungen nachvollziehbar sind. Ein angelegtes Verzeichnis allein belegt nicht, dass die App es zugeordnet hat oder spätere Befehle darin ausgeführt werden. Kann die App die unterstützte Funktion nicht bereitstellen, bleiben Sie bei rein lesender Arbeit oder verwenden Sie einen bereits unterstützten Entwicklungsweg. Bezeichnen Sie eine einfache Ordnerkopie nicht als verwalteten Worktree.

Diagnosedaten für einen hilfreichen Fehlerbericht sammeln

Nutzen Sie den vorgesehenen Feedback- oder Diagnoseweg der App. Die öffentlichen Berichte enthalten TypeError, Fehler beim Absenden aus dem Eingabebereich und mode=worktree. Suchen Sie nach dem zugehörigen Ereignis zum Zeitpunkt Ihres eigenen Tests, statt den Stacktrace einer anderen Person zu kopieren.

Erfassen Sie nur das relevante Ereignis und seinen Kontext. Ein unverarbeitetes Protokoll kann Prompts, lokale Pfade, Repository-Namen, Authentifizierungsdaten oder Sitzungskennungen enthalten. Entfernen oder anonymisieren Sie diese vor der Weitergabe. Die folgende Vorlage ist eine redaktionelle Arbeitshilfe, kein tatsächlich beobachtetes Protokoll:

Betriebssystem und Architektur:
Version/Build der Desktop-App:
Testzeit und Zeitzone:
Genaue sichtbare Fehlermeldung:
Neuer oder bestehender Chat:
Projekttyp: Git / ohne Git / kein Projekt
Local-Test: erfolgreich / genaue Fehlermeldung / nicht getestet
Worktree-Test: erfolgreich / genaue Fehlermeldung / nicht getestet
Angebotenes Update und Ergebnis:
Wurde ein Worktree-Verzeichnis angelegt?
Relevante bereinigte Diagnosefelder:
Änderungen zwischen den Tests:

Bezeichnen Sie einen vorgeschlagenen Serialisierungsmechanismus nicht als bestätigte Ursache auf Ihrem Rechner. Für die Verantwortlichen ist entscheidend, ob der Fehler auftritt, bevor ein Worktree existiert, während des Setups oder nachdem eine Aufgabe gestartet wurde. Beschreiben Sie diesen Unterschied und eine minimale Reproduktion, ohne proprietären Quellcode hochzuladen.

Feststellen, ob die Funktion wiederhergestellt ist

Wiederherstellung bedeutet, dass der benötigte Vorgang wieder funktioniert – nicht nur, dass ein Hinweis verschwindet. Bei einem Fehler der direkten Worktree-Erstellung prüfen Sie, ob ein neuer Worktree-Chat den kleinen Prompt annimmt, die App den vorgesehenen Checkout anzeigt und sich auch ein zweiter neuer Chat starten lässt. Fahren Sie dann mit einer kleinen echten Aufgabe im geprüften Verzeichnis fort und kontrollieren Sie deren Änderungen.

Funktioniert nur Local, dokumentieren Sie: Vorübergehende Alternative verfügbar; direkte Worktree-Erstellung scheitert weiterhin. Ist kein Update verfügbar, bewahren Sie Versionsangabe und Diagnosedaten für den Support auf. Hat sich die Fehlermeldung geändert, untersuchen Sie das neue Fehlerbild mithilfe des Codex-Fehlerverzeichnisses, statt alle Maßnahmen aus dem alten Thread auszuprobieren.

Ofox veröffentlicht diese Anleitung für Entwickler. Ein Wechsel des Modellanbieters, der Kauf von API-Guthaben oder höhere Modelllimits belegen keine Behebung eines Serialisierungsfehlers in der Desktop-App.