# Achar sobras na Library depois de desinstalar apps no Mac
> Relacione sobras da Library à identidade do bundle do app, proteja pastas compartilhadas do fornecedor e revise o que resta depois do Lixo ou de uma instalação antiga.
Published: 2026-07-29 | Updated: 2026-10-18
Aponte dois scanners de sobras para o mesmo app desinstalado e você vai receber duas listas. Isso
não é um bug. Cada ferramenta escolhe a própria regra de propriedade, a própria lista de recusa e o
próprio limite de trabalho de administrador. Essas três escolhas decidem tudo na tela.
Depois que você entende a atribuição, a limpeza de sobras deixa de ser "quem acha mais lixo" e
passa a ser "de quem os erros doem menos".
Este guia é sobre o estado posterior: o app já se foi, ou acabou de cair no
Lixo, e você quer que o resíduo seja revisado com o mesmo cuidado que um desinstalador deveria ter usado.
Para a sequência completa enquanto o app ainda roda, veja
[desinstalação completa](https://mole.fit/pt-br/blog/how-to-completely-uninstall-apps-on-mac). Para escolhas de produto,
veja [além do AppCleaner](https://mole.fit/pt-br/blog/appcleaner-alternative).
Arrastar um app para o Lixo remove só o bundle; os dados dele ficam sob `~/Library` em Application Support, Caches, Preferences e Containers. Atribua sobras pelo identificador do bundle, nunca por tamanho ou nome, e revise cada candidato antes de apagar, ou use um desinstalador que aplique exatamente isso.
## O que "desinstalar" significa de fato no macOS
O macOS não trata um aplicativo como um objeto com um botão de apagar. Há pelo
menos três camadas:
| Camada | Local típico | Quem deve remover |
|---|---|---|
| Bundle do app | `/Applications`, `~/Applications`, Setapp etc. | Você, o Lixo ou o gerenciador de pacotes |
| Suporte do usuário | `~/Library/…` | Scanner de sobras ou revisão cuidadosa à mão |
| Sistema / privilegiado | `/Library`, helpers, recibos, extensões | **Desinstalador do fornecedor** primeiro |
Arrastar para o Lixo só garante a primeira camada. A camada do meio é onde ferramentas
genéricas ajudam. A terceira é onde elas muitas vezes fingem e falham: drivers, extensões
de rede, helpers privilegiados, daemons de licenciamento. A Apple ainda diz para preferir um
app Uninstall do fornecedor por esse motivo
([Apagar ou desinstalar apps](https://support.apple.com/102610)).
Remover o bundle do app é só a camada de cima. O resíduo da Library do usuário e os helpers do sistema são decisões separadas, com risco diferente.
## Onde as sobras do usuário de fato vivem
A maior parte do resíduo de terceiros se agrupa sob a Library pessoal:
| Área | O que em geral é |
|---|---|
| `Application Support/` | Bancos, pacotes offline, estado de projeto |
| `Caches/` | Cache que se recria |
| `Containers/` e `Group Containers/` | Casas em sandbox e grupos compartilhados |
| `Preferences/` (+ ByHost) | Plists de ajustes |
| `Logs/`, DiagnosticReports | Diagnóstico |
| `Saved Application State/` | Restauração de janela |
| `HTTPStorages/`, WebKit, cookies | Estado de rede dessa identidade |
| `LaunchAgents/` | Helpers de login do usuário apoiados num plist |
| `Application Scripts/` | Pacotes de script do sandbox |
Caminhos no nível do sistema sob `/Library` (LaunchDaemons, PrivilegedHelperTools, recibos sob
`/private/var/db/receipts`) são uma camada de risco maior. Prefira o removedor do fornecedor; trate
scanners genéricos como só revisão ali.
Um app em sandbox muitas vezes parece arrumado: contêiner primário em
`~/Library/Containers/`. Ele ainda pode usar App Groups, Application Scripts,
caches compartilhados, CloudKit ou itens das Chaves. O sandbox estreita o acesso direto a arquivos; não
garante uma pegada de um diretório só. Um app fora do sandbox pode se espalhar por
Application Support, Caches, Preferences, Logs, Saved Application State, WebKit e
Cookies. Dispersão mais larga significa mais espaço para duas ferramentas discordarem.
## A atribuição é a habilidade inteira
A descoberta segura de sobras se apoia na **identidade**, não em nomes de marketing.
### Identificador do bundle versus nome de exibição
`com.example.widget` é estável entre renomeações e localizações. Nomes de exibição não são.
Dois produtos podem compartilhar uma pasta da empresa (`…/Application Support/Google`) enquanto só um
está desinstalado. Casar "Google" como string é como scanners inventam falsos positivos
de vários gigabytes.
A **correspondência por identificador** é precisa e quase nunca propõe dados de um app irmão. Ela
perde pastas que o app nomeou a partir de si mesmo.
A **correspondência por nome** acha essas pastas, e também coisas que só compartilham uma palavra. Acha
mais e erra com mais frequência.
A correspondência por identidade é mais estreita e mais segura. A correspondência por nome acha mais sobras e erra com mais frequência quando dois produtos compartilham uma pasta de fornecedor.
Checagens práticas antes de qualquer exclusão:
```
mdfind 'kMDItemCFBundleIdentifier == "com.example.widget"'
ls /Applications ~/Applications 2>/dev/null
```
Se qualquer coisa com esse id ainda existe, trate os caminhos de suporte compartilhados como **vivos**.
### Helpers e identidades embutidas
Apps modernos trazem helpers com ids relacionados: `com.example.widget.helper`, nomes declarados
em `SMPrivilegedExecutables`, itens de início sob `Contents/Library/LoginItems`. Um scanner
completo coleta esses ids do bundle **antes** de o app desaparecer. Depois que o
bundle se foi, você só tem o que foi registrado ou o que ainda está no disco sob nomes
exatos.
### Contêineres de grupo
`~/Library/Group Containers/` guarda dados compartilhados de suíte de propósito:
- `group.`
- nomes no escopo do time, como `.`
- espaços `group.*` compartilhados usados por vários apps
Só caminhos exatos no escopo do dono são candidatos a associação automática. Árvores de grupo
compartilhadas devem continuar só revisão, ou intocadas, quando qualquer irmão permanece. Esta é a categoria
em que ferramentas de "achou mais" causam dano real.
### Variantes de nome e builds de canal
`Foo Beta` pode deixar `Foo Beta`, `FooBeta` e às vezes uma pasta `Foo` estável que
pertence ao canal de lançamento ainda instalado. Nomes de base sem o canal têm alto
risco de falso positivo: mantenha-os só revisão, a menos que você prove que o app estável se foi.
A atribuição deve seguir a identidade do bundle até os caminhos de propriedade, não até pastas do fornecedor inteiro de que outros apps ainda precisam.
## Três pontos seguros de entrada
### 1. Desinstaladores do fornecedor primeiro
Agentes de segurança, clientes de VPN, drivers de áudio e ferramentas de endpoint conhecem os próprios recibos
e a ordem de desmontagem da extensão. Rode esses antes de qualquer caminhada pela Library. Apagar arquivo não é um
fluxo confiável de desativação para extensões de sistema ou de rede; o macOS as registra.
### 2. Revisar depois que o app já se foi
Quando o `.app` se foi, procure caminhos ainda marcados com esse bundle id ou variantes exatas
de nome. Padrões conservadores:
- **Muitas vezes ok quando é de propriedade:** caches, logs, estado salvo, relatórios de falha
- **Revise com cuidado:** Application Support, Containers, Preferences (licenças, e-mail
offline, bancos de projeto)
- **Em geral deixe:** Group Containers sem propriedade exata, Documentos fora da Library,
qualquer coisa de que outro id ainda precise
Meça os candidatos:
```
du -sh ~/Library/Application\ Support/ \
~/Library/Caches/ \
~/Library/Containers/ 2>/dev/null
```
Erros de permissão em geral significam que o Terminal não tem Acesso Total ao Disco, não que a pasta está
vazia.
### 3. O momento em que o app cai no Lixo
Muita gente joga no Lixo primeiro e pensa depois. Um observador que nota um `.app` novo em
`~/.Trash`, lê a identidade do Info.plist, varre arquivos de suporte relacionados e abre um
**painel de revisão** pega o resíduo sem uma caça. Restrições de design que
separam o útil do prejudicial:
- Nunca apague automaticamente o bundle do app que foi para o Lixo (Colocar de Volta tem de funcionar)
- Nunca apareça para classes protegidas / antivírus / MDM
- Consuma uma supressão de uma vez quando **o próprio limpador** mandou o app para o Lixo durante
a desinstalação, senão o painel corre contra o fluxo de desinstalação
- Condicione ao Acesso Total ao Disco; falhe em silêncio sem ele, em vez de pedir a partir do segundo plano
A revisão de sobras no Lixo do [Mole](https://mole.fit/mac-app-uninstaller) usa a identidade do app no Lixo para propor arquivos
relacionados, mantém o próprio bundle do app recuperável e suprime o pedido para classes
protegidas de software. A revisão só é útil quando essas checagens de propriedade ficam mais estreitas
do que uma busca por nome.
## Órfãos não são "qualquer coisa grande na Library"
Descobrir sobras de apps que você esqueceu exige **subtração de reivindicação**: enumere
pastas candidatas de suporte e depois subtraia tudo o que software instalado ainda reivindica
(ids de bundle, apps em execução, registro do Launch Services, raízes de fornecedor). Se a varredura
de reivindicação é parcial (tempo esgotado, diretórios ilegíveis), o resultado seguro é **zero órfãos**, não uma
lista no chute. Ferramentas que sempre acham dezenas de apps "lixo" num Mac limpo estão otimizando
para um número de venda.
Portões de período quieto também importam: uma configuração reescrita na semana passada pode pertencer a uma ferramenta de CLI
que a caminhada de reivindicação não consegue ver. mtimes recentes devem suprimir candidatos.
## Exemplo trabalhado: duas ferramentas, uma suíte de fornecedor
Você desinstala o Produto A de uma empresa que também entrega o Produto B, ainda instalado.
- Ferramenta 1 (pesada em identificador): lista pequena, sobretudo caminhos `com.vendor.productA.*`.
- Ferramenta 2 (pesada em nome): acrescenta `~/Library/Application Support/Vendor` (4 GB) e um contêiner
de grupo que os dois produtos usam.
A ferramenta 2 parece mais completa. Ela está propondo a exclusão que pode quebrar o Produto B. O
total no pé da tela não é uma nota de qualidade. As categorias acima dele são.
## O recibo órfão do Homebrew
Se o app veio de um Homebrew Cask, remover só o `.app` pode deixar um registro no Caskroom
que bloqueia a reinstalação. Depois das sobras de arquivo:
```
brew list --cask
```
Se o token permanece, `brew uninstall --cask ` limpa a associação (aceite
`--zap` só quando quiser a limpeza mais ampla do próprio brew). "Cask is not installed" depois
que o app já se foi é motivo para conferir o token e qual instalação do Homebrew você
está usando, não prova de uma associação velha nem motivo para `rm -rf` em caminhos aleatórios do Caskroom.
## O que recusar mesmo quando o nome casa
- Irmãos ainda instalados e gêmeos de canal
- Contêineres de grupo compartilhados e pastas pai do fornecedor
- Recibos e helpers privilegiados sem um removedor validado
- Documentos do usuário fora da Library
- Armazenamentos de conversa de IA e diretórios de modelo que ficam perto de caminhos de cache
([limpeza de IA](https://mole.fit/pt-br/blog/how-to-remove-ai-tool-leftovers-mac))
## Erros comuns
**Maximizar a lista encontrada.** Mais candidatos muitas vezes significa atribuição pior.
**Apagar Group Containers por padrão.** São compartilhados de propósito.
**Pular o desinstalador do fornecedor** para VPN, antivírus, áudio, virtualização.
**Medir sem Acesso Total ao Disco** e então concluir "não sobrou nada".
**Esvaziar o Lixo na hora** depois de uma exclusão em massa de sobras. Guarde um dia de uso normal se
algo importante pode ter sido mal atribuído.
## Conferir
1. Meça de novo os caminhos removidos.
2. Confirme que nenhum item de início ou launch agent desse id permanece
([itens de início](https://mole.fit/pt-br/blog/how-to-disable-startup-programs-on-mac)).
3. Abra os apps irmãos do mesmo fornecedor.
4. Esvazie o Lixo só depois de aceitar as remoções.
## Ordem das operações
1. Procure um desinstalador do fornecedor se o app tinha drivers, extensões ou helpers.
2. Exporte ou desautorize enquanto o app ainda roda, se isso importar.
3. Feche o app e os helpers visíveis.
4. Remova o bundle (ou confirme que ele já está no Lixo).
5. Revise as sobras por identidade; deixe os contêineres compartilhados em paz.
6. Trate recibos de cask do Homebrew, se for o caso.
7. Mantenha os itens no Lixo enquanto usa o Mac normalmente, e então esvazie.
## O primeiro dia depois de uma desinstalação
A maioria esvazia o Lixo no momento em que o app se vai. Uma agenda mais lenta não custa nada
e guarda um caminho de volta:
1. No primeiro dia, mande para o Lixo o bundle do app e só os caches que você confirmou que
se recriam.
2. Deixe Application Support e Containers em paz, e use o Mac normalmente por um dia.
3. Se os apps irmãos e os outros produtos do fornecedor ainda abrem limpos, remova o segundo
lote.
4. Para caminhos sobre os quais você ainda tem dúvida, registre o tamanho com `du -sh` e decida uma semana
depois.
O Lixo fica no mesmo volume, então nada é liberado até você esvaziá-lo. O que a espera compra
é uma janela de recuperação. Se o disco está de fato sem espaço, esvazie primeiro os caches que se
recriam para ganhar folga e guarde os caminhos em disputa para depois.
## Permissões e visibilidade
Sem Acesso Total ao Disco, o Terminal e a maioria dos scanners não conseguem ver dentro de Containers e
de partes da Library. O `du` imprime erros de permissão e ainda termina com um total, e
esse total deixa de fora tudo o que não conseguiu abrir. A leitura não é "não sobrou nada";
é "você não tem permissão de olhar".
- Conceda Acesso Total ao Disco ao Terminal, ou à ferramenta que roda a varredura, e meça de novo.
- Compare os números antes e depois. Decidir a partir do passe meio cego é como um
contêiner de vários gigabytes acaba chamado de vazio.
- Retire o Acesso Total ao Disco de ferramentas que você parou de usar. É a permissão de leitura
mais larga do Mac, e uma concessão sobrevive ao motivo pelo qual foi dada.
## Como isto se relaciona com o guia de desinstalação completa
A [desinstalação completa](https://mole.fit/pt-br/blog/how-to-completely-uninstall-apps-on-mac) é a ordem a seguir
enquanto o app ainda está instalado: desinstalador do fornecedor primeiro, exportar ou desautorizar, fechar,
remover o bundle e então revisar o que sobrou. Este guia supõe que o bundle já
se foi, que é o que remove a evidência fácil, e gasta o comprimento na metade que
resta: decidir quais arquivos o app possuía e quais só compartilhava.
## Leitura adicional
- Apple: [Apagar ou desinstalar apps no Mac](https://support.apple.com/102610)
- Relacionados: [desinstalação completa](https://mole.fit/pt-br/blog/how-to-completely-uninstall-apps-on-mac),
[alternativas ao AppCleaner](https://mole.fit/pt-br/blog/appcleaner-alternative),
[o que limpadores nunca deveriam apagar](https://mole.fit/pt-br/blog/what-mac-cleaners-should-never-delete)
Limpeza de sobras é manutenção de identidade. A habilidade não é maximizar gigabytes; é
provar a propriedade, proteger o estado compartilhado e manter as exclusões recuperáveis.
## Perguntas frequentes
### É seguro eu mesmo apagar arquivos sobrando em ~/Library?
Só com atribuição: relacione a pasta ao identificador do bundle do app, não ao tamanho nem a um nome parecido, e revise cada item antes de ele ir. Um chute errado pode levar os dados de outro app ou os seus documentos.
### Por que os apps deixam arquivos para trás?
O macOS não tem um contrato de desinstalação: arrastar o bundle para o Lixo é o mecanismo inteiro, e tudo o que o app escreveu em tempo de execução fica onde foi escrito.
### Uma reinstalação recria o que eu apaguei?
Estado que se reconstrói, sim: caches, recibos e preferências padrão voltam na primeira abertura. Documentos, histórico de conversa e licenças não, e é por isso que uma ferramenta cuidadosa pré-seleciona só o que uma reinstalação recriaria.
---
Canonical HTML page: https://mole.fit/pt-br/blog/how-to-remove-leftover-files-after-uninstalling-mac-apps
Blog index for agents: https://mole.fit/pt-br/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
