Amphetamine: how to uninstall it cleanly

There are two reasons people uninstall Amphetamine, and they lead to different work. One is that the app is no longer used and the leftovers should go with it. The other is that the menu bar has run out of room and something has to give, in which case removing the app may not be the right move at all. Either way the cleanup is unusually contained, because the app ships through the Mac App Store and store apps are sandboxed, which limits where anything can be written. This covers the check worth running before you start, the removal itself, the three locations that survive it, and the one file that deserves care.

Find out what is actually holding sleep open

Run this before removing anything. Open Terminal and run pmset -g assertions. The output lists the current power assertions on the machine, then a section headed "Listed by owning process" showing which processes are holding them.

The two lines that matter are PreventUserIdleSystemSleep and PreventUserIdleDisplaySleep. A value of 1 means something is actively keeping the Mac or the display awake, and the process list below names it. If the app you are about to delete is not in that list, then deleting it will not change the behaviour that prompted this, and the real cause is elsewhere. Video playback, conferencing apps, file sharing, Time Machine and screen sharing all take assertions of their own.

This is worth the thirty seconds because the alternative is uninstalling, finding the Mac still refuses to sleep, and starting the diagnosis over with one less variable to test. Running the same command again after removal closes the loop: the count should drop to 0 and the process should be gone from the list.

Removing the app

The removal itself is ordinary. End any running session, quit the app from its menu bar item, move it from the Applications folder to the Trash, and empty the Trash. Deleting from Launchpad achieves the same thing.

Quitting the app releases its power assertions immediately, so a session left running is not a problem in itself. The order matters only if you plan to verify with the command above, where a clean before and after reading is easier to read when the session was ended first.

If any triggers were configured, write them down before the app goes. There is no export function to fall back on, and the settings live inside a container folder that is tied to the machine and the user account rather than being a portable document. Three lines in a note, naming the condition and what each trigger did, is enough to rebuild the setup later or to reproduce it on a different Mac. This takes a minute and removes the most common regret, which is not the deletion itself but the half hour spent reconstructing conditions that took weeks to settle on.

One fact makes this decision lower stakes than it looks. The app is distributed free on the Mac App Store, so once it has been downloaded it stays in the purchase history of the Apple Account used. Reinstalling later takes a search and a click, with no licence key to locate and no reactivation step. Removing it to see whether the machine behaves differently is a reversible experiment rather than a commitment.

What stays behind

Sandboxing keeps app data inside a small number of predictable locations. That is convenient during cleanup, because the list is short and nothing is scattered across the system. Three places are worth checking.

Location	Contents	Safe to delete
Library/Containers/com.if.Amphetamine in your home folder	Preferences, triggers, custom icons and sounds	Yes, if you do not want the configuration back
Library/Application Scripts/com.if.Amphetamine in your home folder	The Power Protect script, if it was installed	Yes, once the app is gone
/private/etc/sudoers.d	The Power Protect configuration file, if it was installed	Read it first, see below

The container is the one everybody has. It holds the settings, meaning session defaults, every trigger that was configured, any custom menu bar image and any custom notification sound. Deleting it discards all of that. Keeping it means a later reinstall picks up where things left off, which is the reason to leave it in place if the removal is a trial rather than a decision.

The other two exist only if Power Protect was installed, which applies to Apple Silicon Mac laptops used with the lid closed. If that was never set up, those folders were never created and the container is the only cleanup needed.

It is worth understanding why the list is this short, because generic uninstall checklists written for directly downloaded software send people hunting through /Library/Application Support, /Library/Preferences, /Library/Caches and the LaunchAgents folders. Store apps are sandboxed, and a sandboxed app writes into its own container rather than into those system locations. Preference files that would normally sit loose in the user Library are redirected inside the container as well, which is why the preference domain used by the setup command is not found at the path an older guide would tell you to check. Searching those folders for the app name is harmless, and it will come back empty.

Verifying the removal took effect

Two quick checks confirm the job is finished. Run the assertions command again and look for the process to be absent and the counts to read 0, which proves nothing is still holding the display or the system awake. Then look at the menu bar itself: the remaining icons shift right to fill the gap, and on a Mac with a notch an item that was previously pushed out of the visible area may reappear. That second effect is the one people are usually after, and seeing it or not seeing it tells you whether the space problem was caused by this app or by the ten others still installed.

The sudoers file needs different handling

Power Protect is not bundled with the app. It is two files that the person setting it up downloads and places manually, and the repository states both destinations:

Download the Power Protect script and install it in the following location: /Users/YourUserAccount/Library/Application Scripts/com.if.Amphetamine/ Download the Power Protect configuration file and install it in the following location: /private/etc/sudoers.d/ Source: github.com, instructions checked 10 September 2026

The script lives inside your home folder and can go to the Trash like anything else. The second destination is different in kind. Files in /private/etc/sudoers.d define what may be run with administrator privileges, and a malformed file there can break privileged commands across the whole system.

Handle it in this order. List the folder contents and identify the file that belongs to the app. Copy it somewhere else first so the change is reversible. Delete it. Then run sudo visudo -c, which validates the entire configuration and reports any syntax problem it finds. A clean result means privileged commands are unaffected. If the folder holds nothing related to the app, there is nothing to do here at all, and that is the usual case.

The Terminal command used during setup to enable the feature writes a preference into the app domain, which lives inside the container. Deleting the container removes it, so no separate step is required.

The helper app is a separate removal

Anyone who set up triggers based on arbitrary running processes will also have Amphetamine Enhancer installed. That helper is distributed as a disk image on GitHub rather than through the store, so removing the main app leaves it untouched.

Remove it the same way: quit it, then move it from Applications to the Trash. Two extras are worth a look. The downloaded disk image often sits in the Downloads folder taking up space, and if the image is still mounted, eject it before deleting the file.

If the name does not look familiar, the helper was probably never installed, and this section can be skipped. A quick scan of the Applications folder in alphabetical order settles it in a few seconds, since the two names sort next to each other.

Login items and notification entries

Deleting an app usually removes its system settings entries along with it, but two lists are worth a glance at the end.

The first is login items. If the app was set to start automatically, an entry exists in System Settings under General, in the Login Items section. A stale row there does nothing harmful, but it makes the list longer and harder to scan when you next need to audit what starts with the machine.

There is a related habit worth adopting while you are in there. Login items accumulate quietly, because every utility that offers to start automatically adds one and almost none of them remove the entry when their app is deleted by hand. Reading the whole list once, rather than only the row you came for, usually turns up two or three entries for software that left the machine months ago. Each one costs a little launch time and a little menu bar space, and clearing them is the same work as the cleanup already in progress.

The second is notifications. Each app gets its own row in the Notifications list, and rows sometimes persist after removal. Again this is cosmetic. The reason to clear it is the same reason this article exists: a long list of things you no longer use makes the one you are looking for harder to find. Setting names and locations shift between macOS releases, so check the current layout at Apple Support if a section is not where expected.

Put the energy settings back

People who install a keep-awake utility often adjust the system energy settings at the same time, and those adjustments outlive the app. A display timeout stretched to a long interval, or automatic sleep switched off entirely, keeps working after the app is gone, which produces the confusing result of a Mac that still refuses to sleep with nothing installed to explain it.

Run pmset -g assertions once more to confirm no assertion remains, then review the sleep and display timings in System Settings under Lock Screen and Battery. Restoring those values is the last step in returning the machine to its original state.

The reverse case is worth naming too. If the goal was simply that the Mac never sleeps while plugged in, the system settings alone may cover it, and the app was solving a problem that only exists for timed or conditional cases. Sorting out which of the two you need often decides whether anything needs to be reinstalled later.

What to change first

If the reason for removal is menu bar space rather than the app itself, try hiding the icon before deleting anything. A menu bar manager for macOS changes where an icon is drawn, not whether the app runs, so sessions and triggers continue exactly as before while the slot is freed. Icons you rarely click are the right candidates, and Koffret keeps hidden ones reachable without unfolding the whole bar, which is the part that decides whether hiding is a real substitute for removing.