# Quando um app do Mac não desinstala: sete causas para verificar
> Use o erro exato e o estado do app para investigar auxiliares em execução, permissões, launchd, SIP, Gerenciamento de Apps e MDM antes de escolher o método de desinstalação.
Published: 2026-08-18 | Updated: 2026-10-18
Uma desinstalação que falha no macOS não é um problema só. O Finder pode recusar mover o bundle. A
mudança pode dar certo e o app pode estar de volta no próximo login. O bundle pode sumir enquanto o
auxiliar que incomodava continua rodando. Cada um é um mecanismo diferente, com uma correção diferente,
então comece pelo que o seu Mac fez de fato. Para a sequência comum, veja
[desinstalação completa](https://mole.fit/pt-br/blog/how-to-completely-uninstall-apps-on-mac). O que segue supõe
que isso já falhou.
## Comece pelo sintoma
O texto da recusa é diagnóstico. Dois destes seis não produzem diálogo nenhum, e por isso são lidos como a ferramenta estando quebrada.
- **“O item não pode ser movido para o Lixo porque está aberto.”** Algo está em execução,
muitas vezes não o app que você encerrou.
- **Foi apagado, e voltou.** Confira se o bundle foi reinstalado ou se só
um auxiliar que sobreviveu reiniciou. Isso pede correções diferentes.
- **O Finder pede uma senha de administrador.** Um `.pkg` deixou o bundle pertencendo a root.
Normal.
- **Nada acontece. Sem diálogo, sem erro.** A permissão de Gerenciamento de Apps é uma causa possível.
- **`rm` como root diz "Operação não permitida" (Operation not permitted).** Uma restrição de proteção ou de permissão. A mensagem sozinha não identifica o SIP.
- **Acinzentado, ou reaparece num Mac de trabalho.** Um perfil de configuração ou o MDM é o dono.
## 1. O app, ou um dos auxiliares, ainda está em execução
O Finder recusa mover um bundle cujos arquivos estão abertos, e encerrar o processo que você vê
não para tudo que o app iniciou. O Monitor de Atividade lista todo processo, não só
os que têm janela. Procure o nome do fabricante e leia o conjunto inteiro de resultados: um app chamado
Foo em geral traz `Foo Helper`, um `FooUpdater` e um bundle de item de início com um nome de
exibição sem relação. A janela **Forçar Encerrar Aplicativos** não substitui, porque lista
só aplicativos com presença de interface.
```
pgrep -fl -i foo
lsof +D /Applications/Foo.app 2>/dev/null | awk '{print $1, $2}' | sort -u
```
`pgrep -fl` casa a linha de comando inteira, então pega um auxiliar cujo caminho do executável
carrega o nome do fabricante mesmo quando o nome do processo não carrega. `lsof +D` informa todo
processo que segura um arquivo dentro do bundle.
Forçar o encerramento do pai não para um auxiliar de forma confiável. Um auxiliar é o próprio processo,
com o próprio PID, então matar o pai o deixa órfão, a menos que o pai o derrube ao
sair. E se o launchd gerencia o auxiliar, matar qualquer um dos dois só diz ao launchd para iniciá-lo
de novo. Essa é a próxima seção.
Uma pré-visualização do Quick Look ou a indexação do Spotlight também podem segurar arquivos no bundle, e uma reinicialização
limpa os dois. Se a mensagem voltar, o
[guia de remoção de apps](https://support.apple.com/guide/mac-help/mh35835/mac) da Apple sugere o Modo
Seguro.
## 2. Um agente ou daemon do launchd reinicia um auxiliar que sobreviveu
Se um ícone ou um auxiliar volta, confira primeiro se o executável ainda existe fora
do bundle apagado. O launchd pode reiniciar esse programa, mas não consegue restaurar um bundle de app
apagado por conta própria. Um instantâneo quieto do Monitor de Atividade não descarta um job sob demanda.
O launchd supervisiona jobs em segundo plano. Um job é uma property list com um `Label`, um programa
e condições para rodá-lo. `RunAtLoad` o inicia quando o job carrega, `KeepAlive`
o reinicia quando ele sai. Um job sem nenhum dos dois ainda volta: `MachServices`, `Sockets`,
`WatchPaths`, `QueueDirectories` e `StartInterval` fazem o launchd iniciar o processo
no momento em que algo pede, então um auxiliar que fica ocioso depois de dez segundos e
reinicia no serviço Mach parece ausente toda vez que você olha.
As definições ficam em três lugares. `~/Library/LaunchAgents` é só o seu usuário, dentro da
sessão de login. `/Library/LaunchAgents` roda para todo usuário no login. E
`/Library/LaunchDaemons` guarda jobs de todo o sistema, que podem rodar sem login. Eles usam
root por padrão, mas podem especificar outro usuário. Agentes ou daemons podem sobreviver a uma
desinstalação manual se foram instalados fora do bundle. `/System/Library/Launch*` é
da Apple e está protegido.
```
launchctl list | grep -i foo
launchctl print-disabled gui/$(id -u) | grep -i foo
grep -l -i foo ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist \
/Library/LaunchDaemons/*.plist 2>/dev/null
```
Em `launchctl list`, um rótulo com PID está rodando agora e um com um traço está carregado e
esperando um gatilho. `print-disabled` lê o banco persistente de estado desativado, um
fato separado de um plist existir. Leia o candidato com `plutil -p ` e
confira se `Program` ou `ProgramArguments` aponta para o app que você está removendo: fabricantes nem
sempre nomeiam o arquivo pelo rótulo de dentro.
### A ordem importa
Pare e desative o job primeiro, depois remova o plist, depois remova o app.
```
launchctl bootout gui/$(id -u)/com.vendor.foo.helper
sudo launchctl bootout system/com.vendor.foo.daemon
launchctl disable gui/$(id -u)/com.vendor.foo.helper
```
Apague o plist enquanto o job está carregado e o launchd mantém um serviço cuja definição não
existe mais no disco. Ele roda até a próxima reinicialização e pode deixar uma entrada velha no
banco de estado desativado. Remover o app primeiro é pior: o job reaparece contra um
executável ausente e falha em loop, e é daí que vem "sumiu, mas ainda aparece em
Itens de Início".
No macOS 13 e posteriores, apps podem se registrar por
[`SMAppService`](https://developer.apple.com/documentation/servicemanagement/smappservice)
e manter o executável do auxiliar e os arquivos de serviço dentro do bundle do app, então pode
não haver um plist avulso nos diretórios acima. O próprio registro é gerenciado pelo macOS.
Isso pertence ao gerenciamento de tarefas em segundo plano, controlado em
**Ajustes do Sistema › Geral › Itens de Início de Sessão e Extensões**
([guia de itens de início](https://mole.fit/pt-br/blog/how-to-disable-startup-programs-on-mac)).
## 3. É um app do sistema protegido pelo SIP
A Proteção da Integridade do Sistema é uma política no nível do kernel, não um bit de permissão. A Apple
a descreve como o uso de permissões do kernel para limitar a escrita de arquivos críticos do sistema,
aplicada "a todo processo em execução no sistema, esteja ele
em sandbox ou com privilégios de administrador"
([Apple Platform Security](https://support.apple.com/guide/security/system-integrity-protection-secb7ea06b49/web)).
Desde o Big Sur o conteúdo do sistema também fica num volume separado, selado criptograficamente.
`csrutil status` imprime se a proteção está ligada, e a Apple é explícita: "você não pode
remover apps exigidos pelo Mac", um conjunto que inclui Mail, Música, Livros, Notas,
Podcasts, Mapas, News e Bolsa.
Desligar o SIP para apagar um bundle é uma troca ruim. Significa iniciar na Recuperação e
mudar uma política de segurança de toda a máquina. Em Macs Intel, a Apple observa que desativá-lo
remove a proteção de toda partição no dispositivo de armazenamento físico, e no Apple silicon
o Mac sai da Segurança Total. O ganho também não dura: o volume do sistema é substituído
por inteiro na próxima atualização do macOS, e nenhum espaço usável é recuperado.
Melhor: arraste o ícone para fora do Dock, remova-o de
**Ajustes do Sistema › Geral › Itens de Início de Sessão e Extensões** e, se ele continuar abrindo os seus
arquivos, mude o manipulador com **Obter Informações › Abrir com › Alterar Tudo**.
## 4. Foi instalado por MDM ou por um perfil de configuração
Num Mac gerenciado, um app pode ser empurrado de volta no horário do servidor de gerenciamento, e um
perfil pode ser marcado como não removível. Os sintomas são uma remoção que se desfaz horas
depois, um controle acinzentado, ou uma busca no launchd que não acha nada porque a reinstalação
é conduzida remotamente. Confira **Ajustes do Sistema › Geral › Gerenciamento de Dispositivos**. Se essa
seção estiver ausente, não trate isso sozinho como prova de que o Mac não é gerenciado. Confira
o estado de registro e pergunte à TI num Mac da organização.
```
profiles status -type enrollment
sudo profiles list
```
O primeiro informa o registro pelo Registro Automatizado de Dispositivos e se ele tem aprovação
do usuário. O segundo lista os perfis instalados e precisa de root. Depois pergunte à TI. A orientação da Apple é perguntar a quem forneceu um perfil que você não consegue remover,
e ela avisa que remover um perfil apaga tudo que esse perfil configurou, então um
que carrega a conta de e-mail leva isso junto.
## 5. Posse, e a permissão que falha em silêncio
**O Finder pede uma senha de administrador.** Comum. Um instalador `.pkg` roda como root
e deixa o bundle pertencendo a root, então movê-lo precisa de autenticação. Confirme com
`ls -ld /Applications/Foo.app`. Recibos valem a pena conhecer enquanto você está aqui:
`pkgutil --files ` lista os caminhos que um pacote colocou, e `sudo pkgutil --forget `
tira o recibo de `/private/var/db/receipts` sem apagar um único arquivo.
**Nada acontece.** Sem pedido, sem erro, o app continua em `/Applications`, e
a ferramenta que você usou informa uma falha vaga ou recua para outra coisa. No macOS 14 e
posteriores, o Gerenciamento de Apps é uma causa possível: ele controla se um app pode atualizar ou
apagar outros apps. Este teste somente leitura confere se o caminho do bundle é gravável:
```
test -w /Applications/Foo.app && echo "posix says yes"
```
Esse resultado não descarta um problema de permissão. A remoção também depende das permissões de escrita e de busca do
diretório pai, de ACLs e de outras proteções. Se o Gerenciamento de Apps
estiver negado, abra **Ajustes do Sistema › Privacidade e Segurança › Gerenciamento de Apps**, ative o
app confiável que faz a remoção, reabra-o e tente de novo.
## Por baixo: três recusas que parecem iguais
Permissões de arquivo são uma trava: posse, acesso ao diretório pai e ACLs podem afetar
a remoção. A autorização de administrador ajuda com algumas restrições, não com todas.
O TCC, a camada de privacidade por trás dos Ajustes do Sistema, acrescenta uma verificação separada. Gerenciamento de Apps
é uma trava TCC para uma operação, modificar ou apagar o bundle de outro app. Ser
administrador não a satisfaz, e `sudo` também não, porque ela é ligada ao
programa que pede, não ao usuário, e por isso a negação pode aparecer como um erro genérico,
sem pedido.
O sinal visível separa os três. Um pedido de senha do Finder é posse comum,
e a autenticação resolve. Quando o Gerenciamento de Apps bloqueia a remoção, não há
diálogo de senha. O macOS em geral posta um banner na Central de Notificações dizendo que o app foi
impedido de modificar apps no Mac, e a correção é o interruptor de Privacidade e uma
reabertura, não uma senha. Uma "Operação não permitida" (Operation not permitted) como root aponta para uma proteção que uma
senha não limpa. O Gerenciamento de Apps é uma delas: até `sudo` recebe "Operação não permitida" (Operation not permitted)
quando o terminal que o roda não tem a concessão. Outras proteções também o produzem, então
diagnostique pelo caminho e pelo app que pede antes de supor SIP.
O SIP pode recusar até root, mas o texto do erro sozinho não identifica a proteção.
`EACCES` (`Permission denied`) pode incluir falta de acesso de escrita ou de busca a um diretório
pai. `EPERM` (`Operation not permitted`) tem causas além do SIP. Confira o caminho
exato, a posse, as permissões do diretório pai e o app que pede antes de escolher uma correção.
Nenhuma das mensagens é motivo para desativar a proteção do sistema.
## 6. Uma extensão do sistema ou um filtro de rede ainda está ativo
Software de segurança, clientes de VPN e produtos de virtualização instalam extensões do sistema. O
app que contém registra a extensão, e apagar arquivos individuais não é um procedimento confiável de
desativação. O macOS pode remover uma extensão do sistema quando o app que a contém é
movido corretamente para o Lixo, mas o software do fabricante pode ter outros componentes instalados.
Use o procedimento de remoção do fabricante e verifique o estado resultante.
```
systemextensionsctl list
```
A saída mostra o identificador de equipe, o identificador de bundle e um estado como
`[activated enabled]`. A desativação pertence ao app que contém e muitas vezes precisa de uma reinicialização,
então rode o desinstalador do fabricante primeiro.
[Desinstalar antivírus no Mac](https://mole.fit/pt-br/blog/how-to-uninstall-antivirus-mac) cobre a ordem de
desmontagem desta classe.
## 7. Veio da App Store, ou do Homebrew
**Apps da Mac App Store.** Apagar o bundle não remove a compra. O caso que
pega as pessoas é o ajuste que a Apple formula como baixar automaticamente apps que você
comprou na App Store em outros computadores Mac e aparelhos: se um segundo Mac na
mesma conta compra um app em outro aparelho, o ajuste pode baixar essa compra.
Só manter um app instalado num segundo Mac não prova, por si, uma causa de reinstalação. Confira o ajuste em
**App Store › Ajustes**.
**Casks do Homebrew.** Se você instalou com `brew install --cask foo`, jogar o app no Lixo
deixa o Homebrew acreditando que ele está instalado. `brew list --cask` ainda mostra o token, e
o próximo `brew upgrade` pode reinstalar o app que você acabou de apagar, uma causa real de "voltou"
sem job do launchd envolvido. Rode `brew uninstall --cask foo` no lugar. A manpage do Homebrew
descreve `--zap` como remover "all files associated with a cask" e avisa que "may remove
files which are shared between applications", então use esse de propósito.
## Depois de uma exclusão bem-sucedida: o que fica para trás
**Itens de Início de Sessão e Extensões ainda lista.** Ou uma entrada "Abrir no início" apontando para um
caminho ausente, ou um registro de gerenciamento de tarefas em segundo plano de um serviço cujo programa sumiu.
Remova com o botão de menos em **Ajustes do Sistema › Geral › Itens de Início e
Extensões**. O macOS muitas vezes limpa isso sozinho depois de uma reinicialização.
**Um ícone na barra de menus aparece na inicialização.** Algo ainda carrega um binário: em geral um launch agent
que você nunca removeu, ou um auxiliar que o instalador copiou para
`~/Library/Application Support/`.
**Um auxiliar privilegiado sobrevive.** Software que precisou de root instala em
`/Library/PrivilegedHelperTools/
