Codex « thread not found » : solutions et reprise sans effacer l'historique

L'erreur « thread not found » de Codex peut apparaître même lorsque l'historique est conservé. Elle ne signifie pas forcément que la conversation a disparu. Sans supprimer l'historique, essayez dans l'ordre : rouvrir la même tâche, redémarrer complètement l'application, puis envoyer un court message de vérification. Si une erreur de stockage (comme os error 2) apparaît aussi, la solution est différente.

1. Ce que signifie « thread not found » : ce qui est introuvable

Lorsque vous ajoutez une suite à une tâche existante dans Codex d'OpenAI, une erreur de ce type peut apparaître. L'identifiant à la fin désigne la conversation concernée ; il est masqué ci-dessous.

メッセージの送信中にエラーが発生しました
thread not found: <identifiant de la conversation>

Dans l'application affichée en anglais, la première ligne devient Error submitting message (#30710).

Error submitting message
thread not found: <identifiant de la conversation>

Cet article concerne les tâches locales existantes de l'application de bureau. Il s'appuie sur les journaux d'un cas observé dans notre environnement (Windows), sur le code source public et sur des signalements d'utilisateurs, et reflète la situation au 21 septembre 2026.

L'affichage de l'historique et l'acceptation de nouvelles instructions sont deux mécanismes distincts. Pour une tâche que vous n'avez pas utilisée depuis un moment, l'historique peut se charger alors que la conversation n'est pas chargée côté réception des instructions. Envoyer tel quel produit alors cette erreur.

2. Cas pratique : l'envoi a repris alors que l'historique était conservé

Voici un cas observé dans notre environnement. Cette erreur est apparue lorsque nous avons envoyé une instruction de poursuite sur une tâche de l'application Windows 26.915.31029. Les journaux de l'application du 21 septembre 2026 ci-dessous sont convertis en UTC ; les identifiants de conversation et le contenu des tâches ont été omis.

La conversation enregistrée et le répertoire de travail étaient toujours là, et l'opération de lecture de l'historique a également réussi. La tâche d'origine n'avait pas été archivée.

La cause probable est un décalage : l'écran considérait la conversation comme reprise, alors qu'en interne elle n'avait pas été chargée. Une fois l'envoi rétabli, vérifiez aussi que le travail effectué lors de ce tour est correct.

3. L'ordre à suivre quand seul l'envoi échoue

D'abord, copiez votre texte en local pour ne pas le perdre. Avant de cliquer à nouveau sur Envoyer, vérifiez si la même instruction n'a pas déjà été ajoutée à la conversation et si le traitement n'a pas commencé. Pour les instructions impliquant une publication, une suppression ou un achat, il est particulièrement important de ne pas empiler des requêtes dont la réponse a été retardée.

Par exemple, vous pouvez limiter ainsi le message de vérification. Comme il est envoyé comme une instruction ordinaire au modèle, il peut compter dans votre consommation habituelle.

Il s'agit d'une vérification de connexion. Ne reprenez pas le travail précédent.
Sans lire ni écrire de fichiers ni appeler d'outil,
répondez uniquement « Réponse reçue. ».

Le signalement adressé au dépôt GitHub d'OpenAI #30710 contient un cas où un échec d'envoi juste après l'ouverture d'une conversation sous Windows a été résolu par un redémarrage complet de l'application. La consigne officielle de dépannage « attendre la fin d'une tâche en cours avant de redémarrer » concerne le cas où le terminal intégré se bloque ; elle ne vise pas cette erreur d'envoi.

Si vous essayez une mise à jour, notez d'abord la version actuelle de l'application et les symptômes. Selon le guide de dépannage officiel, le Codex inclus dans l'application de bureau et la CLI installée séparément peuvent avoir des versions différentes. Mettre à jour la CLI ne signifie pas que le défaut côté application est corrigé.

4. Un même message peut avoir plusieurs causes et solutions

Ne vous fiez pas uniquement à la ligne « Error submitting message » ; regardez le texte qui suit et l'opération qui a échoué. Le tableau suivant répartit, par symptôme, les exemples issus de signalements publics et de notre environnement.

Pour les cas où l'historique reste disponible, le complément d'un utilisateur macOS dans #30710 est utile. L'écran considérait la conversation comme reprise, mais l'envoi a continué d'échouer ; plus tard, un rechargement dans le nouvel écran a réussi. Ce signalement décrit une incohérence d'état qu'une simple course au moment de l'ouverture ne suffit pas à expliquer, et son déroulement ressemble beaucoup à celui de notre cas.

En revanche, le signalement Windows #39179 décrit un historique lisible alors que l'envoi et l'archivage échouaient, et, dans l'environnement de l'auteur, la situation a persisté après un redémarrage. Un commentaire ajouté plus tard rapporte que, après un redémarrage complet de l'application, la poursuite est redevenue possible, mais que l'échec d'archivage n'a pas été réellement corrigé de façon fiable. #39575 contient un diagnostic sur l'horodatage des noms de fichiers enregistrés et sur le traitement des références. Il s'agit dans tous les cas d'enquêtes d'utilisateurs : ne concluez pas que vos propres données sont endommagées parce qu'un préfixe de chemin ou un décalage horaire apparaît.

Le type avec attente est illustré par le signalement de timeout d'envoi #27395, qui contient des journaux où turn/start a été interrompu au bout de 30 secondes (timeoutMs=30000) et a échoué avec Timeout. Dans un commentaire ajouté à #23644, une requête préalable à l'envoi a attendu environ 30 secondes dans la file (queueWaitMs=30001) avant d'échouer avec App server request expired while queued. Le type où l'arrêt échoue aussi se retrouve dans le signalement d'incohérence entre historique et état d'exécution #42604.

5. Si cela ne marche toujours pas : vérifications et passation

Si le problème persiste après un redémarrage, vérifiez si l'historique enregistré peut être lu. Si vous disposez d'une fonction permettant à une tâche Codex fonctionnelle de lire la tâche cible, commencez par une vérification en lecture seule. Il est aussi essentiel de ne pas confondre l'identifiant cible avec une tâche au nom similaire.

Examinez la tâche cible en lecture seule.
ID cible : l'identifiant de conversation affiché dans l'erreur

Indiquez si l'historique peut être lu, l'état du dernier tour et les erreurs.
N'envoyez aucun message à une autre tâche, ne reprenez pas le travail précédent, ne créez pas de fork, n'archivez rien,
ne modifiez ni les paramètres ni la base de données, et ne déplacez ni ne supprimez les fichiers d'historique.
Si aucune fonction de gestion des tâches n'est disponible, indiquez-le.

Cet exemple s'adresse aux environnements où des fonctions de gestion des tâches sont disponibles. Si vous ne trouvez pas une telle fonction, ne devinez pas de commandes internes au nom proche ; passez au rapport du chapitre 6.

Un commentaire ajouté à #39179 décrit un cas où un court message de vérification, envoyé depuis une autre tâche fonctionnelle, a permis de rétablir aussi la conversation habituelle une fois la réponse terminée. Toutefois, un autre commentaire signale un envoi similaire qui a échoué, ainsi qu'une nouvelle instruction acceptée après le fork d'un historique terminé. Face à ce contre-exemple, le signalant initial a précisé que ce n'est pas une solution générale.

Un fork est une opération qui transfère un historique terminé vers une tâche distincte ; la tâche d'origine n'est pas réparée. Ne partez pas du principe qu'un travail inachevé reprendra tel quel : après le transfert, vérifiez le répertoire de travail, les fichiers modifiés et la dernière étape terminée.

Les données d'historique et les fichiers de travail sont aussi distincts. Même si la conversation ne s'ouvre pas, les modifications du projet peuvent subsister. À l'inverse, même si la conversation est lisible, les fichiers ne sont pas forcément à jour. Si votre projet utilise Git, consultez la liste des modifications et identifiez ce qui a déjà été exécuté avant de poursuivre.

6. Informations à conserver pour demander une enquête

Dans un signalement, ne dites pas seulement « l'envoi ne fonctionne pas » : distinguez ce qui a réussi et ce qui a échoué. Indiquer la version de l'application, le système d'exploitation, l'heure et le fuseau horaire de l'incident, l'identifiant de la conversation concernée et l'opération effectuée juste avant facilite le suivi sans mêler des pannes différentes. Il n'est pas nécessaire de publier l'intégralité de la conversation dès le départ.

Si vous pouvez examiner les journaux, regardez les lignes situées avant et après la requête en échec. method=turn/start indique le début d'une instruction, thread/resume la reprise d'une conversation, et errorCode est un indice sur la réponse interne. Conservez aussi les lignes de succès, et distinguez une même erreur répétée sur plusieurs lignes d'un échec réellement survenu plusieurs fois.

Concernant l'emplacement des journaux de l'application, le guide de dépannage officiel indique pour macOS ~/Library/Logs/com.openai.codex/YYYY/MM/DD. Sous Windows, dans notre environnement, ils se trouvaient aux deux emplacements suivants.

• PC où l'erreur est apparue : %LOCALAPPDATA%\Codex\Logs
• Version Microsoft Store sur un autre PC (journaux de mars 2026) : %LOCALAPPDATA%\Packages\OpenAI.Codex_<ID>\LocalCache\Local\Codex\Logs (sur ce PC, le dossier %LOCALAPPDATA%\Codex lui-même n'existait pas)

Selon l'explication de Microsoft, les fichiers qu'une application empaquetée crée pour la première fois dans AppData sont écrits dans un emplacement propre à l'application, et peuvent apparaître à celle-ci comme s'ils se trouvaient à l'emplacement habituel. Si vous ne les trouvez pas à un endroit, cherchez aussi à l'autre. Le guide officiel indique que les sessions sont enregistrées dans $CODEX_HOME/sessions (valeur par défaut ~/.codex/sessions). Si vos réglages ou votre lieu d'exécution diffèrent, la cible n'est peut-être simplement pas dans le dossier que vous consultez ; ne concluez donc pas à une suppression parce que « la recherche ne la trouve pas ».

Le guide de dépannage officiel indique comment envoyer un retour en saisissant / dans le champ de saisie. Les journaux et captures d'écran peuvent contenir le texte des conversations, des adresses e-mail, les noms d'autres projets et des chemins locaux. Dans un ticket public, ne publiez que les parties nécessaires après les avoir anonymisées ; avant de transmettre des identifiants complets ou des informations similaires, vérifiez le destinataire et le niveau de visibilité.

7. Confirmer la reprise avec une réponse courte

La première réponse à cette erreur n'est pas de supprimer l'historique, mais de vérifier séparément si vous pouvez le lire, s'il est possible de reprendre la conversation et si une nouvelle instruction se termine. Dans ce cas, l'envoi a repris après le rechargement de la conversation. Si une erreur de stockage apparaît, c'est une autre voie : passez aux vérifications du chapitre 5.

Une fois qu'une réponse courte est terminée, vérifiez jusqu'où est allée l'instruction d'origine et reprenez à partir de l'étape nécessaire. Si le problème persiste, privilégiez une enquête en lecture seule et la conservation des journaux. Il est important de ne pas considérer la récupération comme achevée parce que le message d'erreur a disparu, ou parce qu'un fork a pu être créé.

Pour savoir où se trouvent les données de Codex (CODEX_HOME) et l'application elle-même après leur déplacement vers un autre lecteur, consultez notre article Déplacer ChatGPT et Codex vers un autre lecteur.

Articles connexes :

• Erreurs de capacité de Codex et épuisement du quota d'utilisation : différences et solutions (lorsque « Selected model is at capacity » apparaît)
• Conditions de connexion de Remote et vérifications après une déconnexion (lieu d'exécution et mise en veille du PC)
• Erreurs similaires dans Claude Code : Prompt is too long (taille de l'entrée) et MCP error -32000: Connection closed (connexion aux outils externes)

FAQ

Q. Si « thread not found » apparaît, la conversation a-t-elle disparu ?
R. Pas forcément. L'historique enregistré peut rester lisible alors que la conversation d'exécution nécessaire comme cible d'envoi n'est pas chargée. Inversement, la référence de stockage ou les fichiers eux-mêmes peuvent poser problème ; vérifiez donc s'ils sont réellement lisibles.

Q. notLoaded est-il une erreur ?
R. Cet état est en soi normal. Il indique qu'une conversation enregistrée n'est pas actuellement chargée pour l'exécution. Cela ne devient un problème que si elle n'est pas reprise lors de la poursuite et qu'une réponse courte ne se termine pas.

Q. Un redémarrage résout-il toujours le problème ?
R. Pas toujours. Certains signalements indiquent qu'un redémarrage complet a résolu le problème (#30710), d'autres que les échecs d'envoi et d'archivage ont persisté après le redémarrage (#39179). Dans notre exemple, l'envoi a repris après le rechargement de la conversation.

Q. La mise à jour vers la dernière version résout-elle le problème ?
R. Au 21 septembre 2026, nous n'avons trouvé aucune version corrigée qui indique explicitement avoir résolu l'ensemble de ce symptôme. Lors d'une mise à jour, notez les versions de l'application avant et après ainsi que les résultats. La CLI installée séparément et le Codex inclus dans l'application ne sont pas forcément de la même version.