# Comment nettoyer après les outils de code IA sur Mac > Les agents de code multiplient les sorties de build, gardent chaque version de CLI dépassée, et stockent des mois de transcriptions qui ressemblent à des logs. Mesurez chacune, puis triez selon ce qu'il en coûte de les récupérer plutôt que par taille. Published: 2026-08-21 | Updated: 2026-08-22 Un disque confortable depuis deux ans peut se remplir en quelques mois d’usage quotidien d’agents de code. Les agents eux-mêmes sont petits. Ce qui a changé, c’est la fréquence à laquelle la machine compile, la fréquence à laquelle une CLI se remplace elle-même sur le disque, et la part de votre propre raisonnement qui vit désormais sous forme de texte dans votre dossier personnel. Presque toute cette croissance se répartit en trois catégories, qui appellent trois décisions différentes, parce qu’elles coûtent trois montants très différents à récupérer. Les poids de modèles sont le suspect évident, et généralement le mauvais pour ce problème précis. Ollama, LM Studio et Hugging Face tiennent des dépôts adressés par contenu que seuls leurs propres outils peuvent élaguer en sécurité, un sujet couvert séparément dans [retirer les résidus d’outils d’IA](https://mole.fit/fr/blog/how-to-remove-ai-tool-leftovers-mac). Cet article traite de ce que les agents de code IA laissent derrière eux pendant que vous travaillez. ## Mesurez avant de supprimer quoi que ce soit Deux commandes répondent à la majeure partie de la question. La première totalise les dossiers personnels des agents : ``` du -sh ~/.codex ~/.claude ~/.local/share/claude ~/.grok ~/.cache 2>/dev/null | sort -h ``` La seconde retrouve les sorties de build éparpillées dans tous les projets que vous avez jamais ouverts. Remplacez les racines par l’endroit où vous gardez votre code : ``` 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` empêche `find` de descendre dans un dossier déjà trouvé, ce qui compte ici : sans ça, `find` parcourt chaque fichier à l’intérieur d’un `target/` de 24 Go avant de passer à la suite. Sur le Mac utilisé pour mesurer cet article, les deux premières lignes étaient un `target/` Rust à 24 Go et le `target/` d’un projet Tauri à 9,8 Go, contre des arborescences `node_modules` allant de 134 Mo à 1,5 Go. Le ratio est le point important : ce qui ressemble au problème des dépendances ne représentait que deux pour cent du chiffre réel. Si vous préférez voir ça comme une carte plutôt qu’une liste, la vue Analyze de [Mole](https://mole.fit/) dessine les mêmes volumes en treemap et vous laisse explorer le plus gros rectangle, ce qui est plus rapide que de deviner quelle racine passer à `find`. ## Catégorie un : les sorties de build, amplifiées Cette catégorie n’est pas nouvelle. Le volume, lui, l’est. Un développeur qui travaille à la main compile quelques fois par jour. Un agent qui traite une tâche compile après presque chaque modification, lance les tests, essaie une seconde approche, et compile à nouveau. Des caches qui grossissaient autrefois sur des mois grossissent maintenant sur un après-midi, et les dossiers de build incrémental sont conçus pour échanger du disque contre de la vitesse. **Rust** est généralement le plus gros, et de loin. Un dossier `target/` contient les dépendances compilées, l’état de compilation incrémentale et la sortie des scripts de build, conservés séparément par profil, donc debug et release sont deux copies complètes. `cargo clean` sans option « supprime l’intégralité du dossier target ». Prévisualisez d’abord : ``` cargo clean --dry-run cargo clean --release ``` `cargo clean -p ` ne nettoie que les paquets nommés, l’outil approprié quand un seul membre du workspace pose problème. **JavaScript** répartit sa sortie plus finement. Au-delà de `node_modules` lui-même, il y a `node_modules/.cache` (utilisé par les bundlers et les transpileurs), `.next` pour les builds Next.js, et quel que soit le `dist` ou `build` qu’écrit votre chaîne d’outils. Trouvez spécifiquement les caches : ``` find ~/www -maxdepth 4 -type d -path '*/node_modules/.cache' -prune -exec du -sh {} + \ 2>/dev/null | sort -h | tail ``` **Python** dépose `__pycache__` à côté de chaque paquet qu’il importe. Individuellement minuscule, et il y en a des milliers. Comptez-les avant de les supprimer, car la même forme de commande terminée par `rm -rf` ne pardonne rien si une racine est fausse : ``` find ~/www -type d -name __pycache__ -prune -print | wc -l ``` Les caches de bytecode se régénèrent au prochain import sans aucun accès réseau, c’est donc la chose la plus sûre à supprimer dans tout cet article. **Go** conserve un seul cache de build global plutôt que des dossiers par projet. `go env GOCACHE` affiche son emplacement, et `go clean -cache` « fait supprimer par clean tout le cache de build de Go ». `go clean -testcache` expire les résultats de tests en cache sans jeter les paquets compilés. Sur la machine utilisée ici, le cache de build faisait 183 Mo contre un cache de modules de 38 Mo, donc le côté build vaut la peine d’être vérifié même quand les modules téléchargés sont petits. **Xcode** exige un traitement à part, parce que DerivedData, les archives, le support d’appareils et les runtimes de simulateur sont quatre choses différentes avec quatre coûts de restauration différents. Le dossier DerivedData sur ce Mac pesait 9,3 Go. [Nettoyer le stockage Xcode](https://mole.fit/fr/blog/how-to-clean-up-xcode-mac) explique lesquels vous pouvez supprimer et lesquels garder pour la symbolication. Gradle et Maven se divisent de la même façon entre des dossiers `build/` par projet et un dépôt global sous `~/.gradle` ou `~/.m2`, et le côté global relève des autres registres dans [vider les caches de développement](https://mole.fit/fr/blog/how-to-clear-dev-caches-mac). ## Catégorie deux : les versions de CLI dépassées C’est celle que presque personne ne pense à chercher, et sur une machine qui fait tourner plusieurs agents, elle est souvent plus volumineuse que tous les caches réunis. Les CLI d’agents se mettent à jour elles-mêmes en téléchargeant une nouvelle version complète et en y pointant un lanceur. Chaque version est autonome, donc elle ne partage aucun fichier avec la version précédente. Le pointeur se déplace. L’ancienne version reste. Rien ne la balaie, donc le compte grossit d’une unité à chaque mise à jour, indéfiniment. Les structures suivent toutes le même schéma, avec des différences cosmétiques : - **Codex** conserve `~/.codex/packages/standalone/releases/-/`, avec un lien symbolique `current` un niveau au-dessus pointant vers la version active. - **Claude Code** conserve `~/.local/share/claude/versions/`, où chaque entrée est un simple fichier exécutable plutôt qu’un dossier, et `~/.local/bin/claude` est un lien symbolique vers la version active. - **Grok** conserve `~/.grok/downloads/grok--macos-` sous forme de fichiers, avec `~/.grok/bin/grok` et `~/.grok/bin/agent` pointant vers la version courante. - **Cursor Agent** conserve `~/.local/share/cursor-agent/versions/-/`, avec `~/.local/bin/cursor-agent` comme lanceur. - **GitHub Copilot CLI** installé via npm se remplace lui-même sur place, mais son script d’installation écrit un paquet versionné sous un préfixe qui vaut par défaut `$HOME/.local` pour un utilisateur non root. Mole vérifie `~/.copilot/pkg/universal` pour la même structure. Mesurez-les tous à la fois : ``` du -sh ~/.codex/packages/standalone/releases/* \ ~/.local/share/claude/versions/* \ ~/.grok/downloads/* \ ~/.local/share/cursor-agent/versions/* 2>/dev/null ``` Sur le Mac utilisé pour cet article, cela a affiché cinq versions de Codex entre 262 Mo et 310 Mo, cinq binaires Claude Code entre 293 Mo et 306 Mo, deux versions de Grok, et deux versions de Cursor Agent. Environ 3,5 Go au total, dont environ 920 Mo étaient actifs. Tout le reste était un binaire déjà remplacé. Le gestionnaire de tickets de Codex lui-même contient une demande ouverte à ce sujet, où le rapporteur mesure la croissance à environ 250 Mo par mise à jour ([openai/codex#22293](https://github.com/openai/codex/issues/22293)). ### Résolvez le lanceur avant de supprimer le moindre dossier Le raccourci tentant est de trier par date et de garder la plus récente. Ne le faites pas. Deux situations ordinaires cassent cette logique : vous avez délibérément épinglé une version plus ancienne après une régression, ou une mise à jour a préparé le nouveau dossier avant de basculer le pointeur. Supprimer la version active vous laisse avec un lanceur qui pointe vers rien. Demandez plutôt au lanceur. C’est un lien symbolique, donc résolvez-le : ``` readlink -f "$(command -v codex)" readlink -f "$(command -v claude)" readlink -f "$(command -v grok)" ``` Cela affiche la vraie cible, par exemple `~/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin/bin/codex`, et `ls -l "$(command -v codex)"` montre chaque saut plutôt que la réponse finale. Ce qui revient est la version active. Toute version sœur qui n’est pas sur ce chemin est dépassée, et la mettre à la Corbeille est sûr. Relancez la CLI une fois après coup pour confirmer que le lanceur se résout toujours avant de vider la Corbeille.
Un lien symbolique de lanceur sur le PATH se résolvant via un pointeur current vers un dossier de version, tandis que les dossiers de versions sœurs juste à côté ne sont plus référencés et peuvent être retirés en sécurité.
C’est le lanceur, pas l’horodatage, qui identifie la version active. Un retour en arrière épinglé comme une mise à jour à moitié terminée font tous deux du dossier le plus récent la mauvaise réponse.
## Catégorie trois : l’état de travail de l’agent, qui n’est pas indésirable La troisième catégorie est celle où un nettoyeur peut causer de vrais dégâts, parce qu’elle ressemble exactement aux deux premières. Les transcriptions de session, mémoires, plans et pièces jointes générées vivent sous `~/.codex/sessions`, `~/.codex/archived_sessions`, `~/.codex/memories`, `~/.claude/projects` et `~/.grok/sessions`. Ce sont des fichiers JSONL nommés d’après l’identifiant de session, horodatés, en ajout seul, et qui ne cessent jamais de grossir. Chaque heuristique qu’utilise un nettoyeur générique conclut à un fichier de log. Sur le Mac mesuré ici, `~/.codex/sessions` pesait 9,8 Go, `~/.claude/projects` pesait 2,7 Go répartis sur 2 362 fichiers de transcription, et `~/.grok/sessions` pesait 1,3 Go : un chiffre gros et tentant, attaché à des fichiers qui semblent jetables. Ce ne sont pas des logs. Une transcription est le compte rendu de la façon dont on est arrivé à un changement : les approches essayées et rejetées, la contrainte qui en a écarté une, la raison pour laquelle la forme finale est ce qu’elle est. Ce raisonnement n’existe nulle part ailleurs. Le message de commit enregistre ce qui a changé, le code enregistre l’option qui a survécu et non les quatre écartées. Des mois de cela s’accumulent discrètement, et vous découvrez la valeur la première fois que vous revenez demander pourquoi quelque chose a été construit ainsi. Le risque le plus important n’est pas un nettoyeur tiers. Claude Code embarque son propre balayage de rétention : `cleanupPeriodDays` vaut par défaut 30 jours, et au démarrage il supprime les transcriptions sous `projects/`, les fichiers de plan, les instantanés pré-édition dans `file-history/`, et les listes de tâches par session plus anciennes que cette limite. Sa [référence du dossier .claude](https://code.claude.com/docs/en/claude-directory) documente précisément quels chemins sont balayés et lesquels sont conservés indéfiniment. Si vous voulez conserver une année de transcriptions, augmentez ce nombre maintenant plutôt que de découvrir la valeur par défaut après coup. La même page documente `claude project purge` pour le cas inverse, quand vous voulez faire disparaître délibérément l’état d’un projet. [Mole](https://mole.fit/) ne touche jamais à rien de tout cela. Ces cinq chemins, plus `~/.claude/file-history`, `~/.claude/plans`, `~/.claude/tasks`, `~/.codex/attachments` et `~/.codex/generated_images`, figurent sur sa liste de protection, quel que soit leur âge. Il n’y a aucun seuil d’âge, aucune exception « plus vieux que 90 jours », aucun réglage pour en activer une. Une exception basée sur l’âge a été construite une fois pour ces chemins, puis annulée le jour même, parce qu’une vieille transcription n’est pas une transcription périmée. ## Sous le capot : trier par coût de restauration, pas par taille C’est la règle qui rend les trois catégories tranchables, et c’est la seule chose de cet article qui mérite d’être retenue. Classez chaque candidat selon ce qu’il coûte à récupérer, pas selon le nombre de gigaoctets qu’il affiche. **Régénérable localement.** Sorties de build, état de compilation incrémentale, caches de bytecode, DerivedData. Le coût de leur suppression se compte en minutes de CPU sur une machine devant laquelle vous êtes déjà assis, sans réseau impliqué. Supprimez librement, et supprimez les plus gros sans trop réfléchir. **Coûteux à reconstruire.** Registres de paquets, `node_modules`, CocoaPods, environnements virtuels Python, dossiers `vendor`, poids de modèles, DeviceSupport iOS. Chacun exige un réseau, un registre qui sert encore les versions exactes que nomme votre lockfile, et parfois une chaîne d’outils native. Le vrai coût n’est pas quelques minutes sur une bonne connexion, c’est de savoir si vous pouvez travailler du tout dans un train. Passez ceux-ci en revue un par un. **Irremplaçable.** Transcriptions de chat, mémoires d’agent, fichiers de plan, état de projet, fine-tunes locaux. Aucune quantité de CPU ou de bande passante ne les ramène. Ils n’ont jamais leur place dans une suppression groupée, et ne devraient pas être le genre de chose qu’on peut sélectionner par accident. Le piège, c’est que le premier et le deuxième niveau se ressemblent. `target/` et `node_modules/` sont tous deux de gros dossiers à la racine d’un projet, tous deux pleins d’artefacts de dépendances, tous deux listés dans `.gitignore`, tous deux régénérés par une seule commande. Triés par taille, ils se retrouvent côte à côte. Mais `cargo build` reconstruit `target/` à partir de sources déjà présentes sur le disque, tandis que `npm ci` a besoin que le registre soit toujours disponible et que le lockfile se résolve encore. L’un est une pause café. L’autre est un après-midi bloqué ou un paquet retiré que vous ne pouvez plus réinstaller. Les confondre est l’erreur la plus courante de cette catégorie, et c’est pourquoi « supprimer les plus gros dossiers » est un mauvais conseil, même quand cela libère le plus d’espace.
Trois niveaux classés par coût de restauration, avec target et node_modules présentés comme des dossiers de projet visuellement identiques mais atterrissant dans des niveaux différents parce que l’un se reconstruit à partir de sources locales et l’autre exige un registre.
La taille classe les candidats dans le mauvais ordre. Deux dossiers qui se ressemblent à la racine d’un projet peuvent différer d’une journée de travail entière dans ce qu’il en coûte de les restaurer.
## Faire tout ça dans Mole La méthode manuelle fonctionne et ne coûte rien. Ce qu’ajoute [Mole](https://mole.fit/), c’est que les trois catégories arrivent dans une seule liste passée en revue, avec la frontière des niveaux déjà appliquée, si bien que ce n’est plus vous qui devez vous souvenir quel dossier point contient les transcriptions. Ouvrez l’outil Clean et lancez un scan. Le scan est gratuit et ne nécessite aucune licence. Chaque candidat arrive avec son chemin, son propriétaire et sa taille mesurée exacts, et rien ne bouge tant que vous n’avez pas approuvé la liste. Tout ce qui est peu fiable arrive décoché, si bien que l’action par défaut est toujours la plus prudente. Les suppressions vont à la Corbeille plutôt que d’être détruites directement, si bien qu’une erreur se répare en la ressortant plutôt qu’en restaurant une sauvegarde, et une opération groupée signale ce qu’elle a ignoré et ce qui a échoué, pas seulement ce qu’elle a retiré. Pour les versions de CLI dépassées en particulier, Mole fait pour vous la résolution du lanceur décrite plus haut. Il lit le lien symbolique du lanceur pour chaque CLI d’agent, le résout vers la version active, et exclut cette version de l’ensemble des candidats, si bien qu’un retour en arrière délibéré reste intact plutôt que d’être traité comme une vieille version. Le cas mesuré derrière ce comportement est Codex : cinq versions pour 1,2 Go, une seule active. Le [Mole CLI](https://github.com/tw93/Mole) est gratuit, open source, et couvre la même tâche depuis un shell avec `mo clean` ; chaque commande destructive accepte `--dry-run`, pour que vous lisiez la liste complète des chemins avant que quoi que ce soit ne bouge. Les deux partagent une seule liste de protection à `~/.config/mole/whitelist` et un seul journal d’opérations à `~/Library/Logs/mole/operations.log`, et tout tourne en local, sans envoi ni télémétrie.
La vue Clean de Mole montrant un nettoyage passé en revue, chaque candidat listé par chemin et taille, et l’espace réellement récupéré indiqué après l’opération.
Découverte et suppression sont deux étapes distinctes. L’écran de fin indique ce qui a réellement été récupéré plutôt que ce qui avait été estimé avant le scan.
Autant le dire sans détour : Mole n’est pas une sauvegarde, ni une réponse aux malwares, ni un substitut au désinstalleur d’un éditeur pour un logiciel qui embarque des pilotes ou des extensions système. Il ne supprime ni les poids de modèles ni l’historique de chat des IA, et ne le proposera jamais. Ceux-ci restent l’affaire des outils qui les possèdent. ## Empêcher que ça ne revienne Trois changements de configuration couvrent l’essentiel de la repousse. **Dirigez Rust vers un seul dossier de build.** `CARGO_TARGET_DIR` fixe « l’emplacement où placer tous les artefacts générés », si bien que chaque projet écrit dans une seule arborescence que vous pouvez mesurer et nettoyer à un seul endroit. Le compromis est réel : Cargo verrouille le dossier de build, donc deux projets partageant un même dossier target compilent l’un après l’autre plutôt qu’en parallèle. Si vous lancez des builds concurrents régulièrement, gardez-les séparés et programmez plutôt un balayage. **Élaguez les dépôts globaux selon un calendrier, pas à la main.** Le Cargo moderne retire déjà les entrées inutilisées de son cache global pendant les commandes normales de build et de récupération, et npm décrit son cache comme autoréparateur avec `npm cache verify` comme commande de maintenance. Laissez ces politiques s’exécuter plutôt que de supprimer d’emblée les dossiers pointés du dossier personnel. [Vider les caches de développement](https://mole.fit/fr/blog/how-to-clear-dev-caches-mac) contient les commandes par outil. **Vérifiez si la CLI de votre agent élague ses propres versions, et supposez que non.** Au moment de la rédaction, je n’ai trouvé, ni dans Codex ni dans Claude Code, aucun drapeau documenté ni aucune clé de configuration qui élague les binaires de versions dépassées, et la demande sur Codex est toujours ouverte. Le `cleanupPeriodDays` de Claude Code balaie les données de session, pas les binaires de version, donc il n’aide pas ici. Tant que cela ne change pas, c’est une tâche récurrente, et c’est l’élément le plus rentable de la liste, parce qu’il revient au rythme où vos agents publient leurs mises à jour. ## FAQ ### Quelle quantité de disque les outils de code IA occupent-ils vraiment ? Les binaires font chacun quelques centaines de mégaoctets, mais c’est l’accumulation qui compte. Sur la machine mesurée pour cet article, quatre CLI d’agents totalisaient environ 3,5 Go dans leurs dossiers de versions, dont seulement 920 Mo actifs, les transcriptions de session atteignaient environ 14 Go, et un seul dossier `target/` Rust pesait 24 Go. Vos chiffres varieront davantage selon le langage que selon l’agent, donc lancez les deux commandes `du` en haut de cet article plutôt que de faire confiance au chiffre de qui que ce soit, y compris celui-ci. ### Est-il sûr de supprimer les anciennes versions de Claude Code ou de Codex ? Oui, tant que vous résolvez d’abord le lanceur. Lancez `readlink -f "$(command -v claude)"` ou l’équivalent pour votre CLI, gardez le chemin qu’il affiche, et mettez les versions sœurs à la Corbeille. Ne triez pas par date en gardant la plus récente, parce qu’un retour en arrière épinglé comme une mise à jour à moitié terminée font tous deux du dossier le plus récent le mauvais choix. Relancez la CLI une fois après la suppression et avant de vider la Corbeille. ### Un nettoyeur Mac va-t-il supprimer mon historique de chat d’agent ? Certains le feront, parce que ces fichiers ressemblent exactement à des logs. C’est le risque spécifique de cette catégorie. Mole ne touche jamais `~/.codex/sessions`, `~/.codex/archived_sessions`, `~/.codex/memories`, `~/.claude/projects` ni `~/.grok/sessions`, quel que soit leur âge. Avant de lancer un quelconque nettoyeur, vérifiez si ces chemins apparaissent dans sa liste de candidats, et si l’outil refuse de vous montrer la liste avant d’agir, voilà votre réponse. ### Vider les caches de build ralentit-il quoi que ce soit ? Le prochain build, une fois, et c’est tout. L’état de compilation incrémentale existe pour rendre le second build plus rapide que le premier, donc le supprimer vous coûte exactement un build à froid par projet. C’est tout l’inconvénient, et c’est pourquoi les sorties de build appartiennent au niveau « supprimer librement », alors qu’une arborescence `node_modules` qui a besoin d’un aller-retour vers le registre n’y appartient pas. ### Qu’en est-il des modèles Ollama et des caches Hugging Face ? Hors périmètre ici, et délibérément. Ces outils utilisent des dépôts adressés par contenu où deux modèles peuvent partager le même blob, donc supprimer des fichiers à la main peut orpheliner un modèle qui les référence encore. Utilisez la commande de suppression propre à chaque outil, couverte dans [retirer les résidus d’outils d’IA](https://mole.fit/fr/blog/how-to-remove-ai-tool-leftovers-mac). ## Pour aller plus loin Triez par coût de restauration, résolvez le lanceur avant de supprimer une version, laissez les transcriptions tranquilles. Si la plus grosse ligne de votre mesure était un registre de paquets, [vider les caches de développement](https://mole.fit/fr/blog/how-to-clear-dev-caches-mac) contient les commandes de purge par outil. Si c’était Xcode, [nettoyer le stockage Xcode](https://mole.fit/fr/blog/how-to-clean-up-xcode-mac) sépare les dossiers reconstructibles des archives à conserver. Si c’était un dépôt de modèles, [retirer les résidus d’outils d’IA](https://mole.fit/fr/blog/how-to-remove-ai-tool-leftovers-mac) explique pourquoi c’est à l’outil propriétaire de faire la suppression. --- Canonical HTML page: https://mole.fit/fr/blog/how-to-clean-up-ai-coding-tools-mac Blog index for agents: https://mole.fit/fr/blog/llms.txt Site index for agents: https://mole.fit/llms.txt