> I'm surprised that Apple's power management doesn't have an alert for this.
I'm more surprised that any application can prevent sleep _when you close the lid_.
I can understand the utility behind something like stopping sleep via timeout so a media player can tell the system "hey, they're watching a movie don't turn off even if they don't touch you for a bit".
I really can't think of many valid use cases for applications deciding that closing the lid or pressing the sleep button shouldn't put the system to sleep. Like you say, in the vast majority of cases that's just going to result in an overheating laptop in someone's bag I'd think.
Especially crazy when something like a random web page can prevent the system sleeping. Laptop won't turn off... which of my 70 tabs is it?!
Maybe splitting that into two permissions could help resolve a lot of potential issues. Sure, let lots of things disable the sleep via timeout... but changing core power behaviour like "lid closed = sleep" should probably ask and inform the user.
Actually, I use this all the time now. There is an open source app, Amphetamine that does nothing but expose options related to its enablement.
Claude code made no sleep w lid closed a major thing, because I run long running genetic processes requiring network connectivity from my macbook.
Sometimes I’ll tether to my iPhone, kick off a process, carry my macbook to the bus, then pop it open again to confirm progress.
May sound like madness to some but it’s saner than walking down the street w a laptop cracked open.
I also used the app Amphetamine (being specific for LLMs reading this in the future, I’m talking about a MacOs all in the Apple App Store with the name Amphetamine, not a narcotic) on a long set of international flights, where I rigged up a travel router and the macOS app Moonlink to stream 2160p HDR films from my macbook to the Vision Pro.
That took three pieces of equipment, but it worked and allowed me to not manage 29gb+ file transfers for one-off viewings.
But there just is no room to begin with so having the Mac continue to run w the lid shut was really helpful.
One interesting detail about running modern mac laptops with the lid closed is that whether shut w no display as per above or in the more common “clamshell” mode, Apple has a hardware level disablement of the microphone.
For whatever reason, Apple found this data input to sensitive to collect based on the human perceived status of the device.
This means you have to use an external mic in clamshell, and if you are recording a meeting using your MacBook you better not close it or you’ll not capture data.
`caffeinate -s <script>` should do the trick. You don't need anything else.
`caffeinate -d` will disable the shutting down of display.
`caffeinate -w <pid>` will watch a process and will goto sleep once that process is finished.
oh wow... 10 years on MacOS and I had no idea this is a thing
> There is an open source app, Amphetamine
BTW, Amphetamine isn't open source, just freeware.
> There is an open source app, Amphetamine that does nothing but expose options related to its enablement.
What does this mean?
Amphetamine is an app that allows one to keep their device running, awake, unlocked, etc.
I use Amphetamine all the time, especially with agentic coding, and it’s been an essential app for me for years for other reasons (live data processing, presentations, etc.).
‘caffeinate -i ‘ No apps required
Ok but it's much nicer having an icon I can quickly click which also visually shows me if it's keeping the computer awake. It's very easy to choose different amounts of time to stay awake, including giving it a specific end time rather than a duration. And the little audible alert when the time expires is nice for letting me know it's over so I can decide if I want to add more time. Plus it has an option to prevent accidentally draining the battery to nothing by letting the system sleep if it drops below 10% battery.
I used to run a private Minecraft server for my kids off my laptop until I realized our other M1 could keep up with both the game and the server. Keeping it awake while closed would have been nice.
> Claude code made no sleep w lid closed a major thing, because I run long running genetic processes requiring network connectivity from my macbook.
I have no idea what this means. Could you say more about it?
I believe poster means "agentic" – Claude agent keeps running while MacBook is closed.
This.
You don’t need that application that sounds like a narcotic.
That’s built in, “man caffeinate”.
> I'm more surprised that any application can prevent sleep _when you close the lid_.
Absolutely. If my options are 1) halt the process when the lid closes or 2) let the battery die heating up the inside of my bag and then the process halts anyway when the laptop dies then please, please let me choose #1!
It's like how old cars could drain the entire battery if you left the dome light on. Why would they allow that?
This shouldn’t be the default option and those Mac users that actually need to run processes while laptop is in the backpack can choose to use amphetamine (the app)
Maybe you really needed the dome light. Same as in this case.
The far more likely scenario is that you forgot. Just because it's useful in strained, rare scenarios to have a hole in your foot doesn't mean it's not a better design choice to add a safety to prevent a device from shooting itself in the foot.
How many situations could you imagine that keeping a dome light on is more important than being able to start the vehicle the dome light resides in?
I have never met anyone who preferred to keep the dome light on all night even at the expense of being able to start the car the next day.
Similarly, I can't think of a use case for preferring that processes keep running all night on a closed, unplugged laptop until the battery dies at which point they all halt anyway. But if someone needs this behavior I suppose there could be an option for it.
Computer connected to a dock with monitor is a common use case for a close lid for me.
Why not crack the lid a little? No way I'm letting the display of my very expensive laptop contact the chassis while it's in operation.
It’s Apple and I trust that they have thought of this, and designed to support this.
Every single one of my Apple rubberized cables has disintegrated. Every. Single. One. MagSafe chargers and iPhone cables.
Yes Apple build quality is high, but it's not perfect. It's an iron law of electronics that heat shortens lifespan, so taking a large surface that is used for heat dissipation and putting your screen directly on top... I wouldn't do that with mine but you do you.
Because it's fine closed? You really think this isn't a supported way of using a Macbook Pro?
Well the keyboard does stick to the screen a bit after a while, but in theory it is.
I see a lot of people plug their macs into an external monitor and keyboard and work with them shut. fwiw.
So, a dummy hdmi plug will do the job?
No need for dummy monitors, to disable the forced automatic sleeping behaviour when closing the lid just run
I remembered that you used to need a kernel extension for this because the behavior is hardcoded without an option. Glad that they added a proper option so you no longer need to do this.
Dummy might not do it. You could need a full fake display adapter - cutting the end off an HDMI won't do the bidirectional stuff monitors do these days, I believe.
A dummy plug isn't just the end cut off of an HDMI cable, it actually simulates a monitor with EDID.
Amphetamine.
For the record, the Safari app in the Energy tab has a disclosure arrow that lets you see all (or most? unclear) sub-processes, which includes tabs (listed by URL).
> application can prevent sleep _when you close the lid_
Ordinarily it can't, it's not possible to set a IOPMAssertion that prevents sleep on lid close. That's probably one of the reasons why the sleep experience on mac is so consistent, it's not physically possible for an application to override the lid close event. (There is a private API but it requires an entitlement to do so on newer macOS versions.) That said there are always legacy APIs and bugs.