Agentes de IA de código lotando o disco do Mac: onde olhar

Por que os agentes usam tanto disco

Um agente trabalha como trabalharia um desenvolvedor rápido e incansável. Ele faz checkout do código, instala dependências, compila, roda os testes e começa de novo. Muitas ferramentas dão a cada tarefa seu próprio worktree do git, para que várias possam rodar ao mesmo tempo sem mexer nos arquivos umas das outras.

Cada worktree é uma cópia de trabalho completa. Cada um recebe seu próprio node_modules, ambiente virtual ou pasta de compilação, e nada os remove quando a tarefa termina. Vinte tarefas concluídas podem significar vinte cópias das dependências do seu projeto.

Encontre e remova os worktrees que sobraram

Em um repositório, o primeiro comando abaixo lista todos os worktrees que o git conhece, com o caminho e o branch de cada um. Ele apenas lê. Execute-o em cada repositório em que você usa agentes.

Antes de remover um, confira se o trabalho dele está a salvo. Abra a pasta e execute git status. Se o branch recebeu merge ou push e não há alterações sem commit, nada se perde ao removê-lo.

O segundo comando remove a pasta de um worktree. O git se recusa se o worktree tiver alterações sem commit ou arquivos não rastreados, e essa é a proteção que você quer, então não adicione --force sem ter olhado antes. O terceiro apenas limpa os registros do git sobre worktrees cujas pastas já não existem. Remover um worktree não apaga o branch dele.

git worktree list
git worktree remove path/to/worktree
git worktree prune

Logs de sessão e dados de agentes na sua pasta pessoal

Os agentes e suas ferramentas de linha de comando guardam transcrições, histórico, snapshots de arquivos editados e ferramentas baixadas em pastas ocultas da sua pasta pessoal, como ~/.claude, ~/.codex e ~/.cursor. Os editores baseados no VS Code guardam mais coisas em ~/Library/Application Support.

O comando abaixo lista as pastas ocultas da sua pasta pessoal por tamanho, com as maiores por último. Ele apenas lê.

Essas pastas misturam dois tipos de dados. Os logs e as transcrições são histórico: apagar os antigos custa a possibilidade de retomar essas sessões ou pesquisar nelas. Os ajustes, as credenciais e os arquivos de memória são configuração: apagá-los significa configurar a ferramenta de novo. Limpe as sessões antigas pelos ajustes ou comandos da própria ferramenta, quando ela os oferece, e não apague a pasta inteira.

du -sh ~/.??* 2>/dev/null | sort -h | tail -15

Dependências e saída de compilação, multiplicadas

Depois de remover os worktrees de que você não precisa mais, o resto do espaço normalmente está em pastas de projetos que continuam ali. Os agentes muitas vezes clonam repositórios em pastas temporárias ou de rascunho e os deixam lá.

O comando abaixo encontra as pastas node_modules dentro da sua pasta de código e as ordena por tamanho. Ele apenas lê. Troque ~/Projects pelo lugar em que seu código e seus worktrees ficam. Os ambientes virtuais do Python, normalmente chamados .venv, e as pastas de compilação como .build, target e dist seguem o mesmo padrão.

Qualquer uma delas pode ser apagada em um projeto que não está em uso. O comando de instalação ou de compilação as recria.

find ~/Projects -type d -name node_modules -prune -exec du -sh {} + 2>/dev/null | sort -h

Os caches de pacotes também crescem mais rápido

Cada instalação que um agente executa aumenta o cache de download do gerenciador de pacotes, e os agentes instalam com muito mais frequência do que as pessoas. As ferramentas de teste acrescentam os seus: o Playwright, por exemplo, baixa versões completas de navegadores em ~/Library/Caches/ms-playwright.

É seguro limpar esses caches com o comando próprio de cada ferramenta, como npm cache clean --force, pnpm store prune, uv cache clean ou brew cleanup. Cada um remove apenas downloads, e o custo é que a próxima instalação os busca de novo.

Modelos locais

Se você roda modelos no Mac, eles provavelmente são os maiores itens individuais do disco. Um modelo muitas vezes tem vários GB, e testar alguns soma rápido.

• O Ollama guarda os modelos em ~/.ollama/models. O primeiro comando abaixo os lista com os tamanhos, e ollama rm seguido do nome de um modelo remove um deles.
• As bibliotecas do Hugging Face guardam modelos e datasets em cache em ~/.cache/huggingface/hub. O segundo comando os lista por tamanho.
• O LM Studio guarda seus downloads em sua própria pasta de modelos, que você pode abrir e gerenciar pelo app.
• Remover um modelo não perde nada de permanente, mas ele precisa ser baixado de novo se você o quiser de volta.

ollama list
du -sh ~/.cache/huggingface/hub/* 2>/dev/null | sort -h

Contêineres e sandboxes

Alguns agentes executam código dentro de contêineres do Docker. Cada imagem e cada contêiner parado ficam dentro da imagem de disco do Docker, que cresce e não diminui sozinha.

O primeiro comando abaixo mostra o que o Docker está guardando. Ele apenas lê. O segundo remove os contêineres parados, as redes sem uso, as imagens órfãs (dangling) e o cache de compilação sem uso. Ele não remove volumes nem imagens que algum contêiner ainda usa. Tudo o que está guardado apenas dentro de um contêiner parado se perde, então confira antes de executá-lo.

docker system df
docker system prune

Onde o Diskzy entra

O Diskzy mapeia o disco inteiro e se mantém atualizado conforme os arquivos mudam, o que combina com este problema: você vê qual pasta está crescendo enquanto os agentes rodam. A visão System Data, explained (Dados do Sistema, explicados) mostra os dados de desenvolvimento e os modelos de IA como partes próprias, com nome e tamanho.

A aba Clean up (Limpeza) encontra as pastas de compilação de projetos, como node_modules, .build, Pods e ambientes virtuais, onde quer que estejam, e deixa uma pasta desmarcada se o projeto dela mudou nos últimos 14 dias. Os caches de gerenciadores de pacotes vêm marcados. Os modelos do Ollama, do Hugging Face e do LM Studio aparecem na lista, mas desmarcados, porque teriam de ser baixados de novo. Tudo o que é removido vai para o Lixo.