Codex: cómo solucionar «thread not found» sin borrar el historial y casos de recuperación

1. ¿Qué no encuentra «thread not found»?

Al enviar una continuación a una tarea existente en el Codex de OpenAI, puede aparecer un error como este. El ID del final identifica la conversación de destino y aparece oculto a continuación.

Error al enviar el mensaje
thread not found: <ID de la conversación>

En las apps con la interfaz en inglés, la primera línea es Error submitting message (#30710).

Error submitting message
thread not found: <conversation ID>

Este artículo se centra en las tareas locales existentes de la app de escritorio. Se basa en los registros de un caso que observamos en nuestro entorno (Windows), en código fuente público y en informes de errores de usuarios, y refleja la situación al 21 de septiembre de 2026.

Mostrar el historial y aceptar nuevas instrucciones son mecanismos distintos. En una tarea que llevaba un tiempo sin usarse, el historial puede cargarse mientras la conversación no está cargada en el lado que recibe las instrucciones. Si envías tal cual, aparece este error.

2. Caso práctico: el envío se recuperó con el historial conservado

Es un ejemplo de nuestro entorno. Este error apareció al enviar una instrucción para continuar en una tarea de la app de Windows 26.915.31029. A continuación, los registros de la app del 21 de septiembre de 2026 se han convertido a UTC y se han organizado omitiendo los ID de las conversaciones y los detalles de las tareas.

La conversación guardada y el directorio de trabajo seguían ahí, y la operación de lectura del historial también tuvo éxito. La tarea original no se había archivado.

Lo más probable es una desincronización: la pantalla trataba la conversación como reanudada, pero internamente no se había cargado. Una vez recuperado el envío, comprueba también que el trabajo de ese turno sea correcto.

3. El orden de pruebas cuando solo falla el envío

Primero, guarda tu texto en un lugar local para no perderlo. Antes de volver a pulsar Enviar, mira si la misma instrucción ya se ha añadido a la conversación o si el procesamiento ya ha empezado. Sobre todo en instrucciones que incluyan publicar, eliminar o comprar, es importante no acumular solicitudes cuya respuesta se retrasó.

Por ejemplo, puedes acotar el mensaje de comprobación así. Como se envía como una instrucción normal al modelo, puede consumir uso como de costumbre.

Es una comprobación de conexión. No reanudes el trabajo anterior ni
leas o escribas archivos ni hagas llamadas a herramientas;
responde únicamente con «Pude responder».

El informe en el repositorio de GitHub de OpenAI #30710 incluye un caso en el que un fallo de envío justo después de abrir una conversación en Windows se resolvió con un reinicio completo de la app. El paso oficial de solución de problemas de «esperar a que termine la tarea en marcha antes de reiniciar» corresponde a los casos en que se bloquea la terminal integrada; no es una indicación para este error de envío.

Si decides actualizar, primero anota la versión actual de la app y los síntomas. Según la guía oficial de solución de problemas, el Codex incluido con la app de escritorio y la CLI instalada por separado pueden tener versiones distintas. Actualizar la CLI no significa que se haya corregido un fallo de la app.

4. El mismo mensaje puede tener causas y soluciones distintas

No decidas solo por la línea «Error al enviar el mensaje»; mira el texto que sigue y la operación que falló. La tabla siguiente separa, por síntoma, los ejemplos de informes públicos y de nuestro entorno.

En los casos en que el historial permanece, resulta útil el comentario posterior de un usuario de macOS en #30710. La pantalla trataba la conversación como reanudada, pero el envío seguía fallando; más tarde, la recarga en una pantalla nueva tuvo éxito. Es un informe de desajuste de estado que no se explica con una «carrera solo en el momento de abrir», y su desarrollo se parece mucho al de este caso.

Por otro lado, el informe de Windows #39179 describe un caso en el que el historial se podía leer, pero el envío y el archivado fallaban, y en el entorno del autor eso continuó tras reiniciar. Un comentario posterior indica también que, tras reiniciar la app por completo, pudo continuar, pero el fallo del archivado no se corrigió de forma fiable. #39575 contiene diagnósticos sobre la hora en los nombres de los archivos guardados y el proceso de referencia. Todos son investigaciones de usuarios, así que no concluyas que tus datos están dañados solo porque haya un prefijo de ruta o una diferencia horaria.

El tipo que se queda esperando aparece en el informe de timeout de envío #27395, que incluye registros en los que turn/start se cortó a los 30 segundos (timeoutMs=30000) y falló como Timeout. En un comentario de #23644, una solicitud de la que depende el envío estuvo unos 30 segundos en cola (queueWaitMs=30001) antes de fallar con App server request expired while queued. El tipo en el que también falla la detención puede verse en el informe #42604 sobre el desajuste entre historial y estado de ejecución.

5. Cuando sigue sin funcionar: comprobaciones y traspaso

Si sigue sin funcionar tras reiniciar, comprueba si puedes leer el historial guardado. Si tienes una función que permite que una tarea de Codex que funciona lea la tarea de destino, empieza por una comprobación de solo lectura. También es importante no confundir el ID de destino con una tarea de nombre parecido.

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

Indica si puedes leer el historial, el estado del último turno y los errores.
No envíes mensajes a otras tareas, no reanudes trabajos anteriores, no crees
un fork, no archives, no cambies la configuración, no edites la base de datos
ni muevas o borres archivos de historial.
Si no hay ninguna función de gestión de tareas disponible, indícalo.

Este ejemplo de redacción es para entornos donde hay funciones de gestión de tareas. Si no encuentras esa función, no adivines ni ejecutes comandos internos de nombre parecido; pasa al informe del capítulo 6.

En un comentario sobre #39179 se describe un caso en el que se envió un mensaje de comprobación breve desde otra tarea que funcionaba bien y, tras completarse la respuesta, también se recuperó la conversación normal. Sin embargo, otro comentario informa de un envío similar que falla, y de una nueva instrucción aceptada al crear un fork de un historial completado. Ante este contraejemplo, el propio informante original aclaró que no es una solución general.

Un fork es una operación que traspasa un historial completado a otra tarea; la tarea original no se arregla. No des por hecho que un trabajo sin terminar continuará tal cual. Tras el traspaso, revisa el directorio de trabajo, los archivos modificados y el último paso terminado.

Los datos del historial y los archivos de trabajo también son cosas distintas. Aunque no se pueda abrir una conversación, pueden seguir existiendo las ediciones del proyecto. Y al revés: aunque puedas leer la conversación, los archivos no tienen por qué estar actualizados. Si tu proyecto usa Git, revisa la lista de cambios y ordena qué se ha ejecutado ya antes de continuar.

6. Información que conviene guardar al pedir una investigación

Al informar, separa no solo «no se puede enviar», sino también qué salió bien y qué falló. Indicar la versión de la app, el sistema operativo, la hora y la zona horaria, el ID de la conversación de destino y la operación previa facilita el seguimiento sin mezclar fallos de otra naturaleza. No hace falta publicar la conversación completa desde el principio.

Si puedes revisar los registros, ayuda mirar las líneas anteriores y posteriores a la solicitud fallida. method=turn/start indica el inicio de una instrucción, thread/resume la reanudación de una conversación, y errorCode es una pista de la respuesta interna. Conserva también las líneas correctas y distingue si el mismo fallo aparece solo en varias líneas de registro o si realmente falló varias veces.

En cuanto a la ubicación de los registros de la app, la guía oficial de solución de problemas indica para macOS ~/Library/Logs/com.openai.codex/YYYY/MM/DD. En Windows, en nuestro entorno estaban en estos dos lugares.

• PC donde apareció el error: %LOCALAPPDATA%\Codex\Logs
• Versión de Microsoft Store en otro PC (registros de marzo de 2026): %LOCALAPPDATA%\Packages\OpenAI.Codex_<ID>\LocalCache\Local\Codex\Logs (en este PC no existía la propia carpeta %LOCALAPPDATA%\Codex)

Según la explicación de Microsoft, los archivos que una app empaquetada crea nuevos en AppData se escriben en una ubicación privada de la app, y pueden parecerle a esa app que están en la ubicación normal. Si no los encuentras en uno de los dos sitios, busca también en el otro. La guía oficial indica que las sesiones se guardan en $CODEX_HOME/sessions (valor predeterminado ~/.codex/sessions). Si tu configuración o el lugar de ejecución son distintos, puede que el elemento simplemente no esté en la carpeta que miras; no des por eliminado algo solo porque «la búsqueda no lo muestra».

Si quieres saber qué hay en cada sitio al mover los datos de Codex (CODEX_HOME) o la propia app a otra unidad, hemos recogido lo que comprobamos en Cómo mover ChatGPT y Codex a otra unidad.

La guía oficial de solución de problemas explica cómo enviar comentarios escribiendo / en el campo de entrada. Los registros y las capturas pueden contener el texto de conversaciones, direcciones de correo, nombres de otros proyectos y rutas locales. En una incidencia pública, incluye solo las partes necesarias y anonimizadas; y si compartes IDs completos u otros datos similares, comprueba quién los recibe y quién puede verlos.

7. Confirmar la recuperación con una respuesta breve

La primera respuesta a este error no es borrar el historial, sino comprobar por separado si puedes leerlo, si puedes reanudarlo y si una nueva instrucción se completa. En este caso, el envío se recuperó tras recargar la conversación. Si aparece un error de almacenamiento, se trata de otra ruta, así que pasa a las comprobaciones del capítulo 5.

Cuando se complete una respuesta breve, revisa hasta dónde llegó la instrucción original y reanuda desde el paso necesario. Si sigue sin arreglarse, prioriza la investigación de solo lectura y la conservación de los registros. Es importante no dar la recuperación por completada solo porque el mensaje de error desapareció o porque se pudo crear un fork.

Artículos relacionados:

• Errores de capacidad de Codex frente a límite de uso agotado, y cómo solucionarlos (cuando aparece «Selected model is at capacity»)
• Condiciones de conexión de Remote y pasos de comprobación tras una desconexión (lugar de ejecución y suspensión del PC)
• Errores similares en Claude Code: Prompt is too long (tamaño de la entrada) y MCP error -32000: Connection closed (conexión con herramientas externas)

FAQ

P. Si aparece «thread not found», ¿se ha perdido la conversación?
R. No necesariamente. El historial guardado puede seguir pudiéndose leer mientras la conversación que se necesita como destino de envío para la ejecución no esté cargada. Por otro lado, también puede haber un problema con la referencia de almacenamiento o con los propios archivos, así que comprueba si realmente puedes leerlos.

P. ¿notLoaded es un error?
R. Ese estado en sí es normal. Indica que una conversación guardada no está cargada para ejecutarse en este momento. Solo se convierte en un problema cuando, al continuar, no se reanuda y ni siquiera una respuesta breve llega a completarse.

P. ¿Reiniciar siempre lo soluciona?
R. No siempre. Hay informes en los que un reinicio completo lo solucionó (#30710), y otros en los que el envío y el archivado seguían fallando tras reiniciar (#39179). En nuestro ejemplo, el envío se recuperó después de recargar la conversación.

P. ¿Actualizar a la última versión lo resuelve?
R. Al 21 de septiembre de 2026, no encontramos ninguna versión corregida que indique explícitamente haber resuelto este síntoma en su conjunto. Al actualizar, anota las versiones de la app antes y después, y los resultados. La CLI instalada aparte y el Codex incluido en la app no tienen por qué ser la misma versión.