Comment nettoyer après les outils de code IA sur Mac

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. 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 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 <package> 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 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.

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/<version>-<arch>/, avec un lien symbolique current un niveau au-dessus pointant vers la version active.
• Claude Code conserve ~/.local/share/claude/versions/<version>, 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-<version>-macos-<arch> 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/<date>-<sha>/, 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).

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.

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 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 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.

Faire tout ça dans Mole

La méthode manuelle fonctionne et ne coûte rien. Ce qu’ajoute Mole, 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 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.

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 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.

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 contient les commandes de purge par outil. Si c’était Xcode, nettoyer le stockage Xcode 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 explique pourquoi c’est à l’outil propriétaire de faire la suppression.