How to Keep MacBook Awake With Lid Closed: 3 Scenarios Explained
Close your MacBook mid-download and it goes to sleep. Open it again and the task is dead. Most people's first response is to install a "keep awake" app, and most of those apps won't help, because they're solving the wrong problem. If you're searching for how to keep MacBook awake with lid closed, the answer depends on which of three distinct problems you actually have: open-lid idle sleep, Apple's supported closed-lid desk mode, or an unsupported battery-only workaround.
This guide covers all three, in order of complexity. The third path is the one guides usually bury or skip. It's also the one that matters most if you're running AI agent sessions, long builds, or overnight backups.
The key distinction to understand before anything else: apps built on Apple's caffeinate command work by holding a "prevent idle sleep" power assertion. They stop the system's idle timer. They cannot override what happens when the lid closes. That's a separate hardware event: the lid sensor fires a signal to IOPMrootDomain, macOS's kernel-level power controller, which then decides whether to sleep the machine, and by default, it does, as Mac Internals detailed in late May. The caffeinate-based apps never see that signal, by design, as Sleepless documents explicitly in its FAQ.
Only one of the three paths below is Apple-supported. The closed-lid-on-battery path is a workaround, functional and widely used, but not something Apple documents or guarantees across future macOS updates. That framing matters when deciding which approach fits your risk tolerance.
Prerequisites: Most steps in this guide work on earlier macOS versions. Wedge specifically requires macOS 14 Sonoma or later. The pmset-based steps in Scenario 3 require administrator access; built-in settings and caffeinate do not.
Scenario 1: Lid open, preventing idle sleep
If the lid stays open and you need to stop the system from nodding off during a presentation, screen recording, or long download, this is straightforward. Nothing here requires third-party software, admin access, or any workaround.
Step 1: Adjust built-in settings for your baseline. Open System Settings → Lock Screen and push out when the display turns off. On a MacBook, go to System Settings → Battery → Options and enable "Prevent automatic sleeping on power adapter when the display is off." This covers the most common case without installing anything, as 9to5Mac noted today.
Step 2: For temporary overrides, use the macOS caffeinate command in Terminal.
caffeinate -t 3600 holds the Mac awake for one hour. caffeinate npm run build keeps it awake until the specified process exits, clean and automatic, with nothing left running afterward. Kanaries recommends this specifically when the lid stays open and you want explicit terminal control.
Step 3: For a persistent menu bar toggle, use the KeepingYouAwake app for Mac.
Free, open-source, and built on caffeinate under the hood. One click activates it; another restores normal sleep. It supports timed sessions and auto-disables below a configurable battery level, per 9to5Mac. Its own documentation is explicit: it only prevents sleep on Macs with the lid open. Close the lid and the Mac sleeps regardless.
Close the lid and none of this applies. That's Scenario 2 or 3.
Scenario 2: Lid closed in a desk setup: Apple's supported clamshell mode
If you work at a desk with an external display, this is the clean path with no trade-offs. Apple officially supports MacBook operation with the lid closed when the machine is connected to power and paired with an external display, keyboard, and pointing device. IOPMrootDomain recognizes that combination and keeps the system awake without any third-party intervention, per 9to5Mac and Mac Internals.
Step 1: Connect your MacBook to power. Step 2: Connect an external display via USB-C, Thunderbolt, or HDMI with an appropriate adapter. Step 3: Connect a keyboard and mouse or trackpad, wired or Bluetooth. Step 4: Close the lid. The external display becomes the primary screen.
No software needed. No unsupported workarounds. If this setup fits your workflow, stop here.
When this isn't enough: no external display, or on battery, or both. That's what the next section covers, and why the tools there are more complex.
How to prevent MacBook from sleeping when closed on battery: the unsupported path
This is the scenario that launched several new tools in the past few weeks. You want to start a long-running task, close the MacBook, and walk away. No monitor, no desk, possibly no power cable.
This path works. But it's not Apple-supported, it requires admin access, and it introduces trade-offs the other scenarios don't. Read the risks before picking a method.
Quick decision: which tool fits which case
Before the comparison table, here's the short version:
- Want no install? Use raw
pmset. - Want App Store distribution and trigger automation? Try Amphetamine, but verify battery-only closed-lid behavior on your specific hardware first.
- Want built-in guardrails with a battery floor? Use Sleepless.
- Want better battery handling under a closed lid? Use Wedge.
Now the details behind those recommendations.
How it works
The command sudo pmset -a disablesleep 1 sets a kernel-level flag called SleepDisabled. Unlike caffeinate power assertions, this flag is recognized by IOPMrootDomain as a veto on sleep that persists through the lid-close event, as Sleepless confirms from firsthand testing on Apple Silicon. Verify it's active after setting it:
pmset -g | grep SleepDisabled output should read 1.
Restore normal sleep behavior when done:
sudo pmset -a disablesleep 0
If you want to check what's currently holding sleep at bay, pmset -g assertions lists every active sleep veto and the process holding it, as Mac Internals details in their power management documentation.
The risks: read before choosing a method
Forgetting to turn it off is the primary hazard. SleepDisabled persists until you clear it or reboot. Leave it set and your Mac won't sleep overnight, on a flight, or whenever you'd normally expect it to. Every method below addresses this differently; that's the main differentiator.
Battery drain from the internal display. Raw pmset disablesleep can leave the internal display running at full brightness under the closed lid, silently burning battery for hours. One tool specifically addresses this; the others don't, per Wedge's documentation. If battery efficiency matters, factor this into your choice.
Thermal limits. A closed lid reduces airflow through the keyboard deck. Light unattended work, such as downloads, syncs, or AI agent sessions that aren't pegging the CPU, is fine. Sustained heavy computation with the lid fully shut is where judgment is required, as Sleepless notes. Monitor temperatures with Activity Monitor or iStatMenus if uncertain.
Hardware-enforced sleep at critical battery. At a low enough charge level, macOS forces sleep regardless of what pmset says. This is enforced at the hardware level. There is no workaround, per Wedge.
When to skip this approach entirely: leaving the machine unattended for hours on battery running a CPU-heavy workload, such as a large model training run or a full project recompile, the thermal and battery risks outweigh the convenience. Plug it in or leave the lid cracked.
Choose your method
All four options use pmset disablesleep as the underlying mechanism. What they add around it is what differs.
| Raw pmset | Amphetamine | Sleepless | Wedge | |
|---|---|---|---|---|
| Lid-closed on battery | ✓ | Unclear: test on your hardware | ✓ | ✓ |
| App Store / signed | App Store | Ad-hoc signed | Ad-hoc signed | |
| Admin access required | Yes (terminal) | No | One-time sudoers rule | Keychain password |
| Battery safeguards | None | Trigger-based | Auto-off at floor (15% default) | Hardware limit only |
| Display sleep on lid close | No (display stays on) | Configurable | No | Yes (brightness → 0) |
| Auto-off timer | No | Yes (session rules) | 1h / 2h with countdown | No |
| Best for | Terminal users who won't forget to reset | Trigger automation, App Store requirement | Set-and-forget light tasks | Battery efficiency priority |
Raw pmset (Terminal): Right for users comfortable in the command line who are disciplined about the restore step. Two commands: enable before closing, disable when done. No extra software, no Gatekeeper prompts. Kanaries specifically recommends this for users who want explicit control and will remember to reverse it.
Amphetamine: The most capable option and the only one distributed through the App Store, which means no Gatekeeper warnings and no sudoers changes. Sessions can be tied to specific conditions, such as a particular app running, CPU above a threshold, or battery above a floor. Display sleep, screen locking, and system sleep behavior can also be configured independently when the built-in display is closed. Compatible with Intel and Apple Silicon Macs on macOS 10.13 or later, per Amphetamine's GitHub and 9to5Mac.
One important caveat, worth keeping front of mind rather than buried: Amphetamine's GitHub documentation describes its closed-lid keep-awake feature specifically in the context of operation with an external monitor. Whether it reliably keeps a MacBook awake on battery with no external display attached is ambiguous in the available documentation. Test your specific workflow before depending on it for unattended battery use.
Sleepless: An open-source AppKit app that wraps pmset disablesleep with an auto-off timer (1 or 2 hours, with a live countdown in the menu bar), a battery floor cutoff (configurable from 5-50%, defaulting to 15%), and an automatic reset when Low Power Mode activates. The installer adds a tightly scoped sudoers rule covering exactly two commands, the enable and disable pmset calls, nothing else. Ad-hoc signed; first launch requires right-click → Open, or build from source to bypass Gatekeeper entirely, per its GitHub repository. The right choice for light unattended tasks where safety rails matter more than trigger automation.
Wedge: Targets the same core use case but adds one distinct feature: when the lid closes, it sets the internal display brightness to zero, then restores it when you reopen. This directly addresses the battery drain problem that raw pmset leaves unhandled. Wedge uses a private DisplayServices symbol to control brightness, which App Store rules prohibit, so distribution through the App Store isn't possible, per Wedge's documentation. Requires macOS 14 Sonoma or later; Apple Silicon is recommended, with Intel untested. Admin password stored in Keychain; no network connections made. First launch requires right-click → Open. The right choice when battery efficiency under a closed lid is the primary concern.
Conclusion: quick reference and what to verify
Three questions determine which path to take. Is the lid open or closed? If closed, is there power and an external display? If not, how much setup friction and risk are acceptable?
- Lid open:
caffeinatein Terminal, or KeepingYouAwake for a menu bar toggle. No setup, no risk, no admin access. - Lid closed with power and external display: Apple's clamshell mode. Nothing to install.
- Lid closed on battery, no monitor: Sleepless if you want a set-and-forget tool with a battery floor; Wedge if saving battery under the closed lid is the priority; Amphetamine if App Store provenance matters, but verify battery-only behavior first; raw
pmsetif you want no additional software and will remember to reset it.
Whichever pmset-based method you use, two verification steps are worth building into the habit. Before closing the lid: pmset -g | grep SleepDisabled should return 1. After the task finishes: run sudo pmset -a disablesleep 0 and confirm the output returns to 0. If a tool seems not to be working, pmset -g assertions will show exactly what's holding sleep (or not) and which process is responsible, as both Mac Internals and Sleepless document.
The tools in the pmset category are recent, most launched or updated between May and June 2026, and independent testing across macOS versions and hardware generations is limited. Amphetamine has the longest track record by a wide margin. The others are young but purpose-built for exactly this workflow, and their source code is open for review before granting admin access to anything.
Comments
Be the first, drop a comment!