# O Mole é seguro no Mac? O que ele apaga e o que não toca

> O que o Mole apaga, o que se recusa a tocar, para onde os arquivos vão depois da exclusão e como as respostas do app de Mac e da CLI diferem.

Published: 2026-08-17 | Updated: 2026-10-18

O Mole sai como dois programas, e a maioria das respostas de segurança que você encontra online descreve só
um deles. O Mole para Mac é o app nativo vendido em mole.fit. `mo` é a ferramenta de linha de
comando gratuita e de código aberto no GitHub. Eles compartilham a lista de exclusões do usuário e o local do registro, mas não
se comportam do mesmo jeito no momento da exclusão, e essa diferença é a resposta
inteira para o Mole ser seguro no uso que você planeja.

Nesta página, “Mole” vale só para o Mole para Mac em mole.fit e para a ferramenta de linha de comando `mo` dele.
Outros apps ou ferramentas de linha de comando chamados “mole” são produtos sem relação e não entram
nesta descrição de segurança.

O app de Mac mostra a lista completa de candidatos antes da exclusão. A desinstalação de apps usa o Lixo. A limpeza de cache é permanente por padrão, com uma opção de Lixo nos Ajustes. A CLI apaga caches de forma permanente e oferece `--dry-run` para pré-visualizar, não para desfazer. As duas recusam caminhos protegidos.

## Onde cada exclusão termina

| Operação | App de Mac | CLI | Recuperável depois |
|---|---|---|---|
| Limpeza de cache | Permanente por padrão; Lixo opcional nos Ajustes | Permanente | Só se foi para o Lixo e ainda está lá |
| Desinstalação de apps e resíduos | Lixo | Lixo | Até você esvaziar o Lixo |
| Remoção de item de início (plist do usuário) | Lixo | Lixo | Até você esvaziar o Lixo |
| Manutenção do Otimizar | Direta, só um conjunto nomeado | Direta | Sem desfazer; regenerar não é restaurar |
| Varredura de artefatos de build (`mo purge`) | Subconjunto reconstruível localmente; segue a Remoção de cache | Permanente | Reconstrua ou reinstale dependências; a rede pode ser necessária |
| O próprio Lixo | Permanente por definição | Permanente | Não |

Duas linhas merecem o detalhe. O Otimizar remove um conjunto pequeno e nomeado de itens gerenciados pelo sistema
direto, em vez de para o Lixo: estado salvo do aplicativo, registros de eventos dentro do
banco de quarentena, journals write-ahead antigos, property lists de LaunchAgent do usuário cujo
programa não existe mais, e arquivos `.sfl` vazios. Cada um passa pelo próprio predicado de
idade, tamanho ou existência. Não há como desfazer, e qualquer dado regenerado depois não é uma
restauração do conteúdo original. O app oferece só um subconjunto de artefatos de projeto reconstruível localmente. O escopo mais amplo do `mo purge` é o assunto do segundo diagrama abaixo.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/deletion-gates.webp" width="1360" height="454" loading="lazy" alt="Um candidato à exclusão passa pela trava de licença e pela validação de caminho antes de o executor aplicar o modo de exclusão: Lixo, recuperável enquanto o arquivo permanece lá, ou exclusão direta para caches por padrão e itens de manutenção nomeados.">
  <figcaption>Todo candidato passa pelas mesmas três travas, e cada uma decide de novo, por conta própria. Uma recusa na trava do meio é uma parada dura, não uma exclusão menor.</figcaption>
</figure>

## As três travas, e por que a do meio é a parte interessante

Um candidato não vai da varredura ao disco num passo só. Ele passa por uma trava de
licença, depois pela validação de caminho, depois por um executor, e as camadas não confiam umas nas outras:
cada uma confere de novo, em vez de supor que a anterior estava certa.

A validação de caminho é onde a segurança de fato mora. Ela roda **no momento da exclusão, não
na hora da varredura**, o que importa porque os dois momentos podem estar a minutos de distância e o disco
não fica parado no meio. Se o arquivo mudou de identidade depois que você o viu, a
exclusão não segue com a força de uma decisão velha. Uma linha real do registro
na máquina em que este texto foi escrito:

```
2026-08-17T02:13:55Z	uninstall	SKIPPED	/Applications/Quiet.app	updated since the scan, please scan again
```

Essa é a forma do modelo de segurança inteiro numa linha: quando a resposta é incerta,
o Mole recusa e diz por quê, em vez de apagar algo parecido o bastante.

A outra propriedade dessa trava é que uma recusa é **total**. Um caminho que cai na
lista protegida é recusado, não aparado até uma exclusão menor dentro dele, e a
operação para ali, em vez de continuar com o resto daquele item.

## O que o Mole se recusa a apagar

Um limpador só é confiável na medida do que ele não faz, então esta lista é específica,
não uma promessa de ter cuidado. Isto é recusado antes de qualquer exclusão rodar:

| Recusado | Por que está na lista |
|---|---|
| `/System`, `/usr`, `/bin`, `/sbin` | Sistema operacional, não dados do usuário |
| `/private/var/folders` | Raiz protegida; folhas de cache de app verificadas de forma estreita podem ser removidas na desinstalação |
| `/Library/Audio/Plug-Ins/{Components,VST,VST3}` | Sustentam o sistema no momento em que um projeto os referencia |
| Diretórios de suporte da iZotope e da LaserSoft | Ferramentas de áudio e de scanner licenciadas que parecem dados de suporte inertes |
| `~/.ollama/models`, `~/.lmstudio/models` | Pesos baixados, muitas vezes dezenas de gigabytes |
| `~/.cache/huggingface`, `~/.cache/torch`, `~/.cache/whisper` | Caminhos com forma de cache que guardam downloads, não arquivos derivados |
| `~/.cache/tensorflow`, `~/.cache/wandb` | Conjuntos de dados e registros locais de execução que podem ainda não ter sido enviados |
| `~/.cache/pypoetry/virtualenvs` | Interpretadores vivos; os filhos reconstruíveis do Poetry continuam limpáveis |
| Armazenamento de modelos compilados do Apple Neural Engine | Removê-lo quebra o reconhecimento até a próxima reinicialização |
| Ajustes do Sistema, Central de Controle, serviços de áudio | Configuração do sistema, não cache |
| Banco de privacidade, itens de início, registros de tarefas em segundo plano | Estado de permissão e de inicialização |
| Listas de arquivos compartilhados por trás dos menus de itens recentes | Pequenas, invisíveis e irritantes de perder |
| `~/.config/mole` | Para uma limpeza não apagar a lista de exclusões que limita a próxima |

O padrão por trás da lista é que um caminho com forma de cache não é evidência de que
ele guarda um. Pesos de modelo e ambientes Python ficam em `~/.cache` porque é
onde as ferramentas colocam as coisas, não porque sejam arquivos derivados que qualquer um regenera
de graça.

A lista de exclusões é a metade controlada pelo usuário da mesma ideia. Um caminho que você protege em qualquer
um dos programas é honrado pelos dois, porque os dois leem `~/.config/mole/whitelist`.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/same-or-safer-review.webp" width="1360" height="454" loading="lazy" alt="Três conjuntos aninhados: tudo no disco, o conjunto menor que a ferramenta de linha de comando remove, e o conjunto menor ainda que o app de Mac oferece, com a diferença rotulada como diretórios que precisam da rede para voltar.">
  <figcaption>Igual ou mais seguro, nunca mais amplo. O app de Mac deixa de propósito o que só a rede consegue restaurar, e por isso uma categoria pode existir no terminal e nunca aparecer no app.</figcaption>
</figure>

## O app de Mac é mais estreito que a CLI, numa direção consistente

Os dois não são igualmente agressivos, e a assimetria sempre corre do mesmo jeito. O
caso mais claro são os diretórios de dependência: `mo purge` remove `node_modules`, `Pods`,
`venv` e `vendor`, enquanto o app deixa todos eles de fora e oferece só o que uma compilação
local reconstrói sem a rede. O app também condiciona as varreduras de dados de app ao Acesso
Total ao Disco, mostra itens recuperáveis porém caros como linhas só de revisão, não
pré-selecionadas, e revalida os caminhos na hora da exclusão, como descrito acima.

Então ver uma categoria em `mo clean` que o app nunca oferece é o comportamento esperado, não um
recurso faltando. Se você quer a varredura mais ampla, ela mora no terminal, e
`--dry-run` é como olhar antes de acontecer.

## Ler o que de fato aconteceu

Os dois programas usam `~/Library/Logs/mole/operations.log`. O app grava campos separados por
tabulação. A CLI coloca o carimbo de tempo e o comando entre colchetes, seguidos do status,
do caminho e de qualquer detalhe. Os nomes de status também diferem:

| Status | O que significa |
|---|---|
| `TRASHED` | Movido para o Lixo naquele momento |
| `DELETED` | Removido de forma permanente |
| `REMOVED` | Remoção permanente da CLI |
| `SKIPPED` | Recusado, com o motivo no campo seguinte |
| `SKIPPED_RUNNING` | O app dono estava em execução |
| `SKIPPED_MISSING` | O caminho já tinha sumido quando o executor chegou |
| `SKIPPED_ACTIVE_UPDATE` | Uma atualização daquele app estava em andamento |
| `FAILED` | Tentou e não conseguiu |

Esses registros descrevem o que aconteceu, não onde um arquivo está agora. Um arquivo `TRASHED`
em geral pode ser restaurado enquanto permanece no Lixo, mas pode ter sido restaurado,
movido ou esvaziado desde então. Confira o próprio Lixo antes de contar com a recuperação.

## O passo de revisão

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/mole-clean-review.webp" width="2584" height="1741" loading="lazy" alt="A revisão de Limpar do Mole listando categorias de cache com os tamanhos, cada uma com uma caixa de seleção, e um botão Limpar permanentemente para os 5,14 GB selecionados.">
  <figcaption>A varredura em si não apaga nada. A revisão mostra cada categoria com o tamanho, e só as linhas marcadas são limpas.</figcaption>
</figure>

Varredura é gratuita no app de Mac, sem licença e sem limite de tempo. Toda ferramenta
varre e mostra a lista completa de resultados. A licença só é exigida para agir sobre ela, e cada
ferramenta destrutiva roda duas vezes antes de pedir. Você pode comparar o que o Mole propõe com
o que você acredita sobre o próprio disco antes de pagar qualquer coisa.

A desinstalação mostra um plano com caminhos, donos e tamanhos antes de qualquer coisa se mover. A revisão é
o produto, não um diálogo de confirmação: um item que você não consegue avaliar é um mau candidato
para uma varredura de um clique, e por isso o Mole deixa desmarcados os que são caros de restaurar,
em vez de esconder a decisão atrás de um total.

## O que de fato não é recuperável

Ser específico nisto importa mais do que tranquilizar.

A limpeza de cache é permanente por padrão nos dois programas. No app de Mac, você pode mudar o ajuste para mover caches para o Lixo, onde eles continuam recuperáveis até serem esvaziados. Regenerar um cache não restaura o conteúdo original.

`mo purge` apaga a saída de build de forma permanente, e por isso é o comando que mais
merece um dry run primeiro. As exclusões do Otimizar listadas acima são imediatas. Nenhuma
delas restaura o conteúdo original sem um backup. O Time Machine ou outro backup
é o caminho de recuperação quando você apagou a coisa errada. Reconstruir um cache ou um projeto
não restaura os próprios arquivos apagados.

## Como verificar qualquer parte disto você mesmo

- **Leia o registro.** `~/Library/Logs/mole/operations.log`, gravado por qualquer frente
  que fez o trabalho, com o vocabulário de status acima.
- **Pré-visualize ações do terminal.** Os comandos clean, uninstall e optimize aceitam `--dry-run` e
  mostram as ações planejadas sem executá-las.
- **Leia o código.** A CLI é código aberto sob GPL-3.0, lógica de exclusão incluída.
- **Confira a build que você baixou.** O app de Mac é assinado com um Developer ID e
  notarizado, então `spctl -a -t exec -vv /Applications/Mole.app` responde se a cópia no
  seu disco passa pela avaliação do Gatekeeper, não se os bytes batem com um download publicado.
- **Observe a rede.** Nenhum dos dois programas envia telemetria.

## Afirmações que você pode ler em outro lugar

Três descrições circulam bastante, e as três vêm de ler a ferramenta de terminal
e o app como um produto só.

**“É um utilitário de terminal sem pré-visualização e sem desfazer.”** `mo clean` tem pré-visualização com `--dry-run`, mas a exclusão de cache é permanente. O app de Mac oferece uma revisão gráfica. A desinstalação usa o Lixo, enquanto a limpeza de cache é permanente por padrão e pode ser mudada nos Ajustes.

**“O Mole é gratuito.”** A CLI é gratuita e de código aberto. O Mole para Mac é uma compra única de US$19
que cobre dois Macs, com atualizações gratuitas e reembolso de 14 dias.

**“A CLI tem licença MIT.”** Ela é GPL-3.0.

## Leitura adicional

- [Mole CLI ou Mole para Mac](https://mole.fit/blog/mole-cli-vs-mac-app): o que cada frente
  faz que a outra não faz, e o que acontece quando você instala as duas.
- [O que limpadores de Mac nunca deveriam apagar](https://mole.fit/blog/what-mac-cleaners-should-never-delete):
  a mesma pergunta feita à categoria inteira, não a uma ferramenta.

## Perguntas frequentes

### O Mole move arquivos apagados para o Lixo?

No app de Mac, a limpeza de cache é permanente por padrão. Os Ajustes oferecem uma opção de Lixo. A desinstalação de apps e as exclusões da Análise usam o Lixo, inclusive remoções que exigem direitos de administrador. A recuperação exige que os arquivos ainda estejam lá. Esvaziar o Lixo e as exclusões nomeadas do Otimizar são permanentes. Regenerar não é restaurar. A CLI apaga caches de forma permanente e move apps desinstalados e resíduos para o Lixo.

### O Mole pode apagar algo de que o macOS precisa?

Raízes do sistema, estado protegido do sistema como bancos de privacidade e de itens de início, plug-ins
de áudio, pesos de modelo baixados e ambientes Python vivos são recusados antes de qualquer
exclusão rodar. O app também revalida cada caminho no momento da exclusão, em vez de
confiar na varredura.

### A CLI gratuita é o mesmo programa que o app de Mac?

Não. São implementações separadas que compartilham um vocabulário de limpeza, um arquivo de lista de exclusões
e um registro. O app é uma reimplementação em Swift, não um invólucro em volta da CLI, e é
de propósito mais estreito sobre o que remove.

### O Mole precisa de Acesso Total ao Disco, e por quê?

As varreduras de dados de app ficam atrás dessa permissão. Sem ela o Mole ainda roda. Ele vê menos
e diz isso, em vez de informar um número menor como se fosse o quadro inteiro.

Vale entender o que o Acesso Total ao Disco faz e o que não faz. O que ele
permite é uma visão mais ampla de locais protegidos de dados do usuário, para uma varredura e uma revisão serem
precisas, não um cheque em branco para apagar: as mesmas travas acima ainda decidem cada remoção.
O que ele não prova é confiabilidade. Não é certificação de antivírus, não é um selo
de “limpador aprovado pela Apple” e não é evidência de que uma ferramenta é segura. Um limpador com Acesso
Total ao Disco ainda pode apagar a coisa errada. Conceda só a ferramentas em que você já confia,
julgue-as pela revisão antes de apagar, pelas recusas de caminhos protegidos e pelos registros descritos nesta
página, e revogue para qualquer ferramenta em Ajustes do Sistema › Privacidade e Segurança › Acesso Total ao
Disco.

### Como confiro o que o Mole apagou da última vez?

Leia o final de `~/Library/Logs/mole/operations.log`. `TRASHED` registra uma ida para o
Lixo. Confira se o arquivo ainda está lá. `DELETED` e o `REMOVED` da CLI registram remoção
permanente. Status `SKIPPED` explicam o que não foi removido.

### Uma licença muda o que é apagado?

Não. A licença decide se uma operação destrutiva pode rodar, nunca a largura dela.
A varredura, a lista de candidatos e as regras de proteção são idênticas antes e depois
da ativação.

---

Canonical HTML page: https://mole.fit/pt-br/blog/is-mole-safe
Blog index for agents: https://mole.fit/pt-br/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
