Keep Your MacBook Awake With the Lid Closed: AwakeToggle

I run Claude Code sessions that keep working after I walk away from my desk. Long agent runs, background jobs, remote access from my phone. Then I close the lid to leave the house, and macOS sleeps — the session stops mid-task, the SSH connection drops, and whatever was running is gone.

The fix is one command. I'll give it to you first, because you may not need my app at all.

The actual command

sudo pmset -a disablesleep 1

That's the whole feature. pmset is Apple's own power-management tool, already on your Mac. disablesleep 1 tells the system not to sleep when the lid closes. Set it back to 0 to restore normal behavior.

If you're happy typing that, you're done — bookmark this page and move on. The rest of this post is about why I still wrapped it in an app.

Why caffeinate isn't the answer

The usual advice is caffeinate, and it's the wrong tool here.

caffeinate creates a power assertion — it asks the system to hold off on idle sleep. That covers "my screensaver kicked in during a long build." It does not cover closing the lid. A lid close is a different path: it's an explicit user request to sleep, and no assertion overrides it. Run caffeinate -disu, close your MacBook, and it sleeps anyway.

pmset disablesleep works at a lower level — it disables the sleep path itself, lid switch included. That's why it needs sudo and caffeinate doesn't.

Same for Apple's built-in clamshell mode: it keeps the machine awake with the lid shut, but only with power and an external display and an external keyboard or mouse attached. Sitting in a café with just the laptop, it doesn't apply.

So why an app

Three things the raw command doesn't give you:

1. No indicator. Nothing in the UI tells you whether sleep is currently disabled. You have to run pmset -g | grep SleepDisabled to find out.
2. Which means you forget it's on. This is the real problem. Sleep stays disabled until you explicitly turn it off — a reboot doesn't clear it. Forget, and your laptop keeps running inside a closed bag, burning battery and trapping heat.
3. sudo every time. Enough friction that you don't bother for a 20-minute errand.

An always-visible menu-bar icon fixes all three. You can see the state without thinking about it, which means you notice when it's still on.

AwakeToggle

Download AwakeToggle.zip — 52KB, macOS 12+, universal (Intel and Apple silicon). Source: github.com/machinefriendly/awaketoggle

• Left-click the icon — toggle instantly
• Right-click the icon — open the menu
• Closed-laptop icon = stay-awake is on
• Open-laptop icon = normal sleep

The UI follows your system language — English, 中文, or Français, with anything else falling back to English.

Toggling pops the standard macOS admin password prompt. That's the system's own authorization dialog — the app never sees or stores your password, and it doesn't install a privileged helper or add a passwordless-sudo entry to keep one from appearing. I'd rather type the password than leave a permanent hole in the system's auth config for a convenience toggle.

It doesn't phone home, collect anything, run a background service, or launch at login.

"Apple could not verify this app is free of malware"

You'll hit this on first launch. It's expected, and it's worth understanding what it actually means.

It is not a malware detection. macOS didn't scan the app and find something. That message appears for any app that hasn't been through Apple's notarization — regardless of whether it's safe. Notarization requires an Apple Developer account at $99/year.

I didn't buy one. AwakeToggle is a 52KB tool I wrote for myself and gave away; paying a yearly subscription to distribute it for free doesn't add up. So the warning is the honest cost of it being free, and you should treat it the way you'd treat any unsigned binary from the internet: don't take my word for it.

Don't trust me, read it

• The entire source is one Swift file, ~240 lines. That's a two-minute read, not a code audit.
• The only privileged thing it does is the pmset line above.
• You can build it yourself in one command (below) and get the same app.

That's a better security story than a signature. A notarized app can still do anything it wants — the certificate proves an identity paid Apple, not that the code is good. 240 readable lines prove more than my $99 would.

Opening it

1. Unzip, drag AwakeToggle.app to Applications
2. Double-click → blocked → click Done (not "Move to Trash")
3. Open System Settings → Privacy & Security, scroll down to "AwakeToggle was blocked"
4. Click Open Anyway → confirm once more
5. Done. It won't ask again.

On macOS 15 and later, the old right-click → Open shortcut no longer works — Apple removed it. The Privacy & Security route above is the only way now, which is why a lot of tutorials you'll find are out of date.

Build it yourself

No Xcode needed, just the command line tools:

xcode-select --install     # if you haven't already
git clone https://github.com/machinefriendly/awaketoggle.git
cd awaketoggle
./build.sh

That produces a universal binary targeting macOS 12+, ad-hoc signed, packaged into the same zip I ship. If you build it yourself, the Gatekeeper warning is still there — an ad-hoc signature is an ad-hoc signature regardless of who compiled it — but now it's your binary from source you've read.

Before you turn it on

Heat and battery. Sleep stays disabled until you turn it off — rebooting doesn't reset it. A Mac that keeps running inside a closed bag has nowhere to dump heat and will drain to empty. Watch the icon, and turn it off when you're done.

This is genuinely the main risk of the tool, and the reason the menu-bar indicator exists rather than a fire-and-forget script.

Requests

It does one thing right now. If you want something more — scheduled windows, auto-off below a battery threshold, launch at login — open an issue. I'd rather hear a real use case than guess at features.

If enough people end up using it, I'll reconsider the developer certificate so the warning goes away.