Codex „thread not found“: Fehlerdiagnose und Wiederherstellung

Der Codex-Fehler „thread not found“ bedeutet nicht zwangsläufig, dass Ihr Verlauf verloren ist. Prüfen Sie zuerst, ob nur das Senden scheitert oder ob sich auch die Unterhaltung nicht mehr öffnen lässt.

1. Was fehlt bei thread not found?

Codex von OpenAI kann beim Senden einer Folgeanweisung an eine bestehende Aufgabe einen Fehler wie diesen anzeigen. Die ID bezeichnet die Unterhaltung und wurde hier entfernt. Die erste Zeile ist eine Übersetzung der japanischen Meldung aus unserem Fall.

Beim Senden der Nachricht ist ein Fehler aufgetreten
thread not found: <Unterhaltungs-ID>

Dieser Artikel behandelt bestehende lokale Aufgaben in der Desktop-App. Am 21. September 2026 haben wir Protokolle fehlgeschlagener Sendeversuche von unserem eigenen Rechner mit öffentlichem Quellcode und Nutzerberichten abgeglichen. Im Mittelpunkt steht unser Windows-Fall, keine nachweislich in jeder Umgebung funktionierende Reparatur.

Die offizielle App-Server-Spezifikation erläutert: thread/read liest den gespeicherten Verlauf, ohne die Unterhaltung in den Laufzeitspeicher zu laden. Das unterscheidet sich von thread/resume, das eine Unterhaltung zur Fortsetzung der Arbeit wieder aufnimmt. Dies sind interne Kommunikationsmethoden, keine Befehle für das Chat-Eingabefeld.

Außerdem haben wir die in den gespeicherten Metadaten unseres Rechners erfasste CLI-Version 0.155.0-alpha.9 mit dem zugehörigen öffentlichen Quellcode für das Senden abgeglichen. Der Einstiegspunkt von turn/start ruft die Unterhaltung ab und liefert thread not found, wenn die Suche scheitert. Gesucht wird in der Liste der Unterhaltungen im Arbeitsspeicher. Der Fehler allein zeigt daher nicht, dass gespeicherte Dateien verschwunden sind.

notLoaded ist an sich kein Fehlerzustand. Es bedeutet, dass eine gespeicherte Unterhaltung derzeit nicht zur Ausführung geladen ist. Problematisch wird es, wenn das nötige Fortsetzen ausbleibt und die Unterhaltung keine neue Anweisung annehmen kann. Der Wortlaut allein unterscheidet weder normales Entladen noch Probleme beim Auffinden gespeicherter Daten, eine falsche Unterhaltungs-ID oder andere Ursachen.

2. Praxisfall: Senden wieder möglich, Verlauf erhalten

In der Arbeitsumgebung von AI Arte erschien der Fehler, als wir einer anderen Aufgabe eine Anweisung zur Fortsetzung schickten. Verwendet wurde die Windows-App 26.915.31029. Die folgende Zeitleiste fasst die App-Protokolle vom 21. September 2026 zusammen. Alle Uhrzeiten sind japanische Standardzeit (JST); Unterhaltungs-IDs, Arbeitsinhalte und personenbezogene Angaben wurden weggelassen.

Die gespeicherte Unterhaltung und das Arbeitsverzeichnis waren vorhanden; der Verlauf ließ sich lesen. Die ursprüngliche Aufgabe war nicht archiviert. Wir prüften Protokolle und gespeicherten Zustand ausschließlich lesend, ohne die Unterhaltungsdatenbank oder Einstellungen zu ändern.

Eine Abweichung zwischen dem Status „fortgesetzt“ in der Oberfläche und dem internen Zustand ist eine plausible Erklärung. Wir haben das Problem aber nicht reproduziert, um die genaue Entstehung dieser Abweichung zu bestimmen. Auch ist die Prüfung des Status der letzten Runden nicht gleichbedeutend mit einer Prüfung der darin erledigten Arbeit. Unsere Bestätigung der Wiederherstellung betrifft nur das Senden und den Zustand der Unterhaltung.

3. Vorgehen, wenn nur das Senden scheitert

Sichern Sie zuerst Ihren Eingabetext. Prüfen Sie vor wiederholtem Senden, ob dieselbe Anweisung bereits in der Unterhaltung steht oder schon verarbeitet wird. Eine lediglich verspätete Antwort sollte keine doppelte Ausführung auslösen – besonders bei Veröffentlichungen, Löschungen oder Käufen.

Begrenzen Sie die Prüfung beispielsweise wie unten. Das ist eine Anweisung an das Modell, kein Reparaturbefehl für die App. Das Senden und die Modellantwort können zum regulären Nutzungskontingent zählen.

Dies ist eine Verbindungsprüfung. Setze frühere Arbeiten nicht fort,
lies oder schreibe keine Dateien und rufe keine Werkzeuge auf.
Antworte ausschließlich mit „Antwort erhalten.“

Bericht #30710 im GitHub-Repository von OpenAI beschreibt einen Windows-Fall, bei dem ein Neustart Sendefehler unmittelbar nach dem Öffnen einer Unterhaltung besserte. Die offizielle Fehlerhilfe empfiehlt bei einem festhängenden integrierten Terminal, laufende Aufgaben abzuwarten und dann neu zu starten. Diese Anleitung ist kein spezielles Wiederherstellungsverfahren für diesen Sendefehler. Keine der beiden Quellen garantiert, dass ein Neustart jeden Fehler thread not found behebt.

Notieren Sie vor einem Update die aktuelle App-Version und die Symptome. Die mitgelieferte Codex-Version kann von einer separat installierten CLI abweichen. Ein reines CLI-Update belegt nicht, dass das Problem der Desktop-App behoben ist. Wir haben keine Version ermittelt, die dieses Symptom dauerhaft beseitigt.

4. Ähnliche Meldungen, unterschiedliche Ursachen

Lesen Sie nicht nur die Überschrift zum fehlgeschlagenen Senden, sondern auch den restlichen Fehlertext. Ermitteln Sie, welcher Vorgang scheitert. Die Tabelle ordnet öffentliche Berichte und unsere Beobachtungen ein; sie ist keine Rangliste der Häufigkeit.

Ein Beispiel mit weiterhin lesbarem Verlauf liefert der ergänzende Bericht eines macOS-Nutzers in #30710. Die Oberfläche behandelte die Unterhaltung als fortgesetzt, das Senden scheiterte aber wiederholt. Eine neue Instanz der Oberfläche lud sie später erfolgreich neu. Diese Zustandsabweichung lässt sich nicht allein durch eine Race Condition unmittelbar nach dem Öffnen erklären. Sie ähnelt unserem Fall, eine identische Ursache ist jedoch nicht bewiesen.

Dagegen beschreibt der Windows-Bericht #39179 Fehler beim Senden und Archivieren, die auch nach einem Neustart bestanden. #39575 enthält ebenfalls eine Diagnose zu Zeitstempeln in gespeicherten Dateinamen und zur Suche nach diesen Dateien. Es handelt sich jedoch um Untersuchungen von Nutzern. Ein Pfadpräfix oder ein Zeitzonenunterschied allein beweist keine Beschädigung Ihrer eigenen Daten.

Für Fehler nach einer Wartezeit siehe den Bericht zu Sende-Timeouts in #27395; für Fehler, die auch das Stoppen betreffen, siehe den Bericht zur Abweichung zwischen Verlauf und Laufzeitstatus in #42604. Berichte mit ähnlichen Meldungen belegen nicht, dass das Problem unter allen Nutzern häufig auftritt. Unsere Untersuchung ergab keine Häufigkeitsmessung mit Nutzerzahlen oder Sendeversuchen als Bezugsgröße.

5. Weitere Prüfungen und Übergabe bei anhaltenden Problemen

Falls ein Neustart nicht hilft, prüfen Sie, ob der gespeicherte Verlauf lesbar ist. Wenn Ihre Umgebung es erlaubt, die betroffene Aufgabe aus einer anderen funktionierenden Codex-Aufgabe zu untersuchen, beginnen Sie mit einer reinen Leseprüfung. Prüfen Sie die Ziel-ID, statt nur eine ähnlich benannte Aufgabe auszuwählen.

Untersuche die Zielaufgabe ausschließlich lesend.
Ziel-ID: Hier die Unterhaltungs-ID aus der Fehlermeldung einfügen

Berichte, ob der Verlauf lesbar ist, welchen Status die letzte Runde hat
und ob Fehler vorliegen. Sende keine Nachrichten an andere Aufgaben.
Setze frühere Arbeiten nicht fort, erstelle keinen Fork, archiviere nichts,
ändere weder Einstellungen noch Datenbank und verschiebe oder lösche
keine Verlaufsdateien. Falls Aufgabenverwaltungswerkzeuge fehlen,
weise auf diese Einschränkung hin.

Dieses Anfragebeispiel setzt eine Umgebung mit Werkzeugen zur Aufgabenverwaltung voraus. Solche Werkzeuge gibt es nicht in jeder Oberfläche oder CLI. Wenn die Funktion fehlt, müssen Sie keine ähnlich benannten internen Befehle erraten und ausführen.

Ein ergänzender Bericht in #39179 beschreibt eine kurze Prüfung, die aus einer anderen funktionierenden Aufgabe gesendet wurde. Nach deren abgeschlossener Antwort war auch die normale Unterhaltung wieder möglich. Allerdings berichtet ein weiterer Kommentar, dass derselbe Sendeversuch scheiterte, während ein Fork des abgeschlossenen Verlaufs eine neue Anweisung annahm. Angesichts dieses Gegenbeispiels stellte der frühere Berichterstatter klar, dass es keine allgemeine Lösung ist.

Ein Fork ist eine Möglichkeit, abgeschlossenen Verlauf in eine andere Aufgabe zu übernehmen, keine Reparatur der ursprünglichen Aufgabe. Gehen Sie nicht davon aus, dass unerledigte Arbeit unverändert übernommen wird. Prüfen Sie nach der Übergabe Arbeitsverzeichnis, geänderte Dateien und den letzten abgeschlossenen Schritt. Ein öffentlicher Bericht über eine angenommene neue Anweisung garantiert ebenfalls nicht, dass die anschließende Arbeit korrekt beendet wurde.

Auch Unterhaltungsverlauf und Arbeitsdateien sind getrennt. Projektänderungen können vorhanden sein, obwohl sich die Unterhaltung nicht öffnet. Umgekehrt garantiert ein lesbarer Verlauf keine aktuellen Dateien. Prüfen Sie in einem Git-Projekt die Änderungen und klären Sie vor dem Fortsetzen, was bereits ausgeführt wurde.

6. Angaben für eine hilfreiche Fehlermeldung

Trennen Sie erfolgreiche von fehlgeschlagenen Vorgängen, statt nur „Senden geht nicht“ zu melden. App-Version, Betriebssystem, Uhrzeit und Zeitzone, Unterhaltungs-ID und vorherige Aktion helfen, Fehlerarten zu unterscheiden. Sie müssen nicht gleich die gesamte Unterhaltung veröffentlichen.

Wenn Sie Protokolle prüfen können, betrachten Sie den Bereich um die fehlgeschlagene Anfrage. method=turn/start kennzeichnet den Start einer Anweisung, thread/resume setzt eine Unterhaltung fort und errorCode gibt Hinweise auf die interne Antwort. Bewahren Sie auch erfolgreiche Einträge auf. Unterscheiden Sie einen Fehler in mehreren Protokollzeilen von mehreren tatsächlich fehlgeschlagenen Anfragen.

Auf unserem Windows-Rechner lagen die App-Protokolle unter %LOCALAPPDATA%\Codex\Logs. Das ist der auf diesem Rechner bestätigte Speicherort, keine Garantie für jede Distribution. Laut offizieller Dokumentation liegen Sitzungen unter $CODEX_HOME/sessions, standardmäßig unter ~/.codex/sessions. Abweichende Einstellungen oder Ausführungsziele können bedeuten, dass die gesuchten Daten lediglich in einem anderen Ordner liegen. Ein erfolgloser Suchlauf beweist keine Löschung.

Die offizielle Fehlerhilfe beschreibt das Senden von Feedback durch Eingabe von / im Eingabefeld. Protokolle und Screenshots können Gesprächsinhalte, E-Mail-Adressen, Namen anderer Projekte und lokale Pfade enthalten. Veröffentlichen Sie in einem Issue nur notwendige, anonymisierte Ausschnitte. Prüfen Sie vor der Weitergabe vollständiger IDs oder ähnlicher Angaben den Empfänger und die Sichtbarkeit der Meldung.

7. Wiederherstellung mit einer kurzen Antwort prüfen

Prüfen Sie statt einer sofortigen Löschung des Verlaufs drei Dinge getrennt: Lässt er sich lesen, lässt sich die Unterhaltung fortsetzen und kann eine neue Anweisung abschließen? In unserem Fall gelang das Senden nach erneutem Laden. Das beweist aber nicht, dass dieselbe Methode auch unabhängige Speicherfehler behebt.

Prüfen Sie nach einer abgeschlossenen kurzen Antwort, wie weit die ursprüngliche Anweisung gekommen ist, und setzen Sie am passenden Schritt fort. Besteht das Problem weiter, haben lesende Untersuchung und Protokollsicherung Vorrang. Eine verschwundene Fehlermeldung oder ein erfolgreich erstellter Fork reicht nicht aus, um die Wiederherstellung als abgeschlossen zu bewerten.

Claude Code kann außerdem den Fehler Prompt is too long bei zu großer Eingabe oder MCP error -32000: Connection closed bei Problemen mit externen Werkzeugverbindungen melden. Das sind andere Fehler in einem anderen Produkt. Auch wenn das Symptom wie „Ich kann der KI keine Anweisungen geben“ aussieht, richten Sie das Vorgehen nach Produktname und vollständiger Fehlermeldung aus. Übernehmen Sie die dortigen Diagnosebefehle nicht einfach in eine Codex-Unterhaltung.

FAQ

Q. Bedeutet thread not found, dass die Unterhaltung gelöscht wurde?
A. Nicht unbedingt. Der gespeicherte Verlauf kann lesbar bleiben, obwohl die für den Nachrichtenempfang nötige Laufzeitunterhaltung nicht geladen ist. Allerdings können auch Verweise auf gespeicherte Daten oder die Dateien selbst fehlerhaft sein. Prüfen Sie daher, ob sich der Verlauf tatsächlich lesen lässt.

Q. Ist notLoaded ein Fehler?
A. Der Statusname allein belegt keinen Fehler. Er kann den normalen Zustand einer gespeicherten, derzeit nicht zur Ausführung geladenen Unterhaltung beschreiben. Prüfen Sie, ob sie beim Fortsetzen wieder aufgenommen wird und eine kurze Antwort abschließt.

Q. Hilft ein Neustart immer?
A. Nein. Einige Berichte beschreiben eine Besserung, andere weiterhin bestehende Speicher- oder Archivierungsfehler nach dem Neustart. Auf unserem eigenen Rechner beobachteten wir erfolgreiches Senden nach dem Neuladen der Unterhaltung; einen Neustartversuch führten wir nicht durch.

Q. Behebt ein Update auf die neueste Version das Problem?
A. Zum Zeitpunkt unserer Prüfung war keine bestimmte Version bestätigt, die diese gesamte Symptomgruppe behebt. Notieren Sie App-Version und Ergebnisse vor und nach dem Update. Eine separat installierte CLI und die in der App enthaltene Codex-Version sind nicht zwangsläufig identisch.