# Cómo limpiar los restos de las herramientas de codificación con IA en Mac > Las herramientas de IA pueden dejar compilaciones, versiones antiguas del CLI y conversaciones valiosas. Mide cada grupo y comprueba su uso y recuperación antes de borrar. Published: 2026-08-21 | Updated: 2026-10-05 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. En esta muestra, las salidas de Rust ocupaban mucho más que cualquiera de los directorios de dependencias enumerados. 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. - **Cursor**, la app de escritorio, también guarda su propia copia del agente en `~/Library/Application Support/Cursor/User/globalStorage/anysphere.cursor-agent-worker/agent-cli/.local/share/cursor-agent/versions/`, con `bin/cursor-agent` en la misma carpeta `.local` como lanzador. En el Mac medido después había acumulado siete versiones, 4,1 GB. - **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 identifica la versión de ese lanzador. Antes de retirar otra versión, comprueba que ningún proceso, actualización o instalación la use. Si no puedes confirmarlo, consérvala. Ejecuta el CLI y comprueba que el lanzador sigue funcionando antes de vaciar la Papelera.
Un enlace simbólico del lanzador en PATH apunta, mediante current, a un directorio de versión. Antes de borrar otros directorios hay que comprobar por separado si siguen en uso.
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. La limpieza de [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. Las sesiones antiguas tienen un camino aparte, que recorres tú. La Luna lejana de la página Limpiar abre Limpieza y cuidado de IA, que guarda un plazo para cada herramienta y lista las sesiones de Codex y Claude Code más antiguas que ese plazo, además de las sesiones de Claude Code cuya carpeta de proyecto ya no existe, cada una con su título y fecha, y nada se borra hasta que lo marques. Una sesión de Codex se copia primero a la Papelera y luego se borra con el propio comando de Codex, para que su índice siga entero, y las imágenes y notas que Codex generó para ella van también a la Papelera. Una sesión usada en las últimas 24 horas nunca aparece en la lista, así que puedes limpiar con Codex y Claude Code abiertos, y las memorias, planes y skills tampoco aparecen allí en ninguna lista. ## 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 si conservas las fuentes y dependencias necesarias. Detén las compilaciones y comprueba que puedes regenerar los archivos antes de borrarlos. **Caro de reconstruir.** Registros de paquetes, `node_modules`, CocoaPods, entornos virtuales de Python, directorios `vendor`, pesos de modelos, DeviceSupport de iOS. Recuperarlos puede requerir conexión, las descargas o versiones originales y una cadena de herramientas compatible. El coste real no son solo 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. `cargo build` puede reconstruir `target/` localmente si conservas las fuentes, dependencias y herramientas necesarias. `npm ci` puede necesitar descargas del registro, además de un lockfile válido. Cualquiera puede tardar según el proyecto, y una dependencia no disponible puede impedir terminar. Confundir sus costes de recuperación es un error, 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. Las cachés se eliminan de forma permanente de manera predeterminada. Puedes elegir la Papelera en Ajustes y restaurar los archivos mientras sigan allí. El resultado también muestra los elementos omitidos y los errores. 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. La copia propia de Cursor dentro de la app de escritorio se trata igual, y una versión vieja puede irse con Cursor abierto, siempre que ningún proceso la esté usando. 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`; comandos como clean, uninstall y optimize admiten `--dry-run` para previsualizar sus acciones. Ambos comparten la lista de exclusiones del usuario en `~/.config/mole/whitelist` y un registro de operaciones en `~/Library/Logs/mole/operations.log`, y todo corre localmente sin subir nada y sin telemetría.
Pantalla de revisión de limpieza de Mole: categorías de caché con su tamaño y una casilla cada una, y abajo el botón para limpiar definitivamente los 5,14 GB seleccionados.
Encontrar y borrar son dos pasos separados. La revisión muestra por categoría lo que encontró el escaneo, y no se borra nada hasta que lo confirmas.
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. Nunca borra por sí mismo archivos de modelos, y la limpieza ordinaria nunca toca el historial de chat de IA: las sesiones antiguas y los modelos de Ollama sin usar desde hace un mes solo se van desde Limpieza y cuidado de IA, una casilla a la vez, y el propio comando de Ollama borra los modelos. Los demás modelos se quedan con las herramientas que los 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 el destino y verifica que ninguna otra instalación, actualización o proceso use las otras versiones antes de retirarlas. Ordenar por fecha falla ante 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. La limpieza ordinaria de 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. La página independiente Limpieza y cuidado de IA puede listar sesiones de Codex y Claude Code que superan el plazo elegido para cada herramienta, además de sesiones de Claude Code cuyo proyecto ya no existe, sin marcar para revisarlas una a una. ### ¿Limpiar las cachés de build hace algo más lento? La primera compilación tarda más mientras se regenera la caché. La compilación incremental ayuda a acelerar las siguientes, pero el tiempo de recuperación depende del proyecto y de las herramientas. Detén las compilaciones activas y conserva las fuentes y dependencias necesarias. Las salidas pueden eliminarse tras comprobar que se pueden regenerar; reconstruir `node_modules` también puede requerir acceso al registro de paquetes. ### ¿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). Los modelos de Ollama son la única excepción que Mole maneja: Limpieza y cuidado de IA lista los que llevan un mes sin usarse y borra los que marques con el propio `ollama rm` de Ollama, así que los blobs que otro modelo todavía usa se quedan. ## 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