Codex « thread not found » : agir sans effacer l'historique

L'erreur « thread not found » de Codex ne signifie pas nécessairement que votre historique a disparu. Vérifiez d'abord si seul l'envoi échoue ou si vous ne pouvez pas non plus ouvrir la conversation.

1. Que manque-t-il quand Codex affiche thread not found ?

Codex d'OpenAI peut afficher une erreur comme celle-ci lorsque vous envoyez une nouvelle instruction à une tâche existante. L'ID identifie la conversation ; il est masqué ici. La première ligne ci-dessous traduit le message japonais observé dans notre cas.

Une erreur s'est produite lors de l'envoi du message
thread not found: <ID de la conversation>

Cet article porte sur les tâches locales existantes dans l'application de bureau. Le 21 septembre 2026, nous avons confronté les journaux d'envois échoués de notre ordinateur au code source public et aux témoignages d'utilisateurs. Nous nous concentrons sur notre cas sous Windows, sans présenter une méthode de réparation dont l'efficacité serait démontrée dans tous les environnements.

La spécification officielle d'App Server explique que thread/read lit l'historique enregistré sans charger la conversation dans la mémoire d'exécution. Son rôle diffère de celui de thread/resume, qui reprend une conversation pour poursuivre le travail. Ce sont des méthodes de communication interne, pas des commandes à saisir dans le chat.

Nous avons également comparé la version de la CLI 0.155.0-alpha.9, consignée dans les métadonnées enregistrées sur notre ordinateur, au code source public correspondant à l'envoi. Le point d'entrée de turn/start recherche la conversation et renvoie thread not found si cette recherche échoue. Il consulte la liste des conversations en mémoire : cette erreur ne démontre donc pas, à elle seule, que les fichiers enregistrés ont disparu.

notLoaded n'est pas un état d'erreur en soi. Il signifie qu'une conversation enregistrée n'est pas actuellement chargée pour l'exécution. Le problème survient lorsque la reprise nécessaire n'a pas lieu et que la conversation ne peut pas accepter l'instruction suivante. Le libellé seul ne permet pas de distinguer un déchargement normal de la mémoire, un problème de localisation des données enregistrées, un ID de conversation incorrect ou d'autres causes.

2. Cas réel : l'envoi rétabli sans effacer l'historique

Dans l'environnement de travail d'AI Arte, cette erreur est apparue lorsque nous avons envoyé une instruction de continuation à une autre tâche dans la version Windows de l'application 26.915.31029. La chronologie suivante résume les journaux de l'application du 21 septembre 2026. Toutes les heures sont indiquées à l'heure normale du Japon (JST) ; les ID de conversation, le détail des travaux et les informations personnelles sont omis.

La conversation enregistrée et le répertoire de travail existaient, et la lecture de l'historique a réussi. La tâche originale n'était pas archivée. Nous avons inspecté les journaux et l'état enregistré en lecture seule, sans modifier la base de données des conversations ni les paramètres.

Un décalage entre l'état « repris » de l'interface et l'état interne est une explication solide. Nous n'avons toutefois pas reproduit le problème pour déterminer précisément comment ce décalage s'est produit. Vérifier l'état des derniers tours ne revient pas non plus à vérifier l'exactitude du travail réalisé pendant ceux-ci. Nos vérifications de rétablissement concernent uniquement l'envoi et l'état de la conversation.

3. Que faire si seul l'envoi échoue ?

Conservez d'abord une copie de votre saisie pour ne pas la perdre. Avant d'appuyer plusieurs fois sur Envoyer, vérifiez si la même instruction apparaît déjà dans la conversation ou si son traitement a commencé. Évitez de dupliquer une demande dont la réponse est simplement retardée, surtout si elle implique une publication, une suppression ou un achat.

Par exemple, limitez la portée de la vérification comme ci-dessous. Il s'agit d'une instruction au modèle, pas d'une commande réparant l'application. Son envoi et la réponse du modèle peuvent être comptabilisés dans l'utilisation normale.

Ceci est une vérification de connexion. Ne reprends aucun travail précédent,
ne lis ni n'écris de fichiers et n'appelle aucun outil.
Réponds uniquement « Réponse reçue ».

Le signalement #30710 dans le dépôt GitHub d'OpenAI décrit un cas sous Windows où un redémarrage a amélioré les échecs d'envoi survenant juste après l'ouverture d'une conversation. Le guide officiel de dépannage recommande d'attendre la fin des tâches actives et de redémarrer lorsque le terminal intégré est bloqué. Cette indication n'est pas une procédure de rétablissement propre à cette erreur d'envoi. Aucune de ces sources ne garantit qu'un redémarrage résout toutes les erreurs thread not found.

Si vous essayez une mise à jour, notez d'abord la version actuelle de l'application et les symptômes. La version de Codex incluse dans l'application peut différer d'une CLI installée séparément. Mettre à jour uniquement la CLI ne prouve pas que le problème de l'application de bureau est corrigé. Nous n'avons pas identifié de version qui résolve définitivement ce symptôme.

4. Messages similaires, causes et solutions différentes

Ne vous arrêtez pas au titre annonçant un échec d'envoi : lisez le reste de l'erreur et identifiez l'opération concernée. Le tableau ci-dessous regroupe des témoignages publics et nos observations ; il ne classe pas les problèmes selon leur fréquence.

Pour un cas où l'historique restait disponible, consultez le commentaire de suivi d'un utilisateur de macOS dans #30710. L'interface considérait la conversation comme reprise, mais l'envoi échouait à répétition ; une nouvelle instance de l'interface l'a ensuite rechargée correctement. Il s'agit d'un décalage d'état qu'une condition de concurrence juste après l'ouverture ne suffit pas à expliquer. Ce cas ressemble au nôtre, sans qu'une cause identique ait été démontrée.

À l'inverse, le signalement Windows #39179 décrit des échecs d'envoi et d'archivage qui persistaient après un redémarrage. #39575 contient également un diagnostic portant sur les horodatages dans les noms des fichiers enregistrés et sur leur recherche. Il s'agit cependant d'enquêtes menées par des utilisateurs. Un préfixe de chemin ou une différence de fuseau horaire ne prouve pas, à lui seul, que vos données sont endommagées.

Pour les échecs après une attente, consultez le signalement de délai d'envoi dépassé dans #27395 ; pour ceux qui touchent aussi l'arrêt, consultez le signalement de décalage entre historique et état d'exécution dans #42604. Des messages similaires ne prouvent pas que le problème soit fréquent parmi l'ensemble des utilisateurs. Notre enquête n'a trouvé aucun taux d'incidence rapporté à un nombre total d'utilisateurs ou de tentatives d'envoi.

5. Vérifications et options pour continuer si le problème persiste

Si le redémarrage n'aide pas, vérifiez si l'historique enregistré est lisible. Si votre environnement permet d'inspecter la tâche touchée depuis une autre tâche Codex fonctionnelle, commencez par une vérification en lecture seule. Assurez-vous que l'ID cible est correct plutôt que de sélectionner simplement une tâche au nom similaire.

Examine la tâche cible en lecture seule.
ID cible : colle ici l'ID de conversation affiché dans l'erreur

Indique si son historique est lisible, l'état du dernier tour et les erreurs.
N'envoie aucun message à une autre tâche, ne reprends aucun travail précédent,
ne crée aucune branche et n'archive rien. Ne modifie ni les paramètres ni la
base de données, et ne déplace ni ne supprime les fichiers d'historique.
Si les outils de gestion des tâches sont absents, signale cette limite.

Cette demande est un exemple destiné à un environnement disposant d'outils de gestion des tâches. Ceux-ci ne sont pas disponibles dans toutes les interfaces ou CLI. Si vous ne trouvez pas cette fonction, inutile de deviner et d'exécuter des commandes internes aux noms similaires.

Un commentaire de suivi dans #39179 décrit une brève vérification envoyée depuis une autre tâche fonctionnelle ; une fois sa réponse terminée, la conversation normale a également repris. Toutefois, un autre commentaire de suivi indique que le même type d'envoi a échoué, alors qu'une branche issue de l'historique des échanges terminés a accepté une nouvelle instruction. Face à ce contre-exemple, l'auteur du premier signalement a précisé qu'il ne s'agissait pas d'une solution générale.

Créer une branche est une option pour transférer l'historique des échanges terminés vers une autre tâche, pas une réparation de la tâche originale. Ne supposez pas que le travail inachevé sera reproduit tel quel. Après le transfert, vérifiez le répertoire de travail, les fichiers modifiés et la dernière étape achevée. Un témoignage public indiquant qu'une nouvelle instruction a été acceptée ne garantit pas non plus que le travail suivant se soit terminé correctement.

L'historique de conversation et les fichiers de travail sont eux aussi distincts. Les modifications du projet peuvent subsister même si la conversation ne s'ouvre pas. À l'inverse, un historique lisible ne garantit pas que les fichiers soient à jour. Dans un projet Git, examinez les modifications et déterminez ce qui a déjà été exécuté avant de poursuivre.

6. Informations à conserver pour demander de l'aide

Distinguez ce qui a réussi de ce qui a échoué, au lieu de signaler seulement « je ne peux pas envoyer ». La version de l'application, le système d'exploitation, l'heure et le fuseau horaire, l'ID de conversation et l'action précédente aident à différencier les pannes. Il n'est pas nécessaire de publier toute la conversation d'emblée.

Si vous pouvez consulter les journaux, examinez les entrées proches de la requête échouée. method=turn/start marque le début d'une instruction, thread/resume reprend une conversation et errorCode donne un indice sur la réponse interne. Conservez aussi les entrées réussies et distinguez une seule panne consignée sur plusieurs lignes de plusieurs requêtes ayant réellement échoué.

Sur notre ordinateur Windows, les journaux de l'application se trouvaient dans %LOCALAPPDATA%\Codex\Logs. C'est l'emplacement vérifié sur cette machine, pas une garantie pour toutes les distributions. La documentation officielle situe les sessions dans $CODEX_HOME/sessions, avec comme valeur par défaut ~/.codex/sessions. Une configuration ou une cible d'exécution différente peut simplement signifier que les données utiles ne sont pas dans le dossier consulté. Ne pas les trouver lors d'une recherche ne démontre pas qu'elles ont été supprimées.

Le guide officiel de dépannage explique comment envoyer un commentaire en saisissant / dans le champ de message. Les journaux et captures d'écran peuvent contenir du texte de conversation, des adresses e-mail, des noms d'autres projets et des chemins locaux. Dans un signalement public, n'incluez que les parties nécessaires, anonymisées. Avant de partager des ID complets ou des détails similaires, vérifiez le destinataire et les personnes qui pourront consulter l'envoi.

7. Confirmer le rétablissement avec une réponse courte

Au lieu de commencer par effacer l'historique, vérifiez séparément trois points : pouvez-vous le lire, le reprendre et terminer une nouvelle instruction ? L'envoi a réussi après le rechargement dans notre cas, mais cela ne prouve pas que la même méthode résolve des erreurs de stockage sans rapport.

Une fois une réponse courte terminée, vérifiez jusqu'où l'instruction originale est allée et reprenez à l'étape appropriée. Si le problème persiste, privilégiez une enquête en lecture seule et la conservation des journaux. La disparition du message d'erreur ou la création d'une branche ne suffit pas à déclarer le rétablissement complet.

Claude Code peut également afficher Prompt is too long, qui concerne la capacité d'entrée, ou MCP error -32000: Connection closed, qui demande de vérifier la connexion aux outils externes. Ce sont des erreurs différentes dans un autre produit. Même si le symptôme ressemble à « je ne peux pas donner d'instructions à l'IA », choisissez votre démarche selon le produit et le message d'erreur complet. Ne réutilisez pas simplement leurs commandes de dépannage dans une conversation Codex.

Questions fréquentes

Q. thread not found signifie-t-il que la conversation a été supprimée ?
A. Pas nécessairement. L'historique enregistré peut rester lisible même si la conversation nécessaire pour recevoir un message n'est pas chargée pour l'exécution. Des problèmes peuvent aussi toucher les références aux données enregistrées ou les fichiers eux-mêmes ; vérifiez donc si l'historique est réellement lisible.

Q. notLoaded est-il une erreur ?
A. Le nom de l'état ne suffit pas à établir une erreur. Il peut décrire une situation normale où une conversation enregistrée n'est pas actuellement chargée pour l'exécution. Vérifiez qu'elle reprend quand vous continuez et qu'une réponse courte se termine.

Q. Un redémarrage résout-il toujours le problème ?
A. Non. Certains témoignages décrivent une amélioration, tandis que d'autres signalent des erreurs de stockage ou d'archivage persistant après un redémarrage. Sur notre ordinateur, nous avons observé un envoi réussi après le rechargement de la conversation ; nous n'avons pas mené d'expérience pour tester le redémarrage.

Q. Une mise à jour vers la dernière version résoudra-t-elle le problème ?
A. Au moment de notre revue, nous n'avions pas vérifié de version précise résolvant l'ensemble de ces symptômes. Notez la version de l'application et les résultats avant et après la mise à jour. Une CLI installée séparément et la version de Codex incluse dans l'application ne sont pas nécessairement identiques.