Procesos de Codex en segundo plano en Windows: cómo decidir sin perder trabajo

Si has cerrado Codex pero el árbol de procesos sigue ahí, la aplicación vuelve sin una ventana útil o la CPU y el disco mantienen actividad sin una tarea visible, no empieces contando procesos ni buscando un nombre para finalizar. Primero averigua si una tarea activa, un terminal, una ejecución Scheduled o una sesión de Computer Use es la propietaria del trabajo. Cuando hay propietario, la salida correcta empieza en esa superficie.

Si no encuentras propietario, guarda prompts, parches y salidas de terminal; sal de Codex de forma normal y observa cómo cambia la actividad. Solo después de comprobar la ventana, la relación entre procesos padre e hijo y el uso de recursos puedes clasificar el árbol como residual. «Finalizar árbol de procesos» queda reservado para tres límites: un residuo inactivo que no se puede retirar normalmente, actividad sostenida sin dueño o un árbol que impide volver a abrir Codex de forma utilizable.

Relanza Codex una sola vez. Si el estado reaparece, deja de repetir cierres forzados y prepara un informe reproducible con versión de la aplicación y de Windows, entorno nativo o WSL2, propietario observado, patrón antes/después y pasos mínimos. Redacta prompts, transcripciones, tokens, nombres de repositorios, usuarios y rutas completas antes de compartirlo.

Decide primero: dejar en ejecución o inspeccionar

Codex puede necesitar varios procesos para una sola tarea: un shell, un comando de terminal, Git, un entorno de ejecución de lenguaje, una herramienta de navegador o una rama de WSL. Esa variedad hace que la pregunta «¿cuántos procesos son normales?» no tenga una respuesta universal publicada. El número cambia con la tarea, las herramientas, el proyecto, la versión de la aplicación y el entorno del agente.

La decisión útil tiene tres ejes:

• Propietario: qué tarea, terminal, ejecución Scheduled o sesión de Computer Use inició o sigue necesitando el trabajo.
• Actividad: si el árbol está avanzando, escribiendo, esperando una aprobación, cerrándose o consumiendo recursos sin una causa identificable.
• Ciclo de vida: qué ocurre después de detener al propietario y salir de Codex de forma normal.

La tabla conecta esos ejes con una acción inmediata. Léela de izquierda a derecha y no saltes directamente a la columna de cierre.

Esta tabla no es un inventario de ejecutables. Los nombres son ayudas para observar y pueden cambiar o pertenecer a otras aplicaciones. Tampoco convierte una cifra aislada de CPU, memoria o procesos tomada de una incidencia en un umbral para otros equipos.

Seis síntomas que no significan lo mismo

Dos capturas del Administrador de tareas pueden parecer iguales y corresponder a situaciones opuestas. Un árbol con actividad puede estar haciendo exactamente lo pedido; un árbol casi inactivo puede ser el residuo que bloquea el siguiente arranque. Clasificar el síntoma evita cerrar por intuición.

1. Una tarea o un terminal siguen trabajando

Si Codex genera código, ejecuta pruebas, espera tu aprobación o transmite salida, los procesos auxiliares tienen propietario. Finalizar el árbol puede perder un parche en curso, interrumpir un comando o dejar una operación externa a medias.

Vuelve a la tarea o al terminal. Decide si debe terminar por sí solo o si quieres cancelarlo. Después comprueba que alcanza un estado terminal claro: completado, cancelado, fallido o detenido. El hecho de que la ventana principal no esté en primer plano no elimina esa propiedad.

2. Una ejecución Scheduled es la propietaria

La documentación oficial de Scheduled indica que las ejecuciones sobre proyectos locales se realizan en segundo plano y requieren que el ordenador permanezca encendido y la aplicación de escritorio siga ejecutándose. Por tanto, un árbol sin una tarea visible en primer plano puede ser intencional.

Revisa el nombre de la programación, su última y próxima ejecución, el modo de ejecución y si trabaja con un checkout local o un worktree. Si ya no la necesitas, detén o desactiva Scheduled desde Codex. Matar el proceso no modifica la programación que puede volver a iniciarlo.

3. El árbol persiste después de salir

Cerrar una ventana y completar el ciclo de salida de una aplicación no siempre son el mismo evento. Puede quedar actividad breve mientras se cierran terminales, se completan escrituras o termina una limpieza. Una sola actualización del Administrador de tareas no demuestra una fuga.

El síntoma se vuelve relevante cuando has salido de forma deliberada, no queda trabajo con propietario y el árbol persiste, mantiene actividad o interfiere con un arranque limpio. Observa la evolución; no conviertas «todavía está ahí» en «está bloqueado» sin comparar antes y después.

4. Codex aparece, pero no hay una ventana utilizable

Pulsar repetidamente el icono empeora la lectura: puedes crear más intentos y perder la referencia de qué árbol empezó primero. Comprueba si ya existe una rama de Codex y anota su hora de inicio. Guarda lo que aún sea accesible, completa una única recuperación limpia y abre la aplicación una vez.

Si la ventana no aparece, no encadenes relanzamientos. Registra la secuencia exacta, la versión y si el árbol anterior cambió. Esa observación separa un residuo que bloquea el arranque de un problema distinto de interfaz.

5. CPU o disco mantienen actividad sin propietario

«En reposo» no significa simplemente que no estás mirando la tarea. Significa que has verificado que no hay ninguna tarea, comando de terminal, ejecución Scheduled ni sesión de Computer Use que deba trabajar. Observa más de una actualización y compara CPU, disco y memoria antes y después de detener al propietario.

Un pico corto puede pertenecer a Git, indexación, cierre de terminales o escrituras. La señal que exige atención es la actividad sostenida ligada al árbol de Codex cuando ya no existe un propietario identificable. No hay un porcentaje ni una duración fija que sustituya esa relación.

6. Quedan hijos de shell que parecen huérfanos

PowerShell, pwsh, conhost.exe, Node, Git, Python y WSL son herramientas compartidas. Pueden depender de Codex, pero también de tu IDE, otro terminal, un servidor de desarrollo o una automatización separada. Su nombre no acredita propiedad.

Rastrea el PID padre y la hora de creación. Si la rama nace del trabajo de Codex y ya no tiene propietario, podrás evaluarla como parte del árbol residual. Si pertenece a otro proyecto, déjala intacta. Una regla que mate todos los procesos Node o PowerShell es especialmente peligrosa en un equipo de desarrollo.

Recupera con una secuencia que preserve el trabajo

La secuencia importa más que la herramienta. Cada paso elimina una causa legítima antes de pasar al siguiente. Detente en cuanto el problema quede resuelto.

1. Conserva el trabajo. Copia un prompt aún no enviado, guarda la salida relevante y confirma que parches o archivos importantes están en disco. Si una tarea todavía produce cambios, decide si la dejas terminar o la cancelas desde Codex.
2. Detén al propietario. Cancela la tarea, detén el comando que iniciaste, desactiva la ejecución Scheduled o finaliza la sesión de Computer Use desde su propia superficie.
3. Sal de forma normal. Usa la opción de salida de Codex mientras la interfaz responda. No empieces por el cierre forzado.
4. Deja que la actividad se estabilice. Da margen a hijos de terminal y operaciones de archivo. No existe un tiempo mágico válido para todos los proyectos.
5. Verifica el cambio. Comprueba ventana, tamaño y forma del árbol, relación padre-hijo y evolución de CPU o disco.
6. Finaliza solo un árbol residual cualificado. Hazlo únicamente si ya no queda trabajo con propietario y se cumple al menos uno de los tres límites explicados abajo.
7. Relanza una vez. Debe volver una ventana utilizable y un estado coherente, sin un segundo árbol que crezca.
8. Informa si reaparece. Conserva evidencia antes de reinstalar, borrar estado o cambiar varias opciones.

Los tres límites del paso 6 son deliberadamente estrechos:

1. El árbol está inactivo, pero permanece como residuo y no se retira mediante la salida normal.
2. El árbol mantiene actividad sin una tarea, terminal, Scheduled o Computer Use que la posea.
3. El árbol impide volver a abrir Codex de forma utilizable.

El límite de parada también es claro: después del paso 7 no se repite un bucle de «forzar cierre y abrir». Si reaparece, el objetivo cambia de recuperar a documentar una reproducción.

En el Administrador de tareas, identifica primero el grupo superior que realmente pertenece a Codex. Usa Finalizar tarea solo en el paso 6. Si la interfaz no puede retirar un árbol residual ya verificado, un administrador puede usar la opción de árbol de Windows:

powershell
taskkill /PID <pid-superior-verificado-de-codex> /T /F

/T incluye hijos y /F fuerza la terminación. Precisamente por eso el comando puede recuperar un residuo y destruir trabajo en curso. No adivines el PID, no apuntes a un shell compartido por nombre y no lo ejecutes antes de guardar y rastrear la rama.

Observa primero en el Administrador de tareas

El Administrador de tareas —Task Manager en algunas interfaces o documentación— es la forma más rápida de responder tres preguntas: si el grupo sigue cambiando, qué hijo muestra actividad y si esa actividad cae cuando se detiene al propietario.

Empieza por la vista Procesos para observar CPU, memoria y disco. Pasa a Detalles cuando necesites PID y hora de inicio. El Monitor de recursos puede aportar contexto sobre actividad de disco, pero una ruta de archivo completa puede ser sensible y no debe copiarse sin revisar.

Haz una observación anterior y otra posterior:

1. Anota qué trabajo aparece activo en Codex.
2. Observa qué ramas cambian mientras ese trabajo avanza.
3. Detén la tarea desde su superficie.
4. Comprueba qué actividad disminuye y qué rama permanece.
5. Solo entonces decide si lo restante pertenece a Codex y está fuera de su ciclo de vida esperado.

No uses una única cifra de memoria como sentencia. Algunos entornos de ejecución conservan memoria, y un proceso puede estar ocioso sin liberarla de inmediato. Tampoco conviertas un PID de una incidencia pública en algo reproducible: los PID cambian en cada ejecución.

Inspecciona con PowerShell sin exponer de más

PowerShell ayuda a guardar una fotografía estructurada, pero conviene empezar sin la línea de comandos. Esta versión recoge nombre, PID, padre y fecha de creación:

powershell
Get-CimInstance Win32_Process |
  Where-Object { $_.Name -match 'codex|powershell|pwsh|conhost|node|git|python|wsl' } |
  Sort-Object ParentProcessId, ProcessId |
  Select-Object Name, ProcessId, ParentProcessId, CreationDate

El filtro solo reduce el volumen para observar. No define qué es un proceso de Codex: puede incluir herramientas ajenas y omitir auxiliares con otro nombre. Reconstruye la propiedad con el PID padre, la hora de inicio y la tarea que estaba activa.

Para una fotografía ligera de recursos:

powershell
Get-Process |
  Where-Object { $_.ProcessName -match 'codex|powershell|pwsh|conhost|node|git|python|wsl' } |
  Sort-Object CPU -Descending |
  Select-Object ProcessName, Id,
    @{Name='CPUSeconds'; Expression={[math]::Round($_.CPU, 1)}},
    @{Name='MemoryMB'; Expression={[math]::Round($_.WorkingSet64 / 1MB, 1)}}

CPUSeconds es tiempo de CPU acumulado desde que se inició el proceso, no porcentaje instantáneo. Puede subir aunque la lectura actual sea baja. Ejecuta la fotografía en dos momentos y compárala con las columnas en directo de CPU y disco del Administrador de tareas.

Si un proceso rechaza el acceso, registra esa limitación. No eleves privilegios solo para obtener una tabla más completa. Y no añadas CommandLine a un informe público por defecto: puede revelar prompts, nombres de ramas, repositorios, ficheros, tokens, variables y rutas locales.

Separa Windows nativo, WSL2 y el terminal integrado

La documentación de Codex para Windows diferencia el agente nativo, que usa PowerShell y el sandbox de Windows, del agente que se ejecuta en WSL2. La elección del shell del terminal integrado es independiente. Cambiar el entorno del agente a WSL requiere reiniciar la aplicación.

Elegir PowerShell, Git Bash o un shell WSL para un terminal no traslada automáticamente el agente. Del mismo modo, ver un proceso WSL no demuestra un fallo: puede ser coherente con el entorno seleccionado o con una herramienta invocada por el proyecto.

No cambies Windows/WSL como primer intento de recuperación. Ese cambio altera el experimento y puede ocultar la causa original. Captura primero el estado que falla; después, si sigue siendo reproducible, modifica una sola variable y compara.

Si el árbol ya está sano pero la aplicación de escritorio sigue siendo lenta frente a CLI o a otra superficie, sigue la guía separada de Codex App frente a CLI en español. Esa página se ocupa de comparar superficies; esta se limita al ciclo de vida de los procesos.

Trata Scheduled y Computer Use como posibles propietarios

Scheduled y Computer Use no son nombres alternativos para un proceso residual. Son superficies que pueden poseer trabajo legítimo y, por eso, deben comprobarse antes de cerrar el árbol.

En Scheduled, confirma si la ejecución corresponde a un proyecto local y si está en curso, en cola o próxima. Recuerda que Scheduled de Codex no es el Programador de tareas de Windows. Si una programación ya no debe ejecutarse, actúa sobre la programación; cerrar procesos solo elimina una instancia y no su causa.

Una sesión de Computer Use puede mantener activas aplicaciones o tareas de navegador de forma intencional. Si existe una sesión, finalízala desde su superficie y verifica que su actividad asociada se detiene. El modelo de permisos y supervisión de Computer Use es un tema distinto.

Cuando tu pregunta sea cómo iniciar, controlar o supervisar trabajo con interfaz gráfica, consulta la guía española de Codex Computer Use. En este diagnóstico solo importa como posible propietario del árbol, no como culpable automático.

Prepara un informe reproducible y redactado

Un informe útil relaciona entorno, propietario, actividad, ciclo de vida y resultado de recuperación. Una queja como «había muchos procesos» no permite distinguir una ejecución legítima de un defecto recurrente.

La guía oficial de feedback y logs orienta los informes de Codex hacia incidencias existentes de GitHub o una nueva incidencia y recuerda revisar logs y transcripciones antes de compartirlos. La ubicación documentada de las transcripciones es $CODEX_HOME/sessions. No hay una ruta universal publicada para logs de la aplicación de Windows, así que no inventes una ni presentes una ruta local observada como regla general.

Recoge este paquete antes de borrar o reinstalar:

• versión de la aplicación Codex y hora local de la captura;
• versión y arquitectura de Windows;
• entorno del agente: Windows nativo con PowerShell o WSL2;
• shell del terminal integrado, si es relevante;
• tipo de proyecto y si la ejecución usaba checkout local o worktree;
• estado visible de Tasks, Scheduled, terminal y Computer Use;
• síntoma exacto: residuo tras salir, arranque sin ventana o actividad sostenida sin propietario;
• relación padre-hijo y horas de inicio;
• evolución de CPU, disco y memoria antes y después de la salida normal;
• pasos mínimos de reproducción y resultado del único relanzamiento.

Puedes usar esta plantilla:

text
Versión de Codex:
Versión de Windows:
Entorno del agente: Windows nativo / WSL2
Terminal integrado:
Tipo de proyecto y tipo de ruta: [redactado si hace falta]
Trabajo con propietario: Task / Scheduled / Terminal / Computer Use / Ninguno
Síntoma:
Pasos mínimos:
Resultado esperado:
Resultado observado:
CPU, disco y memoria antes/después:
¿La salida normal retiró el árbol?
¿Un único relanzamiento recuperó la aplicación?

Antes de publicar, elimina prompts, contenido de transcripciones, tokens, claves, datos de clientes, nombres de repositorios privados, nombres de usuario, rutas completas y argumentos sensibles. Comparte relaciones y patrones abstractos, no un volcado íntegro del directorio de sesiones.

Evita atajos que destruyen evidencia

Los atajos agresivos pueden hacer desaparecer el síntoma sin aclarar su causa y, a la vez, perder trabajo o información útil:

• No fijes una cantidad normal. La forma del árbol depende del trabajo, las herramientas, el entorno y la versión.
• No mates por nombre. Node, PowerShell, Git, Python, consola y WSL pueden pertenecer a otros proyectos.
• No borres cachés, transcripciones ni el estado de .codex como primer paso. Puedes perder evidencia y configuración.
• No reinstales antes de capturar una reproducción. Cambiarás el entorno que intentabas diagnosticar.
• No cambies entorno Windows/WSL, terminal, permisos y ubicación del proyecto a la vez. Modifica una variable después de guardar una línea base.
• No repitas ciclos de cierre forzado y relanzamiento. Una recuperación limpia y un relanzamiento bastan para saber si reaparece.
• No uses background_terminal_max_timeout como ajuste del árbol. Controla el sondeo de salida de terminal, no el número de procesos ni el ciclo de vida de la aplicación.

La referencia de configuración de Codex describe background_terminal_max_timeout como la ventana máxima de sondeo para la salida de terminal en segundo plano. Subir o bajar ese valor no convierte un residuo de escritorio en un estado sano.

Preguntas frecuentes

¿Cuántos procesos de Codex son normales en Windows?

No hay una cantidad universal publicada. El árbol cambia con tareas, terminales, Git, entornos de ejecución, herramientas de navegador, Computer Use, Scheduled, la versión de la aplicación y el entorno nativo o WSL2. Decide por propietario, actividad y ciclo de vida.

¿Es seguro finalizar Codex desde el Administrador de tareas?

Solo después de guardar, detener al propietario, intentar la salida normal y verificar el residuo. Está justificado cuando no queda trabajo con propietario y el árbol está inactivo pero no se retira, mantiene actividad sin dueño o bloquea un relanzamiento utilizable.

¿Por qué sigue Codex en segundo plano después de cerrar la ventana?

Una tarea, un terminal, una ejecución Scheduled o Computer Use pueden seguir trabajando; también puede estar terminando escrituras o limpieza. Si ninguno es propietario y el árbol persiste tras una salida normal deliberada, trátalo como síntoma residual y aplica la secuencia segura.

¿Qué hago si Codex aparece en Task Manager, pero no abre una ventana?

No pulses el icono repetidamente. Comprueba el árbol existente y su hora de inicio, conserva lo accesible, completa una sola recuperación y relanza una vez. Si vuelve a fallar, registra versiones, propiedad, actividad y secuencia exacta.

¿Una CPU o un disco altos demuestran que Codex está bloqueado?

No. Una actividad breve puede pertenecer a una tarea, Git, indexación, un comando, Scheduled o limpieza. Se vuelve accionable cuando es sostenida, no queda propietario y la comparación antes/después la vincula al árbol residual.

¿Scheduled significa Programador de tareas de Windows?

No. Aquí Scheduled es la función de ejecuciones programadas de Codex. Puede mantener trabajo local en segundo plano mientras el ordenador está encendido y la aplicación de escritorio sigue ejecutándose. Se gestiona desde su superficie en Codex.

¿Elegir WSL en el terminal integrado cambia el entorno del agente?

No necesariamente. El terminal integrado y el entorno del agente son selecciones distintas. La aplicación distingue agente nativo de Windows y agente WSL2; cambiar el entorno del agente a WSL requiere reiniciar la aplicación.

¿background_terminal_max_timeout controla cuántos procesos hay?

No. Define cuánto puede sondearse la salida de un terminal en segundo plano. No establece una cantidad de procesos y no es una reparación inicial para un árbol residual de la aplicación.

¿Debo finalizar todos los PowerShell, Node, Git, Python o WSL que cuelgan de Codex?

No. Confirma primero la relación padre-hijo y el propietario. Finaliza, si se cumplen los límites, la rama superior residual verificada; deja intactos los procesos de otros terminales, IDE o proyectos.

¿Qué debo adjuntar si el problema reaparece?

Versiones, entorno, propietario observado, relación padre-hijo, patrón de recursos antes/después, pasos mínimos y resultado de una única recuperación. Redacta comandos, rutas, prompts, transcripciones, credenciales y datos identificables antes de compartir.

Regla práctica para no perder trabajo

Deja los procesos de Codex en ejecución cuando una tarea, un terminal, Scheduled o Computer Use los posea. Cuando no quede trabajo, actúa en este orden: conserva, detén al propietario, sal normalmente, deja que la actividad se estabilice, verifica, finaliza únicamente el árbol residual cualificado, relanza una vez e informa si reaparece.

La lista de procesos es una observación, no el diagnóstico. El diagnóstico aparece al conectar quién inició el trabajo, qué actividad mantiene y cómo cambia el árbol después de una salida correcta. Esa disciplina resuelve el incidente inmediato sin destruir el trabajo ni la evidencia que haría posible corregir una recurrencia.