I certainly don't mean to imply that the causal arrow points from launchd to power state; the opposite, actually! I'm just working to better understand Mac sleep. (And yep, pmset -g is a fun little corner!) The reason I am interested in the precise details of when StartCalendarInterval ends up running a job is that the available resources and limits of a Mac are different in these different power states. I have to code with that in mind. Re:my scheduled job I fear it will cause you fine and patient Apple folk to bristle, as its purpose is to work around Time Machine, uh, "changes" I have encountered. To wit: "Time Machine did not finish backing up because some files were unavailable. Backups will resume when your Mac is unlocked." can be avoided by keeping the Mac awake and unlocked (caffeinate -d) during backup. Time Machine *.sparsebundle "disk not ejected properly" errors can be prevented by using a script-assisted backup that verifies unmounting prior to sleep. And I can speculate all day about changes to the SMB stack or whatever the root cause that makes my macOS 26 machine require 8 hours of trying to complete before it fails a backup, but I know that debug.lowpri_throttle_enabled=0 before backup gets me to a successful backup in about 2 hours. SO, this particular job schedules a script that applies all of these workarounds, executes tmutil startbackup --auto --block, and cleans up afterward. (And my apologies, I do realize this has strayed far from my posted topic/title. Thanks for reading =-)

Well I committed the cardinal sin of not eliminating enough variables before debugging. Time to set the record straight! Here's what I learned: Above, I was wrong: in fact, macOS 26, 15, 12 (and earlier!) all DO exhibit this behavior: running a CalendarInterval scheduled job when MacBook is sleeping. The differentiator is not the OS version but the state of the lid -- lid open while asleep and you get the DarkWake behavior: launchd runs your job, it may still get suspended until a full wake Lid closed while asleep - behavior is as described here -- your job does not run in any way until the lid is opened I don't know what desktop Macs do here (no lid!). There is a PowerNap boolean key used by Apple in /System/Library/LaunchDaemons/ *.plists, but I wasn't able to suss out its behavior, and it only seems to be used in a com.apple.xpc.activity dictionary. If you'd like to give this a go for your own devices, dear reader, I wish you luck. I was mis-attributing OS version to this launchd behavior, when it was actually that two of my test machines had different lid states. Mea culpa! The title of this thread, therefore, should read "launchd StartCalendarInterval behavior depends on lid state" And thanks again, Etresoft.

Thank you for your insight - that's a good piece of the puzzle! I found the DarkWake session: WWDC 2012, Session 711, "Power Management" with Ethan Bold and Soren Spies. Sadly, I can't blame DarkWake because it has been around since 2012, but I only see this unexpected wake on newer macOS. Since I'm using StartCalendarInterval on different versions, here's what I see: macOS 12 and earlier behave as expected; sleep through the CalendarInterval macOS 15 & 26 dark wake at the CalendarInterval Perhaps Apple changed launchd to be capable of scheduling a dark wake. My guess is there is a Launch[Agent|Daemon] *.plist key that can be used to change this behavior. I'll fire up BBEdit and go spelunking through /System/Library/LaunchDaemons/ to see if I can find a relevant key. Of course, if this was documented, I wouldn't be left wondering if I should file a bug report!