Codex llena el disco y desgasta el SSD: limpieza segura paso a paso

Abres la laptop una mañana y el disco está casi lleno. No descargaste nada pesado, no exportaste ningún video. Pero en algún momento de las últimas semanas, mientras dejabas que el CLI de Codex de OpenAI hiciera un refactor tras otro, una carpeta discreta dentro de tu carpeta personal creció hasta el tamaño de una videoteca. Lo hemos visto en nuestras propias máquinas, y la primera reacción siempre es la misma: ¿a dónde se fue todo ese espacio y le está haciendo daño a mi SSD? Es un problema de mantenimiento con una solución tranquila y repetible.

Qué es este problema

OpenAI Codex —el agente de programación que corre en tu terminal— guarda un almacén local de trazas y logs dentro de su carpeta de inicio, ~/.codex/. Ese almacén incluye una base de datos SQLite y un archivo de write-ahead-log (algo como logs_*.sqlite-wal). Con uso intenso, esos archivos pueden crecer muchísimo y escribir gran cantidad de datos al disco con el tiempo. En corto: Codex registra su propia actividad sin parar, y ese log no se encoge solo. Así que el espacio "perdido" no es un virus ni un misterio: es un agente haciendo su trabajo con demasiado entusiasmo y sin limpiar después.

Un detalle lo vuelve más complicado que un log normal. Según reportes en el rastreador de issues público de openai/codex en GitHub (abiertos a junio de 2026 — revisa el rastreador para ver el estado actual, ya que Codex se actualiza seguido), la traza detallada se escribe sin importar la variable de entorno RUST_LOG. Es decir, bajar el nivel de logging de la forma habitual no detiene las escrituras. Por eso la gente se sorprende: cree que desactivó el log y el disco sigue llenándose.

A quién le importa

• Ideal para: quienes usan el CLI de Codex a diario en laptops con SSD chicos (256–512 GB), donde una carpeta de logs descontrolada sí amenaza el espacio libre; y para quien corre sesiones largas e intensas.
• También útil para: equipos pequeños que estandarizan una configuración, gente cuyo backup en la nube vuelve a subir la misma carpeta que no para de crecer, y para quien quiere una máquina ordenada.
• No es problema para: usuarios ocasionales con discos grandes y sesiones ligeras; ni para quien no usa el CLI de Codex. Si estás en Claude Code o Cursor, este almacén de logs específico no aplica (más abajo lo explicamos), aunque ninguna herramienta está libre de mantenimiento en general.

Qué necesitas

La solución de un vistazo

Paso a paso

1. Mide primero. Corre la revisión de tamaño (comandos abajo) para confirmar que ~/.codex/ es de verdad lo que te come el espacio. No borres a ciegas.
2. Cierra Codex por completo. Sal del CLI y de la app de escritorio si la usas. Borrar un archivo SQLite/WAL activo con el proceso corriendo puede corromper el estado.
3. Confirma la ruta exacta. Lista la carpeta y busca la base de datos SQLite y el archivo *.sqlite-wal. Asegúrate de estar viendo ~/.codex/ y no otra cosa.
4. Borra solo los archivos de log específicos. Apunta a los archivos log/SQLite/WAL por nombre. Nunca corras un borrado recursivo amplio sobre una ruta que recuerdas a medias.
5. Vuelve a medir. Corre la revisión otra vez para confirmar que bajó el espacio. Ojo: un usuario reportó que borrar el almacén no siempre recuperaba el espacio de inmediato; si te pasa, reiniciar o darle un momento al sistema de archivos suele ayudar.
6. Automatiza la limpieza. Programa el recorte para no hacerlo a mano cada semana.
7. Excluye del backup/sync. Agrega las rutas de logs a las listas de exclusión de tu backup y tu sync en la nube para que no se copien una y otra vez.

Comandos para copiar y pegar

Estos son los comandos reales de diagnóstico y limpieza. Lee cada uno antes de correrlo. Lo que está marcado como ilustrativo es un patrón para adaptar, no una ruta exacta garantizada: confirma los nombres de archivo en tu propia máquina, porque Codex cambia entre versiones.

1) La revisión de tamaño de 30 segundos.

# macOS / Linux
du -sh ~/.codex

# Windows PowerShell
Get-ChildItem "$env:USERPROFILE\.codex" -Recurse -File | Measure-Object Length -Sum

2) Mira qué hay dentro, del más grande al más chico (para saber exactamente qué archivos quitar):

# macOS / Linux
ls -lhS ~/.codex
du -ah ~/.codex | sort -rh | head -n 15

# Windows PowerShell
Get-ChildItem "$env:USERPROFILE\.codex" -Recurse -File |
  Sort-Object Length -Descending |
  Select-Object -First 15 FullName, @{Name='MB';Expression={[math]::Round($_.Length/1MB,1)}}

3) Limpieza segura: cierra Codex primero y borra solo los archivos log/SQLite/WAL. Esto apunta a archivos específicos por patrón; no borra la carpeta entera (ahí también viven tu configuración y tu sesión). Patrones ilustrativos; confirma los nombres reales del paso 2 antes de borrar:

# macOS / Linux  —  Codex debe estar cerrado
# Mira, luego borra por patrón específico. Nada de rm -rf amplio sobre una ruta adivinada.
ls -lh ~/.codex/logs_*.sqlite* 2>/dev/null
rm -i ~/.codex/logs_*.sqlite-wal
rm -i ~/.codex/logs_*.sqlite-shm
# Borra el log principal solo si confirmaste que es el almacén de trazas, no la config:
rm -i ~/.codex/logs_*.sqlite

# Windows PowerShell  —  Codex debe estar cerrado
Get-ChildItem "$env:USERPROFILE\.codex" -Filter "logs_*.sqlite*" |
  ForEach-Object { Write-Host $_.FullName }
Remove-Item "$env:USERPROFILE\.codex\logs_*.sqlite-wal" -Confirm
Remove-Item "$env:USERPROFILE\.codex\logs_*.sqlite-shm" -Confirm
# ¿Confirmaste que es el almacén de trazas y no la config? Entonces:
Remove-Item "$env:USERPROFILE\.codex\logs_*.sqlite" -Confirm

Las banderas -i (macOS/Linux) y -Confirm (PowerShell) hacen que cada borrado pregunte antes. Déjalas. Son un seguro barato contra equivocarte de ruta.

4) Una limpieza programada. Recorta los archivos WAL/log con cierta cadencia para que la carpeta no vuelva a inflarse. Ilustrativo: adapta la ruta y el horario:

# macOS / Linux  —  entrada de cron (corre `crontab -e`)
# Semanal, domingo 3am: quita archivos WAL/shm de Codex cuando Codex no esté corriendo.
0 3 * * 0  find "$HOME/.codex" -maxdepth 1 -name 'logs_*.sqlite-wal' -delete; find "$HOME/.codex" -maxdepth 1 -name 'logs_*.sqlite-shm' -delete

# Windows  —  registra una tarea semanal de limpieza en el Programador de tareas
$action  = New-ScheduledTaskAction -Execute "powershell.exe" `
  -Argument '-NoProfile -Command "Remove-Item \"$env:USERPROFILE\.codex\logs_*.sqlite-wal\",\"$env:USERPROFILE\.codex\logs_*.sqlite-shm\" -ErrorAction SilentlyContinue"'
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At 3am
Register-ScheduledTask -TaskName "Prune Codex logs" -Action $action -Trigger $trigger

5) Excluye las rutas de logs del backup / sync en la nube para que no se vuelvan a copiar sin fin:

# macOS Time Machine — excluye la carpeta de Codex
sudo tmutil addexclusion ~/.codex

# Linux (ejemplo con restic) — pasa una exclusión al hacer backup
restic backup ~ --exclude="$HOME/.codex/logs_*.sqlite*"

# Windows — si usas sync selectivo de OneDrive/Dropbox, desmarca ~/.codex en los ajustes de la app (interfaz gráfica).

Opcional: mueve la carpeta de logs a un lugar menos valioso. En macOS/Linux puedes mantener los archivos de trazas en un tmpfs en RAM o en un disco secundario, para que tu SSD principal no reciba las escrituras sostenidas. Esto es más laborioso y depende de la versión; revisa la documentación oficial de Codex para ver la forma soportada de reubicar su directorio de datos antes de hacer un symlink a mano.

Ejemplo: lo que vas a ver

Un momento típico de "uy" se ve así: la revisión de tamaño devuelve algo mucho más grande de lo que esperarías de una carpeta de logs:

$ du -sh ~/.codex
214G    /Users/tu/.codex

$ ls -lhS ~/.codex
-rw-r--r--  1 tu  staff   180G  Jun 21 09:14  logs_trace.sqlite-wal
-rw-r--r--  1 tu  staff    33G  Jun 21 09:14  logs_trace.sqlite
-rw-r--r--  1 tu  staff    16M  Jun 21 09:14  logs_trace.sqlite-shm

Ese archivo WAL haciendo casi todo el daño es la firma clásica. Para dimensionar: un usuario en el rastreador de GitHub reportó que el almacén llegó a cientos de GB, y otro estimó escrituras acumuladas del orden de cientos de terabytes por año. Ese número de TB/año es la estimación de un usuario en un issue de GitHub, no una cifra oficial de OpenAI, así que tómalo como una señal aproximada, no como un dato medido.

Ejemplo: después de la solución

Tras cerrar Codex y quitar los archivos WAL/SQLite específicos, la misma revisión vuelve a verse sana:

$ du -sh ~/.codex
1.1G    /Users/tu/.codex

Una advertencia honesta: un usuario reportó que borrar el almacén no siempre recuperaba el espacio de inmediato; a veces el número se queda rezagado hasta que el proceso libera del todo el archivo o reinicias. Si tu lectura de espacio libre no se mueve enseguida, dale un minuto o reinicia y vuelve a revisar. Un reporte aparte vinculó un almacén demasiado grande con que la app de escritorio no arrancara; si tu app de Codex no abre, vale la pena descartar primero un ~/.codex/ inflado.

Tested Notes

• Tipo de entrada: una laptop con un solo SSD interno donde ~/.codex/ creció a cientos de GB tras semanas de sesiones intensas con el agente.
• Herramienta usada: CLI de OpenAI Codex.
• Mejor resultado: cerrar Codex y borrar solo los archivos logs_*.sqlite-wal / -shm (y luego el .sqlite de trazas, ya confirmado) recuperó la mayor parte del espacio de forma segura, dejando intactas la config y la sesión.
• Qué falló: bajar RUST_LOG no detuvo las escrituras (comportamiento reportado), así que "solo baja el logging" no es una solución. Borrar no siempre recuperó el espacio al instante.
• Ediciones manuales aún necesarias: confirmar los nombres exactos de archivo en tu máquina, decidir si reubicas la carpeta de logs y ajustar el horario y las exclusiones de backup a tu setup.

Tropiezos que de verdad hemos tenido

La primera trampa es borrar con Codex todavía corriendo. SQLite usa ese archivo WAL como estado en vivo; si lo quitas a media escritura, puedes corromper el almacén. Cierra siempre el CLI (y la app de escritorio) primero. La segunda es borrar de más: tu configuración y tu sesión también viven dentro de ~/.codex/, así que un borrado total te desconecta y reinicia tus ajustes. Apunta a los archivos log/WAL en concreto. La tercera es suponer que RUST_LOG te salva; en el comportamiento reportado no toca estas escrituras, así que no te confíes. Y la cuarta es la ilusión del espacio que no aparece: si el espacio libre no salta de inmediato, coincide con lo que reportó un usuario; espera o reinicia antes de dar por hecho que el borrado falló.

Errores comunes

1. Correr rm -rf ~/.codex para "limpiarlo de una vez". Eso elimina también la config y la sesión, y un borrado recursivo amplio sobre una ruta adivinada es justo lo que un operador cuidadoso nunca hace.
2. Borrar con Codex abierto. Arriesgas corromper el almacén SQLite. Ciérralo primero, siempre.
3. Confiar en que RUST_LOG detiene las escrituras. El comportamiento reportado dice que no, así que la carpeta sigue creciendo.
4. Dejar que el backup/sync vuelva a subir la carpeta. La borras localmente, pero tu backup guarda una copia gigante y la vuelve a sincronizar: espacio y ancho de banda desperdiciados.
5. Tomar la cifra de TB/año como oficial. Es la estimación de un usuario en un issue de GitHub. Sirve como un "gestiona esto", no como un dato medido.

Alternativas de herramientas

FAQ

¿El logging intenso de Codex va a desgastar mi SSD?

Probablemente no rápido. Los SSD tienen una resistencia de escritura finita, medida como TBW (terabytes escritos), y las escrituras de fondo sostenidas sí consumen ese presupuesto además de tu espacio libre. Pero los SSD de consumo modernos traen TBW altos, así que esto es algo que conviene gestionar, no para entrar en pánico. A junio de 2026, lo sensato es limpiar seguido y considerar reubicar la carpeta de logs si usas Codex con fuerza: trátalo como mantenimiento de rutina, no como una emergencia.

¿Es seguro borrar toda la carpeta ~/.codex sin más?

No lo recomendamos. Esa carpeta también guarda tu configuración y tu sesión, así que borrarla te desconecta y reinicia ajustes, y un borrado recursivo amplio sobre una ruta adivinada es riesgoso por principio. Cierra Codex, confirma los nombres exactos y borra solo los logs_*.sqlite-wal, -shm y (ya confirmado) el .sqlite de trazas. Deja una bandera de confirmación como -i o -Confirm para que cada borrado pregunte antes.

¿Por qué bajar RUST_LOG no detiene que el disco se llene?

Según reportes en el rastreador de openai/codex en GitHub (abiertos a junio de 2026), la traza detallada se escribe sin importar la variable RUST_LOG, así que bajar el logging de la forma habitual no detiene estas escrituras específicas. Esa es la sorpresa que pesca a la gente. Como es comportamiento reportado en una herramienta que cambia rápido, revisa el rastreador y la documentación oficial para el estado actual antes de asumir que sigue igual en tu versión.

Borré los archivos pero mi espacio libre no cambió, ¿falló?

No necesariamente. Un usuario reportó que borrar el almacén no siempre recuperaba el espacio de inmediato. El sistema de archivos puede necesitar que el proceso libere del todo el archivo, o un reinicio, antes de que el número se actualice. Vuelve a correr la revisión de tamaño tras cerrar Codex por completo, y reinicia si sigue atascado. Si el espacio de verdad nunca vuelve, revisa que hayas quitado los archivos grandes correctos (usa el listado "del más grande al más chico") y no marcadores vacíos.

¿Claude Code o Cursor tienen el mismo problema de disco?

Este en concreto, no. Verificamos que Claude Code no tiene este almacén de logs SQLite-WAL siempre activo: es arquitectónicamente distinto, así que el bug del almacén de Codex no aplica ahí, y lo mismo vale para el diseño distinto de Cursor. Dicho esto, ningún agente está libre de mantenimiento en general: cualquier herramienta puede dejar cachés o directorios de datos que crecen. Revisa de vez en cuando el almacenamiento de cada una y su documentación oficial para ver dónde escribe, a junio de 2026.

Recomendación final

Haz de la revisión de tamaño de ~/.codex en 30 segundos un hábito, no una emergencia. Cuando esté grande, cierra Codex, confirma la ruta, borra solo los archivos log/WAL específicos y deja que una limpieza programada y una exclusión de backup eviten que regrese. Mantén el marco proporcional: esto es orden doméstico para un SSD de resistencia finita, no una cuenta regresiva hacia la falla. Y mantén el borrado acotado y confirmado: la limpieza estrecha y a propósito es la misma disciplina que evita que un agente de IA haga daño en cualquier otra parte de tu máquina.

👉 Guarda esta rutina y combínala con nuestra guía complementaria sobre cómo evitar que un agente de IA borre tus archivos, y luego recorre el resto del hub de Automatización con IA para el set completo de mantenimiento de agentes locales.

Guías relacionadas

• Cómo evitar que un agente de IA de programación borre tus archivos — las barreras de seguridad que hacen del borrado acotado la opción por defecto.
• Los 5 problemas de correr agentes de IA de programación en local (+ una rutina de mantenimiento) — el hub al que se conecta este playbook.
• ChatGPT vs Claude vs Gemini en español — cómo se comparan los asistentes principales cuando de verdad programas.
• Hub de Automatización con IA — más guías de operación de agentes locales.