Achar sobras na Library depois de desinstalar apps no Mac

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. Para escolhas de produto, veja além do AppCleaner.

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:

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).

Onde as sobras do usuário de fato vivem

A maior parte do resíduo de terceiros se agrupa sob a Library pessoal:

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/<bundle id>. 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.

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.<bundle id>
• nomes no escopo do time, como <TeamID>.<bundle id>
• 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.

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/<Name> \
  ~/Library/Caches/<bundle.id> \
  ~/Library/Containers/<bundle.id> 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 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 <token> 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)

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).
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 é 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
• Relacionados: desinstalação completa, alternativas ao AppCleaner, o que limpadores nunca deveriam apagar

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.