# Cómo limpiar los restos de las herramientas de codificación con IA en Mac > Los agentes de codificación multiplican las salidas de build, conservan cada versión reemplazada del CLI y guardan meses de transcripciones que parecen logs. Mide cada una, y ordena por lo que cuesta recuperarla, no por tamaño. Published: 2026-08-21 | Updated: 2026-08-22 Un disco que estuvo cómodo durante dos años puede llenarse en unos pocos meses de usar agentes de codificación a diario. Los agentes en sí son pequeños. Lo que cambió es cuántas veces compila la máquina, cada cuánto un CLI se reemplaza a sí mismo en disco, y cuánto de tu propio razonamiento ahora vive como texto en tu directorio de inicio. Casi todo el crecimiento cae en tres categorías, y necesitan tres decisiones distintas, porque cuestan tres cantidades muy distintas recuperarlas. Los pesos de modelos son el sospechoso obvio y normalmente el equivocado para este problema en concreto. Ollama, LM Studio y Hugging Face mantienen almacenes direccionados por contenido que solo sus propias herramientas pueden podar con seguridad, y eso se cubre por separado en [quitar restos de herramientas de IA](https://mole.fit/es/blog/how-to-remove-ai-tool-leftovers-mac). Este artículo trata sobre lo que dejan atrás los agentes de codificación con IA mientras trabajas. ## Mide antes de borrar nada Dos comandos responden la mayor parte de la pregunta. El primero suma los directorios de inicio de los agentes: ``` du -sh ~/.codex ~/.claude ~/.local/share/claude ~/.grok ~/.cache 2>/dev/null | sort -h ``` El segundo encuentra salidas de build dispersas por cada proyecto que hayas abierto alguna vez. Reemplaza las raíces con donde guardes tu código: ``` find ~/www ~/Projects -maxdepth 3 -type d \ \( -name target -o -name node_modules -o -name .next -o -name dist -o -name build \) \ -prune -exec du -sh {} + 2>/dev/null | sort -h | tail -20 ``` `-prune` evita que `find` descienda a un directorio que ya coincidió, lo cual importa aquí: sin él, `find` recorre cada archivo dentro de un `target/` de 24 GB antes de seguir. En el Mac que medí mientras escribía esto, las dos primeras líneas eran un `target/` de Rust con 24 GB y el `target/` de un proyecto Tauri con 9,8 GB, contra árboles de `node_modules` que iban de 134 MB a 1,5 GB. La proporción es lo que importa: lo que parecía el problema de las dependencias era el dos por ciento de la cifra real. Si prefieres ver esto como un mapa en vez de una lista, la vista Analyze de [Mole](https://mole.fit/) dibuja los mismos volúmenes como un treemap y te deja entrar al rectángulo más grande, lo cual es más rápido que adivinar qué raíz pasarle a `find`. ## Categoría uno: salidas de build, amplificadas Esta categoría no es nueva. El volumen sí. Un desarrollador trabajando a mano compila unas cuantas veces al día. Un agente trabajando en una tarea compila después de casi cada edición, corre las pruebas, prueba un segundo enfoque, y vuelve a compilar. Las cachés que antes crecían durante meses ahora crecen en una tarde, y los directorios de build incremental están diseñados para cambiar disco por velocidad. **Rust** suele ser, por mucho margen, el más grande. Un directorio `target/` guarda dependencias compiladas, estado de compilación incremental y la salida de los scripts de build, todo mantenido por separado según el perfil, así que debug y release son dos copias completas. `cargo clean` sin opciones "borrará todo el directorio target". Previsualízalo primero: ``` cargo clean --dry-run cargo clean --release ``` `cargo clean -p ` limpia solo los paquetes indicados, la herramienta correcta cuando el problema es un solo miembro del workspace. **JavaScript** reparte su salida de forma más dispersa. Más allá de `node_modules` en sí hay `node_modules/.cache` (usada por bundlers y transpiladores), `.next` para builds de Next.js, y el `dist` o `build` que escriba tu cadena de herramientas. Busca las cachés específicamente: ``` find ~/www -maxdepth 4 -type d -path '*/node_modules/.cache' -prune -exec du -sh {} + \ 2>/dev/null | sort -h | tail ``` **Python** deja `__pycache__` junto a cada paquete que importa. Individualmente diminutos, y hay miles. Cuéntalos antes de borrarlos, porque la misma forma de comando con `rm -rf` al final no perdona si una raíz está mal: ``` find ~/www -type d -name __pycache__ -prune -print | wc -l ``` Las cachés de bytecode se regeneran en la siguiente importación sin ningún acceso a red, así que esto es lo más seguro de borrar en todo el artículo. **Go** mantiene una sola caché de build global en vez de directorios por proyecto. `go env GOCACHE` imprime su ubicación y `go clean -cache` "hace que clean elimine toda la caché de build de go". `go clean -testcache` vence los resultados de pruebas en caché sin descartar los paquetes compilados. En mi máquina la caché de build pesaba 183 MB contra una caché de módulos de 38 MB, así que vale la pena revisar el lado del build aunque los módulos descargados sean pequeños. **Xcode** necesita su propio tratamiento, porque DerivedData, archives, device support y los runtimes de simulador son cuatro tipos de cosas con cuatro costos de restauración distintos. La carpeta DerivedData de este Mac medía 9,3 GB. [Limpiar el almacenamiento de Xcode](https://mole.fit/es/blog/how-to-clean-up-xcode-mac) cubre cuáles puedes borrar y cuáles conservar para la simbolización. Gradle y Maven se dividen de la misma forma entre directorios `build/` por proyecto y un almacén global bajo `~/.gradle` o `~/.m2`, y el lado global pertenece con los demás registros en [limpiar cachés de desarrollo](https://mole.fit/es/blog/how-to-clear-dev-caches-mac). ## Categoría dos: versiones de CLI reemplazadas Esta es la que casi nadie busca, y en una máquina que corre varios agentes suele ser más grande que todas las cachés juntas. Los CLI de agentes se actualizan a sí mismos descargando una versión nueva completa y apuntando un lanzador hacia ella. Cada versión es autocontenida, así que no comparte archivos con la versión anterior. El puntero se mueve. La versión vieja se queda. Nada la barre, así que el conteo crece de uno en uno con cada actualización, para siempre. Las estructuras siguen un mismo patrón con diferencias cosméticas: - **Codex** guarda `~/.codex/packages/standalone/releases/-/`, con un symlink `current` un nivel arriba que apunta a la versión activa. - **Claude Code** guarda `~/.local/share/claude/versions/`, donde cada entrada es un solo archivo ejecutable en vez de un directorio, y `~/.local/bin/claude` es un symlink hacia la versión activa. - **Grok** guarda `~/.grok/downloads/grok--macos-` como archivos, con `~/.grok/bin/grok` y `~/.grok/bin/agent` apuntando a la build actual. - **Cursor Agent** guarda `~/.local/share/cursor-agent/versions/-/`, con `~/.local/bin/cursor-agent` como lanzador. - **GitHub Copilot CLI** instalado vía npm se reemplaza a sí mismo en el sitio, pero su script de instalación escribe un paquete versionado bajo un prefijo que por defecto es `$HOME/.local` para un usuario sin root. Mole revisa `~/.copilot/pkg/universal` para la misma forma. Mide todos a la vez: ``` du -sh ~/.codex/packages/standalone/releases/* \ ~/.local/share/claude/versions/* \ ~/.grok/downloads/* \ ~/.local/share/cursor-agent/versions/* 2>/dev/null ``` En el Mac que usé para este artículo eso imprimió cinco versiones de Codex entre 262 MB y 310 MB, cinco binarios de Claude Code entre 293 MB y 306 MB, dos builds de Grok, y dos versiones de Cursor Agent. Unos 3,5 GB en total, de los cuales cerca de 920 MB estaban activos. Todo lo demás era un binario que ya había sido reemplazado. El propio rastreador de issues de Codex tiene una solicitud abierta para esto, donde quien la reportó mide el crecimiento en unos 250 MB por actualización ([openai/codex#22293](https://github.com/openai/codex/issues/22293)). ### Resuelve el lanzador antes de borrar un solo directorio El atajo tentador es ordenar por fecha y conservar la más reciente. No lo hagas. Dos situaciones normales lo rompen: fijaste una versión más antigua a propósito después de una regresión, o una actualización preparó el directorio nuevo antes de mover el puntero. Borrar la versión activa te deja con un lanzador que apunta a nada. Pregúntale al lanzador en su lugar. Es un symlink, así que resuélvelo: ``` readlink -f "$(command -v codex)" readlink -f "$(command -v claude)" readlink -f "$(command -v grok)" ``` Eso imprime el objetivo real, por ejemplo `~/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin/bin/codex`, y `ls -l "$(command -v codex)"` muestra cada salto en vez de la respuesta final. Lo que sea que aparezca está activo. Cualquier hermano que no esté en esa ruta quedó reemplazado, y mandarlo a la Papelera es seguro. Corre el CLI una vez después para confirmar que el lanzador todavía resuelve antes de vaciar la Papelera.
Un symlink de lanzador en el PATH resolviendo a través de un puntero current hacia un directorio de versión, mientras los directorios de versión hermanos a su lado están sin referenciar y son seguros de quitar.
El lanzador, no la marca de tiempo, es lo que identifica la versión activa. Tanto una reversión fijada como una actualización a medio terminar hacen que el directorio más reciente sea la respuesta equivocada.
## Categoría tres: estado de trabajo del agente, que no es basura La tercera categoría es donde un limpiador puede hacer daño de verdad, porque se ve exactamente igual que las dos primeras. Las transcripciones de sesión, memorias, planes y adjuntos generados viven bajo `~/.codex/sessions`, `~/.codex/archived_sessions`, `~/.codex/memories`, `~/.claude/projects` y `~/.grok/sessions`. Son archivos JSONL nombrados por id de sesión, con marca de tiempo, de solo anexado, y nunca dejan de crecer. Toda heurística que usa un limpiador genérico dice archivo de log. En el Mac que medí, `~/.codex/sessions` pesaba 9,8 GB, `~/.claude/projects` pesaba 2,7 GB repartidos en 2.362 archivos de transcripción, y `~/.grok/sessions` pesaba 1,3 GB: una cifra grande y tentadora pegada a archivos que parecen desechables. No son logs. Una transcripción es el registro de cómo se llegó a un cambio: los enfoques probados y descartados, la restricción que eliminó uno de ellos, la razón por la que la forma final es la que es. Ese razonamiento no existe en ningún otro lugar. El mensaje de commit registra qué cambió, el código registra la opción que sobrevivió y no las otras cuatro descartadas. Meses de esto se acumulan en silencio, y descubres el valor la primera vez que vuelves a preguntar por qué algo se construyó así. El riesgo más grande no es un limpiador de terceros. Claude Code trae su propia barrida de retención: `cleanupPeriodDays` es 30 días por defecto, y al arrancar borra las transcripciones bajo `projects/`, archivos de plan, capturas previas a la edición en `file-history/`, y listas de tareas por sesión más antiguas que eso. Su [referencia del directorio .claude](https://code.claude.com/docs/en/claude-directory) documenta exactamente qué rutas se barren y cuáles se conservan indefinidamente. Si quieres un año de transcripciones, sube ese número ahora en vez de descubrir el valor por defecto después del hecho. La misma página documenta `claude project purge` para el caso contrario, cuando quieres borrar deliberadamente el estado de un proyecto. [Mole](https://mole.fit/) nunca toca nada de esto. Esas cinco rutas, más `~/.claude/file-history`, `~/.claude/plans`, `~/.claude/tasks`, `~/.codex/attachments` y `~/.codex/generated_images`, están en su lista de protección sin importar la antigüedad. No hay umbral de edad, no hay excepción de "más de 90 días", no hay ajuste para activar una. Una excepción por edad se construyó una vez para estas rutas y se revirtió el mismo día, porque una transcripción vieja no es una transcripción obsoleta. ## Por debajo: ordena por costo de restauración, no por tamaño Esta es la regla que hace que las tres categorías se puedan decidir, y es lo único de este artículo que vale la pena memorizar. Clasifica cada candidato por lo que cuesta recuperarlo, no por cuántos gigabytes muestra. **Regenerable localmente.** Salidas de build, estado de compilación incremental, cachés de bytecode, DerivedData. El costo de borrar esto son minutos de CPU en una máquina en la que ya estás sentado, sin red de por medio. Borra sin miedo, y borra los más grandes sin pensarlo mucho. **Caro de reconstruir.** Registros de paquetes, `node_modules`, CocoaPods, entornos virtuales de Python, directorios `vendor`, pesos de modelos, DeviceSupport de iOS. Cada uno necesita red, un registro que todavía sirva las versiones exactas que nombra tu lockfile, y a veces una cadena de herramientas nativa. El costo real no son minutos con buena conexión, es si puedes trabajar o no en un tren. Revisa estos uno por uno. **Irremplazable.** Transcripciones de chat, memorias del agente, archivos de plan, estado de proyectos, fine-tunes locales. Ninguna cantidad de CPU o ancho de banda recupera esto. Nunca pertenecen a un borrado en lote, y no deberían ser del tipo de cosa que se puede seleccionar por accidente. La trampa es que el nivel uno y el nivel dos se ven idénticos. `target/` y `node_modules/` son ambos directorios grandes en la raíz de un proyecto, ambos llenos de artefactos de dependencias, ambos listados en `.gitignore`, ambos regenerados por un solo comando. Ordenados por tamaño quedan uno junto al otro. Pero `cargo build` reconstruye `target/` a partir de código fuente que ya tienes en disco, mientras que `npm ci` necesita que el registro siga funcionando y que el lockfile todavía resuelva. Uno es un descanso para el café. El otro es una tarde bloqueada o un paquete retirado que no puedes volver a instalar. Confundirlos es el error más común de esta categoría, y por eso "borra las carpetas más grandes" es mal consejo incluso cuando libera más espacio.
Tres niveles ordenados por costo de restauración, con target y node_modules mostrados como directorios de proyecto visualmente idénticos que caen en niveles distintos porque uno se reconstruye desde código fuente local y el otro necesita un registro.
El tamaño ordena a los candidatos en el orden equivocado. Dos directorios que se ven iguales en la raíz de un proyecto pueden diferir en un día entero de trabajo en lo que cuesta restaurarlos.
## Haciendo esto en Mole La vía manual funciona y no cuesta nada. Lo que añade [Mole](https://mole.fit/) es que las tres categorías llegan en una sola lista revisada con el límite entre niveles ya aplicado, así que no eres tú quien tiene que recordar qué directorio con punto guarda las transcripciones. Abre la herramienta Clean y corre un escaneo. Escanear es gratis y no necesita licencia. Cada candidato llega con su ruta exacta, su propietario y su tamaño medido, y nada se mueve hasta que apruebas la lista. Todo lo de baja confianza llega desmarcado, así que la acción por defecto siempre es la más pequeña. Los borrados van a la Papelera en vez de desvincularse, así que un error se arregla arrastrando de vuelta en lugar de restaurar desde una copia de seguridad, y una operación en lote reporta qué omitió y qué falló en vez de solo lo que quitó. Para las versiones de CLI reemplazadas específicamente, Mole hace por ti la resolución del lanzador descrita arriba. Lee el symlink del lanzador de cada CLI de agente, lo resuelve hasta la versión activa, y excluye esa versión del conjunto de candidatos, así que una reversión deliberada se mantiene intacta en vez de tratarse como una versión vieja. El caso medido detrás de ese comportamiento es Codex: cinco versiones con 1,2 GB y solo una activa. El [Mole CLI](https://github.com/tw93/Mole) es gratis, de código abierto, y cubre el mismo trabajo desde una shell con `mo clean`; todo comando destructivo acepta `--dry-run`, así que puedes leer la lista completa de rutas antes de que se mueva nada. Ambos comparten una lista de protección en `~/.config/mole/whitelist` y un log de operaciones en `~/Library/Logs/mole/operations.log`, y todo corre localmente sin subir nada y sin telemetría.
La vista Clean de Mole mostrando una limpieza revisada con cada candidato listado por ruta y tamaño, y el espacio realmente recuperado reportado tras la operación.
Encontrar y borrar son dos pasos separados. La pantalla de finalización reporta lo que realmente se recuperó, no lo que se estimó antes del escaneo.
Vale la pena decirlo sin rodeos: Mole no es una copia de seguridad, no responde a malware, y no sustituye al desinstalador del proveedor para software que instala drivers o extensiones del sistema. No borra pesos de modelos ni historial de chat de IA, y no va a ofrecerse a hacerlo. Eso se queda con las herramientas que lo poseen. ## Evitar que vuelva a acumularse Tres cambios de configuración cubren la mayor parte de la reacumulación. **Apunta Rust a un solo directorio de build.** `CARGO_TARGET_DIR` fija la "ubicación donde colocar todos los artefactos generados", así que cada proyecto escribe en un solo árbol que puedes medir y limpiar en un solo sitio. El costo es real: Cargo bloquea el directorio de build, así que dos proyectos que comparten un target dir compilan uno a la vez en vez de en paralelo. Si corres builds simultáneos habitualmente, mantenlos separados y programa una barrida en su lugar. **Poda los almacenes globales con un horario, no a mano.** Cargo moderno ya elimina entradas sin usar de su caché global durante los comandos normales de build y fetch, y npm describe su caché como autorreparable con `npm cache verify` como comando de mantenimiento. Deja que esas políticas corran en vez de borrar directo las carpetas con punto del directorio de inicio. [Limpiar cachés de desarrollo](https://mole.fit/es/blog/how-to-clear-dev-caches-mac) tiene los comandos por herramienta. **Comprueba si tu CLI de agente poda sus propias versiones, y asume que no.** Al momento de escribir esto no pude encontrar una bandera documentada ni una clave de configuración en Codex ni en Claude Code que pode binarios de versiones reemplazadas, y la solicitud de Codex sigue abierta. El `cleanupPeriodDays` de Claude Code barre datos de sesión, no binarios de versión, así que no ayuda aquí. Hasta que eso cambie, este es un trabajo recurrente, y es el elemento de mayor valor de la lista porque vuelve al ritmo con el que tus agentes publican actualizaciones. ## Preguntas frecuentes ### ¿Cuánto disco usan realmente las herramientas de codificación con IA? Los binarios pesan unos cuantos cientos de megabytes cada uno, pero lo que importa es la acumulación. En la máquina medida para este artículo, cuatro CLI de agentes ocupaban unos 3,5 GB en sus directorios de versiones, con solo 920 MB de eso activo, las transcripciones de sesión sumaban unos 14 GB, y un solo directorio `target/` de Rust pesaba 24 GB. Tus cifras van a variar más por lenguaje que por agente, así que corre los dos comandos `du` al inicio de este artículo en vez de confiar en la cifra de nadie, incluida esta. ### ¿Es seguro borrar versiones antiguas de Claude Code o Codex? Sí, siempre que resuelvas primero el lanzador. Corre `readlink -f "$(command -v claude)"` o el equivalente para tu CLI, conserva la ruta que imprima, y manda al resto a la Papelera. No ordenes por fecha y te quedes con la más reciente, porque tanto una reversión fijada como una actualización a medio terminar hacen que el directorio más reciente sea el equivocado. Corre el CLI una vez después de borrar y antes de vaciar la Papelera. ### ¿Un limpiador de Mac va a borrar el historial de chat de mi agente? Algunos sí, porque esos archivos se ven exactamente como logs. Ese es el riesgo específico de esta categoría. Mole nunca toca `~/.codex/sessions`, `~/.codex/archived_sessions`, `~/.codex/memories`, `~/.claude/projects` ni `~/.grok/sessions` sin importar la antigüedad. Antes de correr cualquier limpiador, comprueba si esas rutas aparecen en su lista de candidatos, y si la herramienta no te va a mostrar la lista antes de actuar, esa es tu respuesta. ### ¿Limpiar las cachés de build hace algo más lento? El siguiente build, una vez, y luego no. El estado de compilación incremental existe para que el segundo build sea más rápido que el primero, así que borrarlo te cuesta exactamente un build en frío por proyecto. Esa es toda la desventaja, y por eso las salidas de build pertenecen al nivel de borrar sin miedo mientras que un árbol de `node_modules` que necesita ida y vuelta al registro no. ### ¿Qué pasa con los modelos de Ollama y las cachés de Hugging Face? Fuera del alcance de este artículo, y de forma deliberada. Esas herramientas usan almacenes direccionados por contenido donde dos modelos pueden compartir el mismo blob, así que borrar archivos a mano puede dejar huérfano a un modelo que todavía los referencia. Usa el comando de borrado propio de cada herramienta, que se cubre en [quitar restos de herramientas de IA](https://mole.fit/es/blog/how-to-remove-ai-tool-leftovers-mac). ## Por dónde seguir Ordena por costo de restauración, resuelve el lanzador antes de borrar una versión, deja en paz las transcripciones. Si la línea más grande de tu medición fue un almacén de paquetes, [limpiar cachés de desarrollo](https://mole.fit/es/blog/how-to-clear-dev-caches-mac) tiene los comandos de poda por herramienta. Si fue Xcode, [limpiar el almacenamiento de Xcode](https://mole.fit/es/blog/how-to-clean-up-xcode-mac) separa las carpetas reconstruibles de los archives que conservas. Si fue un almacén de modelos, [quitar restos de herramientas de IA](https://mole.fit/es/blog/how-to-remove-ai-tool-leftovers-mac) explica por qué la herramienta propietaria tiene que hacer el borrado. --- Canonical HTML page: https://mole.fit/es/blog/how-to-clean-up-ai-coding-tools-mac Blog index for agents: https://mole.fit/es/blog/llms.txt Site index for agents: https://mole.fit/llms.txt