Limpar ferramentas de código com IA no Mac: caches, CLIs, transcrições

Um disco que ficou confortável por dois anos pode encher em poucos meses de uso diário de agentes de código. Os próprios agentes são pequenos. O que mudou é a frequência com que a máquina compila, a frequência com que um CLI se substitui no disco, e quanto do seu próprio raciocínio agora vive na pasta pessoal como texto. Quase todo o crescimento cai em três categorias, e elas precisam de três decisões diferentes, porque custam três quantias muito diferentes para voltar.

Pesos de modelo são o suspeito óbvio e, em geral, o errado para este problema específico. Ollama, LM Studio e Hugging Face mantêm lojas endereçadas por conteúdo que só as próprias ferramentas conseguem podar com segurança, e isso está coberto à parte em remover restos de ferramentas de IA. Este artigo é sobre o que os agentes de código com IA deixam para trás enquanto você trabalha.

Meça antes de apagar qualquer coisa

Dois comandos respondem a maior parte da pergunta. O primeiro totaliza as pastas pessoais dos agentes:

du -sh ~/.codex ~/.claude ~/.local/share/claude ~/.grok ~/.cache 2>/dev/null | sort -h

O segundo encontra saída de build espalhada por todo projeto que você já abriu. Substitua as raízes por onde você guarda 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 impede o find de descer num diretório que já casou, e isso importa aqui: sem ele, o find percorre cada arquivo dentro de um target/ de 24 GB antes de seguir. No Mac que medi enquanto escrevia isto, as duas primeiras linhas eram um target/ de Rust com 24 GB e o target/ de um projeto Tauri com 9,8 GB, contra árvores de node_modules que iam de 134 MB a 1,5 GB. Nesta amostra, a saída de build do Rust era muito maior do que qualquer um dos diretórios individuais de dependência listados.

Se você prefere ver isso como um mapa em vez de uma lista, a visualização Analisar do Mole desenha os mesmos volumes como um mapa em árvore e deixa você entrar no maior retângulo, o que é mais rápido do que adivinhar qual raiz passar ao find.

Categoria um: saída de build, amplificada

Esta categoria não é nova. O volume é. Um desenvolvedor trabalhando à mão compila algumas vezes por dia. Um agente trabalhando numa tarefa compila depois de quase toda edição, roda os testes, tenta uma segunda abordagem e compila de novo. Caches que cresciam ao longo de meses agora crescem numa tarde, e diretórios de build incremental são desenhados para trocar disco por velocidade.

Rust costuma ser o maior, com larga margem. Um diretório target/ guarda dependências compiladas, estado de compilação incremental e saída de scripts de build, mantidos separados por perfil, então debug e release são duas cópias completas. cargo clean sem opções "vai apagar o diretório target inteiro". Pré-visualize primeiro:

cargo clean --dry-run
cargo clean --release

cargo clean -p <package> limpa só os pacotes nomeados, que é a ferramenta certa quando um membro do workspace é o problema.

JavaScript espalha a saída mais fina. Além do próprio node_modules há node_modules/.cache (usado por bundlers e transpiladores), .next para builds do Next.js, e o que quer que dist ou build a sua cadeia de ferramentas escreva. Encontre os caches especificamente:

find ~/www -maxdepth 4 -type d -path '*/node_modules/.cache' -prune -exec du -sh {} + \
  2>/dev/null | sort -h | tail

Python deixa __pycache__ ao lado de cada pacote que importa. Individualmente minúsculos, e há milhares deles. Conte-os antes de remover, porque a mesma forma de comando com rm -rf no fim não perdoa se uma raiz estiver errada:

find ~/www -type d -name __pycache__ -prune -print | wc -l

Caches de bytecode se regeneram na próxima importação sem nenhum acesso à rede, então isto é a coisa mais segura de apagar em todo o artigo.

Go mantém um cache global de build, em vez de diretórios por projeto. go env GOCACHE imprime o local, e go clean -cache "faz o clean remover o cache de build do go inteiro". go clean -testcache expira resultados de teste em cache sem descartar pacotes compilados. Na minha máquina o cache de build tinha 183 MB contra um cache de módulos de 38 MB, então o lado do build vale conferir mesmo quando os módulos baixados são pequenos.

Xcode precisa de tratamento próprio, porque DerivedData, arquivos, suporte a dispositivos e runtimes de simulador são quatro tipos de coisa com quatro custos de restauração diferentes. A pasta DerivedData neste Mac mediu 9,3 GB. Limpar o armazenamento do Xcode cobre quais desses você pode apagar e quais guarda para simbolicação. Gradle e Maven se dividem do mesmo jeito entre diretórios build/ por projeto e uma loja global em ~/.gradle ou ~/.m2, e o lado global fica com os outros registros em limpar caches de desenvolvedor.

Categoria dois: versões de CLI substituídas

Esta é a que quase ninguém procura, e numa máquina que roda vários agentes ela costuma ser maior do que todos os caches juntos.

CLIs de agente se atualizam baixando uma versão nova completa e apontando um lançador para ela. Cada versão é autocontida, então não compartilha arquivos com a versão anterior. O ponteiro se move. A versão antiga fica. Nada a varre, então a contagem cresce em um a cada atualização, para sempre.

Os layouts seguem um padrão, com diferenças cosméticas:

• Codex guarda ~/.codex/packages/standalone/releases/<version>-<arch>/, com um link simbólico current um nível acima apontando para o que está vivo.
• Claude Code guarda ~/.local/share/claude/versions/<version>, em que cada entrada é um único arquivo executável, não um diretório, e ~/.local/bin/claude é um link simbólico para o que está vivo.
• Grok guarda ~/.grok/downloads/grok-<version>-macos-<arch> como arquivos, com ~/.grok/bin/grok e ~/.grok/bin/agent apontando para o build atual.
• Cursor Agent guarda ~/.local/share/cursor-agent/versions/<date>-<sha>/, com ~/.local/bin/cursor-agent como lançador.
• O Cursor, o app de desktop, também guarda a própria cópia do agente em ~/Library/Application Support/Cursor/User/globalStorage/anysphere.cursor-agent-worker/agent-cli/.local/share/cursor-agent/versions/, com bin/cursor-agent na mesma pasta .local como lançador. No Mac medido depois, ele tinha guardado sete versões, 4,1 GB.
• O GitHub Copilot CLI instalado pelo npm se substitui no lugar, mas o script de instalação escreve um pacote versionado sob um prefixo que, por padrão, é $HOME/.local para um usuário que não é root. O Mole confere ~/.copilot/pkg/universal para a mesma forma.

Meça todos de uma vez:

du -sh ~/.codex/packages/standalone/releases/* \
       ~/.local/share/claude/versions/* \
       ~/.grok/downloads/* \
       ~/.local/share/cursor-agent/versions/* 2>/dev/null

No Mac que usei para este artigo, isso imprimiu cinco versões do Codex entre 262 MB e 310 MB, cinco binários do Claude Code entre 293 MB e 306 MB, dois builds do Grok e duas versões do Cursor Agent. Cerca de 3,5 GB no total, dos quais cerca de 920 MB estavam vivos. Todo o resto era um binário que já tinha sido substituído. O próprio rastreador de issues do Codex tem um pedido aberto para isso, em que quem relata mede o crescimento em cerca de 250 MB por atualização (openai/codex#22293).

Resolva o lançador antes de apagar um único diretório

O atalho tentador é ordenar por data e manter o mais novo. Não faça isso. Duas situações comuns o quebram: você fixou uma versão mais antiga de propósito depois de uma regressão, ou uma atualização preparou o diretório novo antes de virar o ponteiro. Apagar a versão viva deixa você com um lançador apontando para o nada.

Pergunte ao lançador. Ele é um link simbólico, então resolva-o:

readlink -f "$(command -v codex)"
readlink -f "$(command -v claude)"
readlink -f "$(command -v grok)"

Isso imprime o alvo real, por exemplo ~/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin/bin/codex, e ls -l "$(command -v codex)" mostra cada salto em vez da resposta final. O que voltar identifica a versão desse lançador. Antes de enviar um irmão ao Lixo, confira que nenhum outro processo, atualização ou instalação o usa. Mantenha itens incertos e teste o CLI antes de esvaziar o Lixo.

Categoria três: estado de trabalho do agente, que não é lixo

A terceira categoria é aquela em que um limpador pode causar dano real, porque ela parece exatamente as duas primeiras.

Transcrições de sessão, memórias, planos e anexos gerados vivem em ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects e ~/.grok/sessions. São arquivos JSONL nomeados pelo id da sessão, com carimbo de data, só de acréscimo, e nunca param de crescer. Toda heurística de um limpador genérico diz arquivo de log. No Mac que medi, ~/.codex/sessions tinha 9,8 GB, ~/.claude/projects tinha 2,7 GB em 2.362 arquivos de transcrição, e ~/.grok/sessions tinha 1,3 GB: um número grande e tentador, preso a arquivos que parecem descartáveis.

Não são logs. Uma transcrição é o registro de como se chegou a uma mudança: as abordagens tentadas e rejeitadas, a restrição que descartou uma, o motivo de a forma final ser o que é. Esse raciocínio não existe em nenhum outro lugar. A mensagem de commit registra o que mudou, o código registra a opção que sobreviveu e não as quatro descartadas. Meses disso se acumulam em silêncio, e você descobre o valor na primeira vez que volta para perguntar por que algo foi construído daquele jeito.

O risco maior não é um limpador de terceiros. O Claude Code traz a própria varredura de retenção: cleanupPeriodDays vem em 30 dias por padrão, e na inicialização ele apaga transcrições em projects/, arquivos de plano, snapshots de pré-edição em file-history/ e listas de tarefas por sessão mais antigas do que isso. A referência do diretório .claude documenta exatamente quais caminhos são varridos e quais são mantidos por tempo indefinido. Se você quer um ano de transcrições, aumente esse número agora, em vez de descobrir o padrão depois do fato. A mesma página documenta claude project purge para o caso oposto, quando você quer o estado de um projeto sumindo de propósito.

A análise Limpar do Mole nunca toca nada disso. Esses cinco caminhos, mais ~/.claude/file-history, ~/.claude/plans, ~/.claude/tasks, ~/.codex/attachments e ~/.codex/generated_images, estão na lista de proteção em qualquer idade. Não há portão de idade, nem exceção de "mais de 90 dias", nem ajuste para ligar uma. Uma exceção por idade foi construída para esses caminhos uma vez e revertida no mesmo dia, porque uma transcrição antiga não é uma transcrição velha no sentido de descartável.

Sessões antigas têm um caminho separado, que você percorre. A lua distante na página Limpar abre Limpeza e cuidados de IA, que mantém uma janela de retenção para cada ferramenta e lista as sessões do Codex e do Claude Code além dela, mais sessões do Claude Code cuja pasta de projeto sumiu, cada uma com título e data, e nada é removido até você marcar. Uma sessão do Codex é copiada para o Lixo primeiro e depois removida pelo próprio comando do Codex, para o índice dele permanecer inteiro, e as imagens e notas que o Codex renderizou para ela vão para o Lixo junto. Uma sessão usada nas últimas 24 horas nunca aparece na lista, então você pode limpar com o Codex e o Claude Code abertos, e memórias, planos e skills também não estão em nenhuma lista ali.

Por baixo: ordene pelo custo de restauração, não pelo tamanho

Esta é a regra que torna as três categorias decidíveis, e é a única coisa neste artigo que vale memorizar. Ordene cada candidato pelo que custa para voltar, não por quantos gigabytes ele mostra.

Regenerável localmente. Saída de build, estado de compilação incremental, caches de bytecode, DerivedData. O custo de apagar isso são minutos de CPU numa máquina em que você já está sentado, sem rede envolvida quando as fontes e dependências necessárias permanecem. Pare builds ativos e verifique que a saída selecionada pode ser recriada antes de apagá-la.

Caro de reconstruir. Registros de pacotes, node_modules, CocoaPods, ambientes virtuais de Python, diretórios vendor, pesos de modelo, iOS DeviceSupport. Recriar isso pode exigir acesso à rede, os downloads originais ou as versões dos pacotes, e uma cadeia de ferramentas compatível. O custo real não é só minutos numa conexão boa; é se você consegue trabalhar num trem. Revise um de cada vez.

Insubstituível. Transcrições de chat, memórias de agente, arquivos de plano, estado de projeto, ajustes finos locais. Nenhuma quantidade de CPU ou banda traz isso de volta. Nunca pertencem a uma exclusão em lote, e não deveriam ser o tipo de coisa que você seleciona por acidente.

A armadilha é que o primeiro e o segundo nível parecem idênticos. target/ e node_modules/ são ambos diretórios grandes na raiz de um projeto, ambos cheios de artefatos de dependência, ambos listados no .gitignore, ambos regenerados por um único comando. Ordenados por tamanho, ficam um ao lado do outro. cargo build pode recriar target/ localmente quando as fontes, as dependências e a cadeia de ferramentas necessárias estão disponíveis. npm ci pode precisar de downloads do registro, além de um lockfile válido. Qualquer um pode levar um tempo substancial, dependendo do projeto; uma dependência indisponível pode interromper a reconstrução por completo. Tratar os custos de recuperação como idênticos é um erro, e é por isso que "apague as pastas maiores" é um mau conselho mesmo quando libera mais espaço.

Fazendo isso no Mole

O caminho manual funciona e não custa nada. O que o Mole acrescenta é que as três categorias chegam numa lista revisada, com o limite de nível já aplicado, então você não é quem precisa lembrar qual diretório de ponto guarda transcrições.

Abra a ferramenta Limpar e rode uma análise. A análise é grátis e não precisa de licença. Cada candidato chega com o caminho exato, o dono e o tamanho medido, e nada se move até você aprovar a lista. Qualquer coisa de baixa confiança chega desmarcada, então a ação padrão é sempre a menor. Caches são apagados de forma permanente por padrão. Você pode escolher o Lixo nos Ajustes e restaurar arquivos enquanto eles permanecerem lá. Resultados em lote também informam itens ignorados e com falha.

Para as versões de CLI substituídas, especificamente, o Mole faz a resolução do lançador descrita acima por você. Ele lê o link simbólico do lançador de cada CLI de agente, resolve-o até a versão viva e exclui essa versão do conjunto de candidatos, então um downgrade deliberado permanece intacto em vez de ser tratado como versão antiga. O caso medido por trás desse comportamento é o Codex: cinco versões em 1,2 GB, com só uma viva. A própria cópia do Cursor dentro do app de desktop é tratada do mesmo jeito, e uma versão antiga pode sair enquanto o Cursor está aberto, desde que nenhum processo a tenha aberta.

O Mole CLI é grátis, de código aberto, e cobre o mesmo trabalho a partir de um shell com mo clean; comandos como clean, uninstall e optimize aceitam --dry-run para pré-visualizar as ações. Os dois compartilham a lista de exclusão editável pelo usuário em ~/.config/mole/whitelist e um log de operações em ~/Library/Logs/mole/operations.log, e tudo roda localmente, sem envio e sem telemetria.

Vale dizer com clareza: o Mole não é um backup, não é resposta a malware e não substitui um desinstalador do fornecedor em software que traz drivers ou extensões de sistema. Ele nunca apaga arquivos de modelo por conta própria, e a limpeza comum nunca toca histórico de chat de IA: sessões antigas e modelos do Ollama sem uso por um mês só saem de Limpeza e cuidados de IA, uma caixa de cada vez, e o próprio comando do Ollama remove os modelos. Outros modelos ficam com as ferramentas que são donas deles.

Impedir que volte

Três mudanças de configuração cobrem a maior parte do recrescimento.

Aponte o Rust para um diretório de build. CARGO_TARGET_DIR define o "local onde colocar todos os artefatos gerados", então cada projeto escreve numa árvore que você pode medir e limpar num único lugar. A troca é real: o Cargo trava o diretório de build, então dois projetos compartilhando um target dir compilam um de cada vez, em vez de em paralelo. Se você roda builds simultâneos de rotina, mantenha-os separados e agende uma varredura.

Pode as lojas globais numa agenda, não à mão. O Cargo moderno já remove entradas sem uso do cache global durante comandos normais de build e fetch, e o npm descreve o cache como autorreparável, com npm cache verify como comando de manutenção. Deixe essas políticas rodarem, em vez de apagar pastas de ponto da pasta pessoal de uma vez. Limpar caches de desenvolvedor tem os comandos por ferramenta.

Confira se o CLI do seu agente poda as próprias versões, e presuma que não. No momento desta escrita eu não encontrei uma flag documentada nem uma chave de configuração no Codex ou no Claude Code que pode binários de versão substituídos, e o pedido do Codex continua aberto. O cleanupPeriodDays do Claude Code varre dados de sessão, não binários de versão, então não ajuda aqui. Até isso mudar, este é um trabalho recorrente, e é o item de maior valor na lista porque volta no ritmo em que os seus agentes publicam atualizações.

Perguntas frequentes

Quanto disco as ferramentas de código com IA realmente usam?

Os binários têm algumas centenas de megabytes cada, mas o acúmulo é o que importa. Na máquina medida para este artigo, quatro CLIs de agente guardavam cerca de 3,5 GB nos diretórios de versão, com só 920 MB disso vivos, as transcrições de sessão somavam cerca de 14 GB, e um único diretório target/ de Rust tinha 24 GB. Os seus números vão diferir mais pela linguagem do que pelo agente, então rode os dois comandos du no topo deste artigo em vez de confiar na cifra de alguém, inclusive nesta.

É seguro apagar versões antigas do Claude Code ou do Codex?

Sim, desde que você resolva o lançador primeiro. Rode readlink -f "$(command -v claude)" ou o equivalente do seu CLI, e mantenha o alvo impresso. Confira que nenhum outro processo, atualização ou instalação precisa de um irmão antes de enviá-lo ao Lixo. Ordenar por data não é confiável: um downgrade fixado ou uma atualização incompleta pode tornar o diretório mais novo o errado. Rode o CLI uma vez depois de apagar e antes de esvaziar o Lixo.

Um limpador de Mac vai apagar o histórico de chat do meu agente?

Alguns vão, porque esses arquivos parecem exatamente logs. Esse é o risco específico desta categoria. A limpeza comum do Mole nunca toca ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects nem ~/.grok/sessions em nenhuma idade. Antes de rodar qualquer limpador, confira se esses caminhos aparecem na lista de candidatos, e se a ferramenta não mostra a lista antes de agir, essa é a sua resposta. A página separada Limpeza e cuidados de IA pode listar sessões do Codex e do Claude Code além da janela de retenção de cada ferramenta, mais sessões do Claude Code cujo projeto sumiu, desmarcadas para revisão individual.

Limpar caches de build deixa alguma coisa mais lenta?

Espere um primeiro build mais lento enquanto o cache é reconstruído. A compilação incremental ajuda a tornar o build seguinte mais rápido, mas o tempo de recuperação depende da cadeia de ferramentas e do projeto. Pare builds ativos e mantenha as fontes e dependências necessárias para regenerar a saída antes de apagá-la. Recriar node_modules também pode exigir acesso ao registro de pacotes.

E os modelos do Ollama e os caches do Hugging Face?

Fora do escopo aqui, e de propósito. Essas ferramentas usam lojas endereçadas por conteúdo em que dois modelos podem compartilhar o mesmo blob, então apagar arquivos à mão pode deixar órfão um modelo que ainda os referencia. Use o comando de remoção de cada ferramenta, coberto em remover restos de ferramentas de IA. Modelos do Ollama são a única exceção que o Mole trata: Limpeza e cuidados de IA lista os sem uso por um mês e remove os que você marca com o próprio ollama rm do Ollama, então blobs que outro modelo ainda usa permanecem.

Para onde ir depois

Ordene pelo custo de restauração, resolva o lançador antes de apagar uma versão, deixe as transcrições em paz. Se a maior linha da sua medição foi uma loja de pacotes, limpar caches de desenvolvedor tem os comandos de poda por ferramenta. Se foi o Xcode, limpar o armazenamento do Xcode separa as pastas recriáveis dos arquivos que você guarda. Se foi uma loja de modelos, remover restos de ferramentas de IA explica por que a ferramenta dona é quem tem de apagar. Se você está removendo um app de desktop de uma vez, os guias para desinstalar o Claude e desinstalar o Cursor mantêm o ~/.claude do Claude Code e o CLI do Cursor Agent, que se instala separado, fora da remoção.