Codex CLI añade voz. Importa más recuperar el trabajo

Codex CLI 0.155.0 añadió conversaciones de voz experimentales el 17 de septiembre de 2026, pero yo daría prioridad a los cambios que conservan el trabajo: guardar un prompt si falla la compactación del contexto y recuperar tareas tras reiniciar el servicio gestionado. La corrección 0.155.1, publicada al día siguiente, también importa si tu proveedor rechaza los resúmenes de razonamiento. Son cambios documentados del cliente, no un nuevo modelo. [1]

¿Qué permite hacer la voz en Codex CLI?

El modo de voz permite conversar en directo dentro de la interfaz del terminal, con transcripción y controles de audio. La implementación incluye /voice, /voice mute y /voice stop. Puede leer las respuestas finales del trabajo delegado durante la conversación, sin leer sus comentarios intermedios. Las respuestas a mensajes escritos tampoco se leen automáticamente. [2]

Una recopilación publicada en r/CodexAutomation el 18 de septiembre destacó la voz. Es comprensible: es la novedad más visible. Esa publicación sirve para descubrir la versión, pero no constituye una prueba independiente de cómo funciona la voz. [7]

Yo la probaría para explicar un problema o comentar un cambio propuesto mientras miro el código. Para rutas exactas y criterios de aceptación, seguiría prefiriendo una instrucción escrita que pueda revisar. Las notas presentan la voz como experimental y limitada a versiones compatibles; no prometen que aparezca en todas las instalaciones. [1]

Esto cambia cómo hablas con el agente. Es una cuestión distinta de la capacidad y el coste que analicé en mi comparación de GPT-6 Astra.

¿Qué ocurre cuando se interrumpe una tarea larga?

Dos correcciones abordan distintas formas de perder la continuidad de una sesión. La primera afecta a la compactación, el paso que reduce el contexto antes de continuar. Antes, un fallo previo al siguiente turno podía dejar fuera del historial un prompt ya aceptado. Ahora se registra la entrada antes de comunicar el error. [4]

La distinción ayuda a investigar una sesión fallida. Un error todavía puede detener el turno, pero la instrucción debería seguir disponible en el historial. La prueba de regresión descrita en el cambio comprueba que el prompt se guarda una sola vez y que después del fallo no se envía otra petición al modelo. No afirma que la compactación ya no pueda fallar. [4]

La segunda corrección recupera tareas guardadas cuando se reinicia el daemon gestionado, es decir, el servicio en segundo plano. La recuperación se ejecuta en segundo plano y los objetivos activos pueden continuar antes de que se reconecte un cliente. Si una tarea no se recupera, el proceso continúa con las demás. [5]

Interpreto estos cambios como mejoras de continuidad. Complementan la conservación del contexto útil del repositorio, que resuelve otro problema: conservar una instrucción no garantiza que el modelo tenga los datos correctos del proyecto. Los cambios del daemon afectan al servicio local de Codex, no a la Agents API alojada.

La limpieza de worktrees identifica la tarea propietaria

El explorador de worktrees relaciona ahora cada copia gestionada con su tarea propietaria. Muestra su título, cuándo se actualizó y si está archivada o no disponible. Un worktree es una copia de trabajo independiente del repositorio; esa relación ayuda a entender por qué existe un directorio antes de eliminarlo. [3]

La eliminación exige confirmación, selecciona Cancelar por defecto y conserva el historial de la conversación. Solo permite borrar worktrees gestionados del repositorio actual. Rechaza la copia de trabajo actual y cualquier copia que contenga cambios locales, archivos sin seguimiento o archivos ignorados. [3]

Conviene entender qué implica incluir los archivos ignorados. Un directorio puede contener archivos generados que Git normalmente omite de la lista de cambios, pero esta comprobación sí los tiene en cuenta. Prefiero ese comportamiento conservador al limpiar después de tareas paralelas. Aporta información antes de borrar archivos, independientemente de qué agente resuelve mejor una función grande.

¿Por qué cambió 0.155.1 los resúmenes de razonamiento?

La versión 0.155.0 hacía que las nuevas sesiones locales del terminal solicitaran resúmenes detallados por defecto. Algunos proveedores no los admiten y rechazaban la petición. La corrección del 18 de septiembre recupera none como valor predeterminado, respetando los ajustes explícitos auto, concise y detailed. [6]

Es una corrección de compatibilidad, no un anuncio de que el modelo razone menos. Cambia el resumen solicitado del razonamiento. Si leíste el anuncio de 0.155.0 y esperabas ver resúmenes en directo automáticamente tras actualizar, esta corrección explica la diferencia. [6]

También hay que poner en perspectiva los primeros informes. Un usuario de r/codex señaló que 0.155.0 no podía iniciar el sandbox de Windows y que volver a 0.154.0 resolvió su problema. Es la experiencia de una persona, no un fallo confirmado en todas las instalaciones de Windows. [8] La corrección documentada de 0.155.1 afecta a los resúmenes; no daría por hecho que resuelve esa otra queja.

En un flujo de trabajo de terminal ya establecido, comprobaría la conservación de prompts y la recuperación de tareas antes de dedicar mucho tiempo a la voz. Tener otra forma de dar instrucciones resulta útil; poder encontrar esas instrucciones tras una interrupción es lo que permite continuar.