Guide

A safer alternative to pmset disablesleep

Search for how to stop a Mac sleeping with the lid closed and you will be told to run sudo pmset -a disablesleep 1. It works. It is also a system-wide switch with no owner, no expiry and no memory of why you flipped it — which is why so many people meet it twice: once when they turn it on, and once when they are trying to work out why their Mac has not slept in a week. Here is what it actually does, how to undo it, and what a scoped version of the same idea looks like — the shape Perked was built around.

What the command actually does

Most keep-awake tools take a power assertion: a polite, per-process request that macOS weighs up along with everything else. disablesleep is not that. It sets a flag on the power-management system itself that says sleep is off — not idle sleep, not display sleep, all of it, including the sleep that normally happens when you close the lid.

That is why it is the answer people reach for: it is the only setting that gets lid-closed behaviour without an external display. It is also why it is dangerous as a default.

• It is system-wide not scoped to an app, a job, or a terminal window. Nothing else on the machine can sleep either.
• It needs root hence the sudo and the admin password. A password prompt every time you want a long job to survive is friction you will eventually route around badly.
• It survives reboots this is the one that catches people. Restarting does not clear it; only setting it back to 0 does.
• It is invisible there is no menu-bar icon, no notification, nothing in Activity Monitor. The only evidence is a line in pmset -g.
• It has no idea what your Mac is doing it will hold a laptop awake on a dying battery, in a bag, at full thermal load, indefinitely. The flag has no opinion about any of that.

First: is it on right now?

Before anything else, check. If you have ever pasted that command, it may well still be set from months ago:

• pmset -g | grep SleepDisabled — 1 means sleep is disabled system-wide. 0, or no line at all, means you are fine.
• sudo pmset -a disablesleep 0 — turns it back off. Run the check again afterwards; it should read 0.
• pmset -g assertions — worth running too: this shows the *other* kind of keep-awake, the per-process assertions, in case something else is also holding the machine up.

If SleepDisabled is 1 and you did not set it, some app did — a keep-awake utility with clamshell support almost certainly. That is not automatically wrong, but it should be an app you can point at, and one that clears the flag when it is finished.

caffeinate: lighter, and honest about its limits

The built-in caffeinate command is the right tool for most of what people use disablesleep for. It takes an assertion rather than flipping a global flag, needs no password, and — importantly — dies with the process that started it, so a closed terminal window cleans up after itself.

• caffeinate -i ./long-job.sh — keeps the Mac awake for exactly as long as that command runs, then stops. This is the good pattern.
• caffeinate -w 4821 — holds until the process with that id exits. Useful for something you already started.
• caffeinate -t 3600 — an hour, then it lets go by itself. A timeout is always safer than a switch.

Where it stops: caffeinate cannot keep a MacBook awake with the lid closed. Nothing short of the disablesleep flag can. So the honest summary is that caffeinate is the safe option right up until the moment you need to shut the lid — and then you are back to the global switch, which is exactly the gap worth closing properly.

What a safe version of the same idea looks like

The flag is not evil; leaving it on is. So a safer version does not avoid disablesleep — it takes responsibility for it. Five properties are what separate the two:

• Scoped on only while something is actually running, off the moment it finishes. Not "on until I remember".
• Self-clearing if whatever set it crashes, is force-quit or the machine is yanked, sleep comes back on its own. This is the property the raw command lacks entirely.
• Power-aware a laptop on 8% battery in a bag should be allowed to sleep, whatever anyone asserted earlier.
• Thermal-aware a closed laptop under load has nowhere to shed heat. Getting too hot should end the session, not be ignored.
• Visible you should be able to see that it is on, why it is on, and read back afterwards what happened.

How Perked does it

Perked keeps the flag but takes the footgun off it. The privileged part is a small helper that macOS installs as a system daemon — you approve it once in Login Items, and after that there is no admin password again. The app talks to it over XPC and asks for the flag only while a session is genuinely live.

The self-clearing property is the part worth spelling out, because it is the one you cannot build with a shell command: while keep-awake is on, the app sends the helper a heartbeat every 30 seconds. If the helper goes 90 seconds without one — the app crashed, you force-quit it, something went wrong — it turns sleep back on by itself. There is no state in which a dead Perked leaves your Mac permanently awake.

Around that sit the other four properties: it switches on when it detects a coding agent (or any process you nominate) and off when that finishes, it can require AC power or a battery floor you set, it pauses when the Mac runs hot, and it journals every switch so you can read back why a run ended. And because it is the same underlying flag, you can always audit it the same way — pmset -g | grep SleepDisabled while a session runs, and again after it ends.

Frequently asked

← Back to Perked