Amphetamine not working on Mac: what to check

The switch is on and the Mac went to sleep anyway. Or the icon is no longer in the menu bar. Or everything works except the one case that matters, which is closing the lid with an external display attached. All three get described the same way, and all three have different causes in different places. Working through them in a fixed order costs less than changing settings and hoping, because a fixed order tells you when to stop.

Sort the symptom first

Three buckets cover nearly everything reported about this app, and they do not overlap.

The first is that nothing is visible. No icon in the menu bar, and no certainty about whether the app is even running. This is a process and display question, not a sleep question.

The second is that the icon is there, a session has been started, and the Mac sleeps regardless. This is a question about whether macOS received the request at all.

The third is that sessions work in general but fail in one specific situation: lid closed, or a trigger tied to a particular app, or a rule based on network conditions. This is a question about a feature's constraints, and it usually has a documented cause rather than a bug.

There is also a fourth possibility that gets misfiled as a bug in this app: something else on the Mac is doing the sleeping or the not sleeping. Checking that takes one command and belongs before any setting is touched.

Ask macOS which process is holding sleep

macOS keeps a live list of every assertion against sleep and who owns it. In Terminal:

pmset -g assertions

The output has two halves. The top half is a tally by type. PreventUserIdleSystemSleep is the system idle assertion, PreventUserIdleDisplaySleep covers the screen, and PreventSystemSleep is documented as valid only while running on AC power, which alone explains a class of "works at the desk, fails on battery" reports.

The half that answers the question starts at Listed by owning process:. Every process currently holding an assertion is named there, along with which type it holds and for how long. Start a session, run the command, and read that list.

If the app is not named, the request never reached macOS. Nothing inside the app's preferences will fix that, and the next step is the process and permission checks below. If the app is named but the Mac still sleeps, compare the type it holds against what is actually wanted. Blocking system idle sleep does not keep a display lit, and a session configured to allow display sleep is doing exactly what it was told while looking broken.

The same list solves the opposite complaint. When a Mac refuses to sleep, the owning process section names the culprit, which is often audio output, a backup agent, a virtual machine, or a software update rather than the keep-awake app. Confirming that before changing anything saves an hour of adjusting settings that were never involved.

Reading the rest of that list

The owning process section is worth reading properly rather than searching it for one name, because the extra lines under each entry usually say why an assertion exists.

Entries created by the built in caffeinate tool show the duration they were asked to hold and when they will release, in the form of a timeout and an action to take when it fires. An assertion with a timeout will disappear on its own, so it is not the explanation for behavior that persists for hours.

Audio is the entry that surprises people most. The audio daemon holds a system idle assertion on behalf of whichever application is playing, and the line names that application's process ID rather than the daemon. A browser tab with a paused video, a conferencing app left open after a meeting, or a music player minimized somewhere can keep a Mac awake for as long as it holds the output device, and none of that involves the keep-awake app at all.

Backup agents, software update, and virtual machines appear the same way, each with a named assertion describing what it is protecting. Reading the names is faster than guessing, and it settles arguments about which app is responsible before any settings are changed.

If the keep-awake app is named in that list while a session is supposed to be off, the session is not off. Timed sessions and triggers can restart one through a path other than the switch that was pressed. Disabling every trigger, then re-running the command, separates "the switch did not work" from "something turned it back on", and those two have completely different fixes.

The icon is not in the menu bar

Two different things produce an empty spot, and they need different responses.

The app may not be running. Check Activity Monitor, or run pgrep -l Amphetamine in Terminal. Nothing returned means nothing is running, so launch it and then look at whether it is registered to open at login. An app that has to be started by hand after every restart tends to be blamed for failures that are really absences.

Or the app is running and there is no room to draw the icon. Menu bar items fill from the right and stop where the application menus begin. Once that space is used up, further items are simply not shown. On a MacBook with a notch, the ceiling arrives noticeably earlier because the notch consumes the middle of the bar. The app is healthy in this state and the session may well be active. It just cannot be clicked.

Apple documents rearranging as a Command drag on the icon, and removing a status menu by Command dragging it out of the bar. That is written about the status menus macOS itself provides. How far an item supplied by a third party app can be moved or removed depends on that app, so treat reordering as a first attempt rather than a fix. When the count of items exceeds the available width, reordering only changes which one disappears.

Closed-display mode on Apple silicon laptops

This case deserves separating from everything else because it has a published cause and a published remedy that most people have never installed.

On Apple Silcon Mac laptops, Closed-Display Mode may not work as expected after connecting or disconnecting your Mac from an external power source such as a power adapter or display with power delivery. To avoid any issues, you can install a script and configuration file that addresses the issue. Source: github.com

The remedy is called Power Protect and it is not part of the app. The published instructions place a script in ~/Library/Application Scripts/com.if.Amphetamine/, a configuration file in /private/etc/sudoers.d/, and then set one preference from Terminal. The reason for the separate install is the App Store sandbox: an app distributed through the store cannot put those files there on a user's behalf.

So a lid-close failure on an Apple silicon laptop may not be a misconfiguration at all. It may be a missing second install. Intel machines and desktops are outside the scope of this one, so a failure there points somewhere else, usually to display or power settings in System Settings.

Triggers that never fire

Conditional sessions have their own failure mode, and it also traces back to sandboxing. An App Store app cannot enumerate every process running on the Mac, which limits what can be named in a condition.

That gap is filled by a separate helper distributed outside the store, Amphetamine Enhancer, which its documentation describes as adding a fail safe for closed-display mode and allowing all running processes to be used with triggers and app based sessions. A trigger that refers to something the app cannot see will never fire, no matter how the rule is written.

When a trigger does nothing, check three things in order. Is the target actually selectable in the app's list, or missing entirely. Is the condition genuinely true right now, which matters for rules keyed to a Wi-Fi network name, an IP address, or a mounted volume that has since changed. And are two rules cancelling each other, one starting a session while another ends it. Disabling every trigger and re-enabling one at a time resolves this faster than reading the rules.

Settings that will not stick, and permissions

Preferences that revert on relaunch point at the container rather than the app. Store apps write settings inside their own sandbox container, and anything interfering with writes there produces exactly this symptom. Cleaning utilities and backup tools that include container paths are worth ruling out.

Reinstalling only helps if the settings go too. Quit the app, remove it, then remove what it wrote before installing again. Otherwise the same state returns with the fresh copy and the reinstall looks like it did nothing.

Missing notifications are a separate matter with a separate switch. macOS holds per app notification permissions in System Settings, and an app denied there will run sessions correctly while appearing silent. This is the general shape of permission problems on modern macOS: the behavior looks like an application defect and lives in the operating system's settings. Panel names move between releases, so confirm the current wording in Apple's support material instead of following an older walkthrough.

Know what version you are debugging

One fact frames all of the above. Apple's published App Store data, read on 10 September 2026, lists the current version as 5.3.2, dated 10 November 2023, requiring macOS 10.13 or later, free, with no in-app purchases. Several major macOS releases have shipped since that date.

The release notes for that version mention a crash fix related to Bluetooth privacy settings access on macOS Sonoma and a warning added for running under Rosetta. Anything that changed in macOS after November 2023 has, by definition, not been addressed. That does not mean the app is broken today. It means a symptom that traces to a recent macOS change has no fix scheduled, and the practical response is a workaround rather than waiting.

One more thing about looking for help: the developer's support knowledge base redirects to a login screen as of 10 September 2026, so article URLs that surface in search results may not open. The sources that remain publicly readable are the App Store listing text and the developer's public repositories.

What to change first

Run pmset -g assertions with a session active and read the owning process list. That single output separates "the app is not being heard by macOS" from "the app is doing something other than what was wanted", and every later step depends on which of those is true. If the icon itself is the problem rather than the session, that is a menu bar capacity question rather than a bug, and Koffret documents how items stay reachable once the bar runs out of room. What the category does in general is set out on How it compares, and the questions that come up on day one, including macOS requirements and permissions, are collected on the FAQ page.