[macOS] Scheduled automation returns to sleep after dispatch during DarkWake

Open 💬 3 comments Opened Jul 22, 2026 by mtarnovan

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.72028 (5706)

What subscription do you have?

Not relevant to reproduction

What platform is your computer?

Darwin 25.5.0 arm64 arm

macOS 26.5.2 (25F84), MacBookAir10,1 (Apple M1), connected to AC through an Apple Studio Display in closed-clamshell mode.

What issue are you seeing?

A local scheduled automation was dispatched while the Mac was in DarkWake, with the Codex app running and sleep prevention enabled. The turn started, but macOS returned to sleep 45 seconds later. The automation then made no meaningful progress until a full user-activity wake, after which it resumed and completed shortly afterward.

Observed timeline (local time):

09:13:33  Codex scheduled automation turn dispatched
09:13:34  DarkWake from Deep Idle ... rtc/SleepService, Using AC
09:14:19  Entering Sleep due to 'Sleep Service Back to Sleep', Using AC
10:17:33  Full Wake ... UserActivity Assertion, Using AC
10:23:57  Automation completed

The automation had only about 12m45s of active execution but roughly 57 minutes of suspension/wall-clock delay. Waking the Mac through user activity allowed it to finish.

This makes unattended local scheduled automations unreliable: Codex can dispatch and mark a turn active during a short maintenance wake, but that active turn does not keep the machine awake long enough to finish.

What steps can reproduce the bug?

On a Mac connected to AC, remain logged in with the Codex desktop app running.
Enable Codex's sleep-prevention / “Prevent sleep while running” behavior.
Leave normal system sleep enabled (in this case AC system sleep was 10 minutes; display sleep was allowed).
Create a local scheduled automation whose work lasts more than a minute and uses normal app/plugin calls.
Let the Mac enter system sleep before the scheduled time.
Allow the scheduler to dispatch the automation during a maintenance DarkWake without interacting with the Mac.
Inspect pmset -g log: the automation turn starts, but macOS records Sleep Service Back to Sleep shortly afterward.
Wake the Mac through user activity. The same turn resumes and completes without another instruction.

What is the expected behavior?

Once a scheduled automation has dispatched and has an active turn, Codex should keep the Mac sufficiently awake to complete that turn, while still allowing display sleep. On AC power, this could use a bounded PreventSystemSleep assertion (or equivalent) that is released when the turn completes.

A scheduled turn should not remain suspended until the user wakes the Mac.

Additional information

Codex's current macOS sleep inhibitor requests PreventUserIdleSystemSleep:

https://github.com/openai/codex/blob/main/codex-rs/utils/sleep-inhibitor/src/macos.rs

That assertion does not prevent the observed Sleep Service Back to Sleep transition during DarkWake. A bounded external workaround using pmset repeat wakeorpoweron followed by /usr/bin/caffeinate -s (PreventSystemSleep, AC only) keeps the same automation reliable without preventing display sleep.

Related issues:

#23294 reports the general “Keep this Mac awake” setting failing to prevent sleep, but does not document an already-dispatched scheduled turn returning to sleep during DarkWake.
#32425 concerns scheduled tasks and a ChatGPT Classic interaction, not this power-assertion sequence.
#31584 is an adjacent automation stall caused by an app tool call/UI activation, not confirmed system sleep.

I searched open issues for DarkWake, Sleep Service Back to Sleep, and the two assertion names and did not find this exact automation failure signature.

View original on GitHub ↗

3 Comments

BRO3886 · 15 days ago

I reproduced this on two consecutive nights with a more severe outcome: after the scheduled turn was dispatched during DarkWake and the machine returned to sleep, the Mac eventually became unable to wake and required a forced restart. One incident produced a retained SOCD report with AP watchdog expired and reset fault wdog,reset_in1.

Environment:

Desktop app: 26.803.41515 (bundle build 6321)
Bundled CLI: 0.147.0-alpha.6.5
Hardware: MacBookPro18,3, M1 Pro
OS: macOS 15.7.3, build 24G419
Power: battery, closed lid

First incident, 2026-08-12 local time:

01:42:30  Clamshell sleep
03:05:45  DarkWake from Deep Idle, rtc/SleepService
03:05:50  Scheduled-task session created
03:23:07  Next DarkWake
03:23:08  Scheduled turn started
03:23:11  Sleep Service Back to Sleep, three seconds later
08:44:29  Final Sleep Service Back to Sleep event
~13:43    Forced restart

The turn was later recorded as interrupted. The forced restart produced:

SOCD report detected: (AP watchdog expired)
Boot faults: wdog,reset_in1

Second incident, 2026-08-13 local time:

02:27:31  Clamshell sleep
03:05:24  DarkWake
03:05:28  Scheduled turn started
03:05:36  Maintenance Sleep, eight seconds later
03:23:17  Turn recorded as interrupted at the next DarkWake
03:56:14  Final Sleep Service Back to Sleep event
10:51:55  Forced restart after normal wake failed

pmset confirms the process uses NoIdleSleepAssertion "Electron"; a historical assertion on this machine lasted 09:46:31. PreventSystemSleep remained 0. No process assertion was logged at either final sleep transition. Wake requests were attributed to rtc/SleepService and dasd, so the overdue task appears to run opportunistically inside the maintenance wake.

There was also a graphics-related correlation on the second night. During every DarkWake, the desktop log resumed a failed composition retry loop:

Native pet material attachment completed attached=false failureReason=system-glass-unsupported
Native pet composition recovery scheduled

The retry counter reached attempt 932 at 03:56:11, three seconds before the final sleep event. The same power transitions repeatedly reported slow acknowledgements from RTBuddy(GFX), RTBuddy(ANS2), Bluetooth, audio, and multifunction-manager drivers. This resembles the composition loop reported in #37949, although it is not proof that the loop caused the watchdog.

All local scheduled tasks are now paused for an A/B sleep test. I can provide the sanitized power-log excerpts, the 2.3 KB watchdog panic, and both interrupted automation records privately if maintainers need them.

IgorGanapolsky · 8 days ago

DarkWake that lets the Mac go back to sleep after dispatch is the overnight bug: the scheduled task starts, then the laptop sleeps and the job dies with it.

Split that survives: keep Codex as the UI, run the long job on a fenced VPS that does not sleep. Approve money / customer / production in the browser so a sleeping lid is not the gate.

If you just need that overnight split: hosted Hermes, $10/mo, 14-day trial — https://thumbgate.app

jakubkrcmar · 1 day ago

Additional sanitized reproduction from Codex Desktop on macOS:

On 2026-08-21, scheduled session 01a022ed-38ca-7a73-9a70-338aad786f00 started at 08:06:08 CEST during a maintenance DarkWake. Its first tool result arrived at 08:06:18, after pmset recorded maintenance sleep resuming at 08:06:16. A full user wake occurred at 08:59:44, but the turn never resumed and still had neither task_complete nor turn_aborted at the next indexed review cutoff.
On 2026-08-24, the same failure shape repeated three times. Sessions started at 08:11:46 and 09:20:07-08 CEST. The power log shows DarkWake at 08:11:45 followed by maintenance sleep at 08:11:51, then DarkWake at 09:20:07 followed by maintenance sleep at 09:20:14. None of the three sessions made a tool call or reached a terminal runner state.

The first case was observed with bundled CLI 0.148.0-alpha.15. This reinforces two acceptance conditions already discussed here and in #35602:

Do not dispatch long local work inside a maintenance wake unless the runner can hold a bounded system-sleep assertion through a durable terminal transition.
If the machine sleeps after dispatch, persist an explicit requeued/failed state and resume exactly once after full wake; never leave an unterminated task with no retry receipt.

I can provide narrower sanitized session and pmset excerpts if maintainers need them.