Codex: cómo abordar «thread not found» sin borrar el historial

El error «thread not found» de Codex no significa necesariamente que hayas perdido el historial. Primero, comprueba si solo falla el envío o si tampoco puedes abrir la conversación.

1. ¿Qué falta cuando Codex muestra thread not found?

Codex de OpenAI puede mostrar un error como el siguiente al enviar una nueva instrucción a una tarea existente. El ID identifica la conversación y aquí se ha ocultado. La primera línea traduce el mensaje en japonés observado en nuestro caso.

Se ha producido un error al enviar el mensaje
thread not found: <ID de la conversación>

Este artículo trata sobre las tareas locales existentes en la aplicación de escritorio. El 21 de septiembre de 2026 contrastamos los registros de envíos fallidos de nuestro ordenador con el código fuente público y los informes de usuarios. Nos centramos en nuestro caso de Windows; no es un método de reparación cuya eficacia se haya demostrado en todos los entornos.

La especificación oficial de App Server explica que thread/read lee el historial guardado sin cargar la conversación en la memoria de ejecución. Su función es distinta de la de thread/resume, que reanuda una conversación para seguir trabajando. Son métodos de comunicación interna, no comandos que debas escribir en el chat.

También contrastamos la versión de la CLI 0.155.0-alpha.9, registrada en los metadatos guardados de nuestro ordenador, con el correspondiente código fuente público del envío. El punto de entrada de turn/start obtiene la conversación y devuelve thread not found si no la encuentra. La busca en la lista de conversaciones en memoria, por lo que este error por sí solo no demuestra que hayan desaparecido los archivos guardados.

notLoaded no es, en sí mismo, un estado de error. Significa que una conversación guardada no está cargada en ese momento para ejecutarse. El problema aparece cuando no se realiza la reanudación necesaria y la conversación no puede aceptar la siguiente instrucción. El texto por sí solo no permite distinguir entre una descarga normal de memoria, un problema al localizar los datos guardados, un ID de conversación incorrecto u otras causas.

2. Caso real: el envío se recuperó sin borrar el historial

En el entorno de trabajo de AI Arte, este error apareció al enviar una instrucción para continuar otra tarea en la versión de Windows de la aplicación 26.915.31029. La siguiente cronología resume los registros de la aplicación del 21 de septiembre de 2026. Todas las horas corresponden a la hora estándar de Japón (JST); se han omitido los ID de conversación, los detalles del trabajo y los datos personales.

La conversación guardada y el directorio de trabajo existían, y el historial se pudo leer. La tarea original no estaba archivada. Inspeccionamos los registros y el estado guardado en modo de solo lectura, sin modificar la base de datos de conversaciones ni la configuración.

Una discrepancia entre el estado «reanudado» de la interfaz y el estado interno es una explicación sólida. Sin embargo, no reprodujimos el problema para identificar exactamente cómo surgió esa discrepancia. Comprobar el estado de los últimos turnos tampoco equivale a verificar la corrección del trabajo realizado en ellos. Nuestras comprobaciones de recuperación solo abarcan el envío y el estado de la conversación.

3. Qué probar cuando solo falla el envío

Primero, guarda una copia de lo que has escrito para no perderlo. Antes de pulsar enviar repetidamente, comprueba si la misma instrucción ya aparece en la conversación o si ha comenzado a procesarse. Evita duplicar una solicitud cuya respuesta simplemente se esté retrasando, sobre todo si implica publicar, borrar o comprar algo.

Por ejemplo, limita el alcance de la comprobación como se indica a continuación. Es una instrucción para el modelo, no un comando que repare la aplicación. Enviarla y recibir una respuesta del modelo puede contar como uso normal.

Esto es una comprobación de conexión. No reanudes trabajos anteriores,
no leas ni escribas archivos y no utilices herramientas.
Responde únicamente «Respuesta recibida».

El informe #30710 del repositorio de OpenAI en GitHub describe un caso de Windows en el que reiniciar mejoró los fallos de envío que se producían justo después de abrir una conversación. La guía oficial de resolución de problemas recomienda esperar a que terminen las tareas activas y reiniciar cuando el terminal integrado se bloquea. Esa indicación no es un procedimiento de recuperación específico para este error de envío. Ninguna de las dos fuentes garantiza que reiniciar resuelva todos los errores thread not found.

Si pruebas una actualización, anota primero la versión actual de la aplicación y los síntomas. La versión de Codex incluida en la aplicación puede diferir de una CLI instalada por separado. Actualizar solo la CLI no demuestra que el problema de la aplicación de escritorio esté resuelto. No hemos identificado una versión que elimine definitivamente este síntoma.

4. Mensajes parecidos, causas y soluciones distintas

No te quedes en el encabezado que indica que el envío ha fallado: lee el resto del error e identifica la operación que falló. La siguiente tabla agrupa informes públicos y nuestras observaciones; no clasifica los problemas por frecuencia.

Como ejemplo de un historial que seguía disponible, consulta el comentario de seguimiento del usuario de macOS en #30710. La interfaz consideraba reanudada la conversación, pero el envío fallaba repetidamente; una nueva instancia de la interfaz la recargó después correctamente. Esto describe una discrepancia de estado que no se explica solo por una condición de carrera justo después de abrir la tarea. Se parece a nuestro caso, pero no se ha demostrado que la causa sea idéntica.

En cambio, el informe de Windows #39179 describe fallos tanto de envío como de archivado que persistieron tras reiniciar. #39575 también incluye un diagnóstico relacionado con las marcas de tiempo en los nombres de los archivos guardados y el proceso de búsqueda. No obstante, son investigaciones de usuarios. Un prefijo de ruta o una diferencia de zona horaria no demuestran por sí solos que tus datos estén dañados.

Para los fallos que aparecen tras una espera, consulta el informe de tiempo de espera de envío agotado en #27395; para los que también afectan a la detención, consulta el informe sobre discrepancias entre el historial y el estado de ejecución en #42604. La existencia de mensajes parecidos no demuestra que el problema sea frecuente entre todos los usuarios. Nuestra investigación no encontró una tasa de incidencia calculada sobre un total de usuarios o de intentos de envío.

5. Comprobaciones y opciones para continuar si el problema persiste

Si reiniciar no ayuda, comprueba si puedes leer el historial guardado. Si tu entorno permite inspeccionar la tarea afectada desde otra tarea de Codex que funcione, empieza con una comprobación de solo lectura. Asegúrate de que el ID de destino es correcto; no elijas simplemente una tarea con un nombre parecido.

Investiga la tarea indicada en modo de solo lectura.
ID de destino: pega aquí el ID de conversación que aparece en el error

Indica si puedes leer su historial, el estado del último turno y los errores.
No envíes mensajes a otra tarea, no reanudes trabajos anteriores, no crees
bifurcaciones ni archives tareas. No cambies la configuración, no edites la
base de datos y no muevas ni borres archivos del historial.
Si no hay herramientas de gestión de tareas, indica esa limitación.

Es un ejemplo de solicitud para un entorno con herramientas de gestión de tareas. Esas herramientas no están disponibles en todas las interfaces ni CLI. Si no encuentras la función, no necesitas adivinar ni ejecutar comandos internos con nombres parecidos.

Un comentario de seguimiento en #39179 describe una comprobación breve enviada desde otra tarea que funcionaba; tras completarse su respuesta, también se recuperó la conversación normal. Sin embargo, otro comentario de seguimiento indica que ese mismo tipo de envío falló, mientras que una bifurcación del historial de los turnos completados aceptó una instrucción nueva. Ante este contraejemplo, el autor del primer informe aclaró que no era una solución general.

Crear una bifurcación es una opción para trasladar el historial de los turnos completados a otra tarea, no una reparación de la tarea original. No presupongas que el trabajo inconcluso se reproducirá tal como estaba. Tras el traspaso, comprueba el directorio de trabajo, los archivos modificados y el último paso completado. Que un informe público indique que se aceptó una instrucción nueva tampoco garantiza que el trabajo posterior terminara correctamente.

El historial de conversación y los archivos de trabajo también son independientes. Los cambios del proyecto pueden seguir presentes aunque la conversación no se abra. A la inversa, un historial legible no garantiza que los archivos estén actualizados. En un proyecto Git, revisa los cambios y determina qué se ha ejecutado antes de continuar.

6. Qué registrar al solicitar ayuda

Distingue lo que funcionó de lo que falló, en lugar de limitarte a decir «no puedo enviar». La versión de la aplicación, el sistema operativo, la hora y la zona horaria, el ID de conversación y la acción anterior ayudan a diferenciar los tipos de fallo. No hace falta publicar toda la conversación desde el principio.

Si puedes inspeccionar los registros, examina las entradas próximas a la solicitud fallida. method=turn/start marca el inicio de una instrucción, thread/resume reanuda una conversación y errorCode aporta una pista sobre la respuesta interna. Conserva también las entradas correctas y distingue un único fallo reflejado en varias líneas del registro de varias solicitudes realmente fallidas.

En nuestro ordenador Windows, los registros de la aplicación estaban en %LOCALAPPDATA%\Codex\Logs. Es la ubicación que verificamos en este equipo, no una garantía para todas las distribuciones. La documentación oficial sitúa las sesiones en $CODEX_HOME/sessions, cuya ubicación predeterminada es ~/.codex/sessions. Otra configuración o un destino de ejecución distinto pueden significar simplemente que los datos relevantes no están en la carpeta que estás mirando. No encontrarlos en una búsqueda no demuestra que se hayan borrado.

La guía oficial de resolución de problemas explica cómo enviar comentarios escribiendo / en el cuadro de entrada. Los registros y las capturas pueden contener texto de conversaciones, correos electrónicos, nombres de otros proyectos y rutas locales. Incluye en una incidencia pública solo las partes necesarias y anonimizadas. Antes de compartir ID completos o detalles similares, comprueba quién recibirá el informe y quién podrá verlo.

7. Confirma la recuperación con una respuesta breve

En lugar de empezar borrando el historial, comprueba tres cosas por separado: ¿puedes leerlo, puedes reanudarlo y puede completarse una instrucción nueva? En nuestro caso, el envío funcionó después de recargar, pero eso no demuestra que el mismo método resuelva errores de almacenamiento ajenos a este caso.

Cuando se complete una respuesta breve, comprueba hasta dónde llegó la instrucción original y retoma el trabajo desde el paso adecuado. Si el problema persiste, prioriza la investigación de solo lectura y la conservación de los registros. Que desaparezca el error o se cree una bifurcación no basta para dar la recuperación por terminada.

Claude Code también puede mostrar Prompt is too long, relacionado con la capacidad de entrada, o MCP error -32000: Connection closed, que requiere comprobar la conexión con herramientas externas. Son errores diferentes de otro producto. Aunque el síntoma parezca «no puedo dar instrucciones a la IA», decide qué hacer a partir del nombre del producto y del mensaje de error completo. No reutilices sin más sus comandos de diagnóstico en una conversación de Codex.

Preguntas frecuentes

Q. ¿thread not found significa que se ha borrado la conversación?
A. No necesariamente. El historial guardado puede seguir siendo legible aunque la conversación necesaria para recibir un mensaje no esté cargada para ejecutarse. También puede haber problemas con las referencias a los datos guardados o con los propios archivos, así que comprueba si realmente puedes leer el historial.

Q. ¿notLoaded es un error?
A. El nombre del estado no demuestra por sí solo que haya un error. Puede describir una situación normal en la que una conversación guardada no está cargada para ejecutarse. Comprueba si se reanuda al continuar y si llega a completarse una respuesta breve.

Q. ¿Reiniciar siempre lo soluciona?
A. No. Algunos informes describen mejoras, mientras que otros mencionan errores de almacenamiento o archivado que persistieron tras reiniciar. En nuestro ordenador observamos que el envío funcionó después de recargar la conversación; no hicimos un experimento para probar el reinicio.

Q. ¿Actualizar a la última versión lo resolverá?
A. En el momento de la revisión no habíamos verificado una versión concreta que resolviera todo este conjunto de síntomas. Registra la versión de la aplicación y los resultados antes y después de actualizar. Una CLI instalada por separado y la versión de Codex incluida en la aplicación no tienen por qué coincidir.