# Als een Mac-app niet wil verwijderen: zeven oorzaken om te controleren
> Gebruik de precieze fout en de staat van de app om draaiende helpers, bevoegdheden, launchd, SIP, Appbeheer en MDM te onderzoeken voordat je een verwijderingsmethode kiest.
Published: 2026-08-18 | Updated: 2026-10-18
Een mislukte verwijdering op macOS is niet één probleem. De Finder kan weigeren de bundel te verplaatsen. De
verplaatsing kan slagen en de app kan bij de volgende aanmelding terug zijn. De bundel kan verdwijnen terwijl de
helper die je irriteerde blijft draaien. Elk is een ander mechanisme met een andere reparatie,
dus begin bij precies wat je Mac deed. Voor de gewone volgorde, zie
[volledig verwijderen](https://mole.fit/nl/blog/how-to-completely-uninstall-apps-on-mac). Wat volgt, gaat ervan uit
dat dat al is mislukt.
## Begin bij het symptoom
De formulering van de weigering is diagnostisch. Twee van deze zes geven helemaal geen dialoog, en daarom worden ze gelezen als een kapotte tool.
- **"Het onderdeel kan niet naar de prullenmand worden verplaatst omdat het geopend is."** Er draait iets,
vaak niet de app die je hebt gestopt.
- **Het was verwijderd, en het is terug.** Controleer of de bundel opnieuw is geïnstalleerd of alleen
een overgebleven helper opnieuw is gestart. Die vragen om verschillende reparaties.
- **De Finder vraagt om een beheerderswachtwoord.** Een `.pkg` liet de bundel in bezit van root.
Normaal.
- **Er gebeurt niets. Geen dialoog, geen fout.** De bevoegdheid Appbeheer is één mogelijke oorzaak.
- **`rm` als root zegt "Operation not permitted".** Een bescherming of een bevoegdheidsbeperking. De melding alleen wijst SIP niet aan.
- **Uitgegrijsd, of het komt terug op een werk-Mac.** Een configuratieprofiel of MDM bezit het.
## 1. De app, of een van zijn helpers, draait nog
De Finder weigert een bundel te verplaatsen waarvan bestanden open zijn, en het proces stoppen dat je kunt zien
stopt niet alles wat de app heeft gestart. Activiteitenweergave toont elk proces, niet alleen
de processen met een venster. Zoek de leveranciersnaam en lees de hele resultatenverzameling: een app die
Foo heet, levert vaak `Foo Helper`, een `FooUpdater` en een inlogonderdeel-bundel met een niet-gerelateerde
weergavenaam. Het venster **Apple-menu › Forceer stop** is geen vervanging, want het toont
alleen apps met een aanwezigheid in de interface.
```
pgrep -fl -i foo
lsof +D /Applications/Foo.app 2>/dev/null | awk '{print $1, $2}' | sort -u
```
`pgrep -fl` vergelijkt de volledige opdrachtregel, dus het vangt een helper waarvan het uitvoerbare pad
de leveranciersnaam draagt, ook als de procesnaam dat niet doet. `lsof +D` meldt elk
proces dat een bestand in de bundel vasthoudt.
De ouder geforceerd stoppen stopt een helper niet betrouwbaar. Een helper is een eigen proces
met een eigen PID, dus de ouder stoppen laat hem verweesd achter, tenzij de ouder hem bij het
afsluiten zelf afbreekt. En beheert launchd de helper, dan zegt het doden van een van beide alleen tegen launchd dat hij hem
opnieuw moet starten. Dat is de volgende sectie.
Een Quick Look-voorvertoning of Spotlight-indexering kan ook bestanden in de bundel vasthouden, en een herstart
wist beide. Komt de melding terug, dan raadt de
[verwijdergids voor apps van Apple](https://support.apple.com/guide/mac-help/mh35835/mac) de veilige
modus aan.
## 2. Een launchd-agent of -daemon start een overgebleven helper opnieuw
Komt een symbool of helper terug, controleer dan eerst of het uitvoerbare bestand nog buiten
de verwijderde bundel bestaat. launchd kan dat programma opnieuw starten, maar kan een verwijderde app-bundel niet zelf terugzetten. Een stille momentopname van Activiteitenweergave sluit een taak op verzoek niet uit.
launchd houdt achtergrondtaken in de gaten. Een taak is een property list met een `Label`, een programma
en voorwaarden om het te draaien. `RunAtLoad` start het als de taak laadt, `KeepAlive`
start het opnieuw als het stopt. Een taak met geen van beide komt nog terug: `MachServices`, `Sockets`,
`WatchPaths`, `QueueDirectories` en `StartInterval` laten launchd het proces starten
op het moment dat iets erom vraagt, dus een helper die na tien seconden inactief wordt en
op zijn Mach-dienst opnieuw start, lijkt elke keer dat je kijkt afwezig.
Definities staan op drie plekken. `~/Library/LaunchAgents` is alleen jouw gebruiker, binnen je
aanmeldsessie. `/Library/LaunchAgents` draait voor elke gebruiker bij het aanmelden. En
`/Library/LaunchDaemons` bevat systeembrede taken die zonder aanmelding kunnen draaien. Ze gebruiken
standaard root maar kunnen een andere gebruiker opgeven. Agents of daemons kunnen een
handmatige verwijdering overleven als ze buiten de bundel zijn geïnstalleerd. `/System/Library/Launch*` is
van Apple en beschermd.
```
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
```
In `launchctl list` draait een label met een PID nu, en een label met een streepje is geladen en
wacht op een trigger. `print-disabled` leest de blijvende database van uitgeschakelde staat, een
apart feit van of er een plist bestaat. Lees de kandidaat met `plutil -p ` en
controleer dat `Program` of `ProgramArguments` naar de app wijst die je verwijdert: leveranciers
noemen het bestand niet altijd naar het label erin.
### De volgorde telt
Stop en schakel de taak eerst uit, verwijder daarna de plist, en verwijder dan de 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
```
Verwijder je de plist terwijl de taak geladen is, dan houdt launchd een dienst waarvan de definitie niet
meer op schijf bestaat. Die draait tot de volgende herstart en kan een verouderde regel achterlaten in de
database van uitgeschakelde staat. De app eerst weghalen is erger: de taak start opnieuw tegen een
ontbrekend uitvoerbaar bestand en faalt in een lus, en daar komt "hij is weg maar staat nog bij
Inlogonderdelen" vandaan.
Op macOS 13 en later kunnen apps zich registreren via
[`SMAppService`](https://developer.apple.com/documentation/servicemanagement/smappservice)
en het helper-uitvoerbare bestand en de dienstbestanden in de appbundel houden, dus er is misschien
geen losse plist in de mappen hierboven. De registratie zelf wordt door macOS beheerd.
Die horen bij Background Task Management, te bedienen in
**Systeeminstellingen › Algemeen › Inlogonderdelen en extensies**
([gids voor opstartonderdelen](https://mole.fit/nl/blog/how-to-disable-startup-programs-on-mac)).
## 3. Het is een systeemapp die door SIP wordt beschermd
System Integrity Protection is beleid op kernelniveau, geen bevoegdheidsbit. Apple
beschrijft het als kernelbevoegdheden gebruiken om de schrijfbaarheid van kritieke systeembestanden te beperken,
toegepast "op elk proces dat op het systeem draait, ongeacht of dat proces
in een sandbox draait of met beheerdersrechten"
([Apple Platform Security](https://support.apple.com/guide/security/system-integrity-protection-secb7ea06b49/web)).
Sinds Big Sur staat de systeeminhoud ook op een apart, cryptografisch verzegeld volume.
`csrutil status` toont of de bescherming aan staat, en Apple is expliciet dat "je apps die je Mac nodig heeft niet kunt
verwijderen", een set die Mail, Muziek, Boeken, Notities,
Podcasts, Kaarten, News en Aandelen bevat.
SIP uitzetten om één bundel te verwijderen is een slechte ruil. Het betekent opstarten naar Herstel en
een machinebreed beveiligingsbeleid wijzigen. Op Intel-Macs merkt Apple op dat het uitschakelen
de bescherming weghaalt voor elke partitie op het fysieke opslagapparaat, en op Apple silicon
verlaat de Mac Volledige beveiliging. De winst houdt ook niet stand: het systeemvolume wordt bij de
volgende macOS-update in zijn geheel vervangen, en er komt geen bruikbare ruimte vrij.
Beter: sleep het symbool uit het Dock, haal het uit
**Systeeminstellingen › Algemeen › Inlogonderdelen en extensies**, en als het je
bestanden blijft openen, wijzig de handler met **Toon info › Open met › Wijzig alles**.
## 4. Het is geïnstalleerd door MDM of een configuratieprofiel
Op een beheerde Mac kan een app terug worden gezet volgens het schema van de beheerserver, en een
profiel kan als niet-verwijderbaar zijn gemarkeerd. De symptomen zijn een verwijdering die zich uren
later ongedaan maakt, een uitgegrijsde bediening, of een launchd-zoektocht die niets vindt omdat de herinstallatie
op afstand wordt aangestuurd. Controleer **Systeeminstellingen › Algemeen › Apparaatbeheer**. Is die
sectie afwezig, behandel dat dan niet op zich als bewijs dat de Mac onbeheerd is. Controleer
de inschrijvingsstatus en vraag IT op een Mac die van een organisatie is.
```
profiles status -type enrollment
sudo profiles list
```
De eerste meldt inschrijving via Automated Device Enrollment en of die door de gebruiker
is goedgekeurd. De tweede toont geïnstalleerde profielen en heeft root nodig. Vraag daarna IT. De uitleg van Apple is om te vragen wie een profiel heeft geleverd dat je niet kunt verwijderen,
en hij waarschuwt dat een profiel verwijderen alles wist wat dat profiel heeft ingesteld, dus een profiel
dat je mailaccount draagt, neemt dat mee.
## 5. Eigendom, en de bevoegdheid die stil faalt
**De Finder vraagt om een beheerderswachtwoord.** Gewoon. Een `.pkg`-installatieprogramma draait als root
en laat de bundel in bezit van root, dus verplaatsen vraagt authenticatie. Bevestig met
`ls -ld /Applications/Foo.app`. Installatiebewijzen zijn het weten waard zolang je hier bent:
`pkgutil --files ` toont de paden die een pakket heeft geplaatst, en `sudo pkgutil --forget `
haalt het bewijs uit `/private/var/db/receipts` zonder één bestand te verwijderen.
**Er gebeurt helemaal niets.** Geen vraag, geen fout, de app staat nog in `/Applications`, en
de tool die je gebruikte meldt een vage mislukking of valt terug op iets anders. Op macOS 14 en
later is Appbeheer één mogelijke oorzaak: het bepaalt of een app andere apps mag bijwerken of
verwijderen. Deze alleen-lezen test controleert of het bundelpad schrijfbaar is:
```
test -w /Applications/Foo.app && echo "posix says yes"
```
Dat resultaat sluit een bevoegdheidsprobleem niet uit. Verwijderen hangt ook af van de schrijf- en zoekbevoegdheden van de bovenliggende
map, ACL's en andere beschermingen. Is Appbeheer
geweigerd, open dan **Systeeminstellingen › Privacy en beveiliging › Appbeheer**, schakel de
vertrouwde app in die de verwijdering doet, start hem opnieuw en probeer het nog eens.
## Onder de motorkap: drie weigeringen die hetzelfde ogen
Bestandsbevoegdheden zijn één poort: eigendom, toegang tot de bovenliggende map en ACL's kunnen verwijderen
beïnvloeden. Autorisatie als beheerder helpt bij sommige beperkingen, niet bij allemaal.
TCC, de privacylaag achter Systeeminstellingen, voegt een aparte controle toe. Appbeheer
is een TCC-poort voor één handeling, het wijzigen of verwijderen van de bundel van een andere app. Beheerder
zijn voldoet er niet aan en `sudo` ook niet, omdat hij aan het
vragende programma is gekoppeld en niet aan de gebruiker, en daarom kan een weigering verschijnen als een algemene
fout zonder vraag.
Het zichtbare teken scheidt de drie. Een wachtwoordvraag van de Finder is gewoon eigendom,
en authenticatie ruimt die op. Blokkeert Appbeheer de verwijdering, dan is er geen
wachtwoorddialoog. macOS plaatst meestal een banner in het Berichtencentrum die zegt dat de app is
tegengehouden bij het wijzigen van apps op je Mac, en de reparatie is de privacyschakelaar en een
herstart van de app, geen wachtwoord. Een "Operation not permitted" als root wijst op een bescherming die een
wachtwoord niet opheft. Appbeheer is er een van: zelfs `sudo` krijgt die fout
als de terminal die hem draait de toestemming mist. Andere beschermingen geven hem ook, dus
diagnoseer op pad en vragende app voordat je SIP aanneemt.
SIP kan zelfs root weigeren, maar de formulering van de fout alleen wijst de bescherming niet aan.
`EACCES` (`Permission denied`) kan ontbrekende schrijf- of zoektoegang tot een bovenliggende
map omvatten. `EPERM` (`Operation not permitted`) heeft oorzaken naast SIP. Controleer het precieze
pad, het eigendom, de bevoegdheden van de bovenliggende map en de vragende app voordat je een reparatie kiest.
Geen van beide meldingen is een reden om systeembescherming uit te zetten.
## 6. Een systeemextensie of netwerkfilter is nog actief
Beveiligingssoftware, vpn-clients en virtualisatieproducten installeren systeemextensies. De
bevattende app registreert de extensie, en losse bestanden verwijderen is geen betrouwbare
deactiveringsprocedure. macOS kan een systeemextensie verwijderen als de bevattende app
netjes naar de prullenmand is verplaatst, maar software van een leverancier kan andere geïnstalleerde onderdelen hebben.
Gebruik de verwijderprocedure van de leverancier en controleer de staat die daaruit volgt.
```
systemextensionsctl list
```
De uitvoer toont team-ID, bundel-ID en een staat zoals
`[activated enabled]`. Deactiveren hoort bij de bevattende app en heeft vaak een herstart nodig,
dus draai eerst de uninstaller van de leverancier.
[Antivirus verwijderen op de Mac](https://mole.fit/nl/blog/how-to-uninstall-antivirus-mac) behandelt de afbouw-volgorde voor deze klasse.
## 7. Het kwam uit de App Store, of uit Homebrew
**Apps uit de Mac App Store.** De bundel verwijderen haalt de aankoop niet weg. Het geval dat
mensen verrast, is de instelling die Apple formuleert als "Download automatisch apps die je
in de App Store op andere Mac-computers en apparaten hebt gekocht": koopt een tweede Mac op
hetzelfde account een app op een ander apparaat, dan kan de instelling die aankoop downloaden.
Een app gewoon geïnstalleerd houden op een tweede Mac bewijst op zich geen herinstallatie-oorzaak. Controleer de instelling in
**App Store › Instellingen**.
**Homebrew-casks.** Heb je geïnstalleerd met `brew install --cask foo`, dan laat de app naar de prullenmand slepen
Homebrew denken dat hij geïnstalleerd is. `brew list --cask` toont het token nog, en
de volgende `brew upgrade` kan de app die je net hebt verwijderd opnieuw installeren, een echte oorzaak van "hij kwam terug"
zonder launchd-taak. Draai in plaats daarvan `brew uninstall --cask foo`. De manpage van Homebrew
beschrijft `--zap` als het verwijderen van "all files associated with a cask" en waarschuwt dat het "may remove
files which are shared between applications", dus pak die bewust.
## Na een geslaagde verwijdering: wat achterblijft
**Inlogonderdelen en extensies toont het nog.** Ofwel een onderdeel "Open bij het aanmelden" dat naar een
ontbrekend pad wijst, of een record van Background Task Management voor een dienst waarvan het programma weg is.
Haal het weg met de minknop in **Systeeminstellingen › Algemeen › Inlogonderdelen en
extensies**. macOS ruimt deze vaak zelf op na een herstart.
**Er verschijnt bij het opstarten een menubalksymbool.** Iets laadt nog een binary: meestal een launch agent
die je nooit hebt verwijderd, of een helper die het installatieprogramma heeft gekopieerd naar
`~/Library/Application Support/`.
**Een hulpprogramma met extra rechten overleeft.** Software die root nodig had, installeert in
`/Library/PrivilegedHelperTools/
