# Limpar ferramentas de código com IA no Mac: caches, CLIs, transcrições > Meça saída de build, instalações antigas de CLI e transcrições de chat separadamente, e revise o que ainda está em uso antes de apagar. Published: 2026-08-21 | Updated: 2026-10-18 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](https://mole.fit/pt-br/blog/how-to-remove-ai-tool-leftovers-mac). 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](https://mole.fit/) 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 ` 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](https://mole.fit/pt-br/blog/how-to-clean-up-xcode-mac) 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](https://mole.fit/pt-br/blog/how-to-clear-dev-caches-mac). ## 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/-/`, com um link simbólico `current` um nível acima apontando para o que está vivo. - **Claude Code** guarda `~/.local/share/claude/versions/`, 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--macos-` como arquivos, com `~/.grok/bin/grok` e `~/.grok/bin/agent` apontando para o build atual. - **Cursor Agent** guarda `~/.local/share/cursor-agent/versions/-/`, 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](https://github.com/openai/codex/issues/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.
Um link simbólico de lançador no PATH resolvendo, por um ponteiro current, até um diretório de versão. Os outros diretórios de versão precisam de conferências separadas de uso ativo antes da remoção.
O lançador, não o carimbo de data, é o que identifica a versão viva. Um downgrade fixado ou uma atualização pela metade tornam o diretório mais novo a resposta errada.
## 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](https://code.claude.com/docs/en/claude-directory) 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](https://mole.fit/) 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.
Três níveis ordenados pelo custo de restauração, com target e node_modules mostrados como diretórios de projeto visualmente idênticos que caem em níveis diferentes porque um reconstrói a partir da fonte local e o outro precisa de um registro.
O tamanho ordena os candidatos na ordem errada. Dois diretórios que parecem iguais na raiz de um projeto podem diferir por um dia inteiro de trabalho no que custa restaurá-los.
## Fazendo isso no Mole O caminho manual funciona e não custa nada. O que o [Mole](https://mole.fit/) 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](https://github.com/tw93/Mole) é 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.
A revisão Limpar do Mole listando categorias de cache com os tamanhos, cada uma com uma caixa de seleção, e um botão de limpeza permanente para os 5,14 GB selecionados.
Descoberta e remoção são dois passos separados. A revisão lista o que a análise encontrou por categoria, e nada é removido até você confirmar.
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](https://mole.fit/pt-br/blog/how-to-clear-dev-caches-mac) 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](https://mole.fit/pt-br/blog/how-to-remove-ai-tool-leftovers-mac). 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](https://mole.fit/pt-br/blog/how-to-clear-dev-caches-mac) tem os comandos de poda por ferramenta. Se foi o Xcode, [limpar o armazenamento do Xcode](https://mole.fit/pt-br/blog/how-to-clean-up-xcode-mac) separa as pastas recriáveis dos arquivos que você guarda. Se foi uma loja de modelos, [remover restos de ferramentas de IA](https://mole.fit/pt-br/blog/how-to-remove-ai-tool-leftovers-mac) 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](https://mole.fit/tested-apps/claude) e [desinstalar o Cursor](https://mole.fit/tested-apps/cursor) mantêm o `~/.claude` do Claude Code e o CLI do Cursor Agent, que se instala separado, fora da remoção. --- Canonical HTML page: https://mole.fit/pt-br/blog/how-to-clean-up-ai-coding-tools-mac Blog index for agents: https://mole.fit/pt-br/blog/llms.txt Site index for agents: https://mole.fit/llms.txt