"Keep this Mac awake" doesn't prevent Mac connected to power from sleeping
What version of the Codex App are you using (From “About Codex” dialog)?
26.513.31313 (2867)
What subscription do you have?
Plus
What platform is your computer?
Darwin 25.4.0 arm64 arm
What issue are you seeing?
Left my MacBook Pro at home connected to power and an external monitor with the Codex app running today, and the Connections → Control this Mac → Keep this Mac Awake setting enabled. Despite this, my Mac went to sleep, dropped off the network, and became unavailable in the Codex section of the ChatGPT app on my iPhone.
What steps can reproduce the bug?
- Connect your Mac to power.
- In Codex, Connections → Control this Mac → Keep this Mac Awake: ON
- Make sure both the Mac and iPhone are on the same TailScale Tailnet.
- Set up an iPhone with access to Codex on your Mac from the ChatGPT app on iOS.
- Leave the Mac idle until the display turns off (System Settings → Lock Screen → Turn display off on power adapter when inactive)
- Note that the Mac goes to sleep and becomes unavailable on the Tailnet, and in the ChatGPT app on iPhone.
What is the expected behavior?
With the option to "Keep this Mac awake" enabled, I would expect my Mac's screensaver to still turn on, for the display to sleep, but for the Mac to remain online and responsive to external connections from the ChatGPT app on mobile.
Additional information
Here are my macOS Battery options (which, despite the name, is where you configure power settings for the machine when it is connected to power in macOS Tahoe):
<img width="1862" height="2314" alt="Image" src="https://github.com/user-attachments/assets/b5722e57-4425-42cd-902b-e7d562b987bf" />
Here are my macOS Lock Screen options:
<img width="1862" height="2314" alt="Image" src="https://github.com/user-attachments/assets/ddb19246-592a-495d-8f38-b1f3d4271517" />
My Mac and iPhone are on the same Tailnet. The TailScale app showed the Mac as offline when it was asleep.
Interestingly, I also run OpenClaw on this machine, and while the computer was showing as offline in TailScale, and not responding to Codex connection attempts from the ChatGPT mobile app, it was still able to respond (with a delay of around a minute) to Telegram messages sent to my OpenClaw bot. Whenever I would send a message, it would respond only after about a minute's delay, and at the moment where it responded, my Mac would show up as online in TailScale for just a moment, while OpenClaw was responding to my message, then it dropped offline again. It seems as if OpenClaw is able to still receive requests and temporarily wake the Mac from sleep to respond to them, whereas the Codex desktop app does not.
11 Comments
Same issue I have
I have the same issue.
Only way I got this to work is enabling _Prevent automatic sleeping on power adapter when the display is off_ in battery options. Seems more like a workaround though and I'm not sure whether _Keep this Mac awake_ in Codex is actually doing anything then.
Anyone find a solution? I haven't been able to use Codex a single time from my phone with the macbook lid closed.
What does "...and remote access is enabled" mean? Where is "remote access" toggled?
Its odd, my mac mini does this, but if I have a lock screen on my macbookpro (same settings on both devices for wake, sleep, lock screen, 'battery', and my codex via IOS works with my macbookpro totally fine with lock screen, but not my mac mini with same settings, if the screensaver or lock screen goes on it bricks until password is back
I got it working. It doesn’t actually enable the Mac permissions even though the app shows it as enabled.
You have to manually go through the privacy settings and enable all the ones that have codex listed.
Oh niceeee. I thought I did that, but I'll double check it on the new macmini
Yeah I had all the codex ones. Weird
I think there’s three of them, but at LEAST two. And on two different Macs, at least one of them wasn’t enabled. Works on both Macs now.
Found the solution for me. Basically running keep awake caffeinate toolmkdir -p ~/Library/LaunchAgentscat > ~/Library/LaunchAgents/com.local.keep-awake.plist <<'EOF'<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict> <key>Label</key> <string>com.local.keep-awake</string> <key>ProgramArguments</key> <array> <string>/usr/bin/caffeinate</string> <string>-dims</string> </array> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> <key>StandardOutPath</key> <string>/tmp/com.local.keep-awake.out.log</string> <key>StandardErrorPath</key> <string>/tmp/com.local.keep-awake.err.log</string></dict></plist>EOFOn Jun 11, 2026, at 20:30, mapleroyal @.***> wrote:mapleroyal left a comment (openai/codex#23294)
I think there’s three of them, but at LEAST two. And on two different Macs, at least one of them wasn’t enabled. Works on both Macs now.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
This runs /usr/bin/caffeinate -dims, which prevents display sleep, idle sleep, system sleep, and disk sleep while the user session is active.
And turn the lock screen back on with all the settings you suggested also. Hopefully helps someone else.
I’m seeing the same issue and captured the exact sleep/assertion sequence.
Configuration:
On 30 July, macOS logs showed:
17:19:44.990 — Codex released its NoIdleSleepAssertion
17:19:45.010 — macOS began the sleep transition
~17:19:46 — Codex reacquired the assertion
17:19:50.049 — Mac entered Idle Sleep
The reacquisition was too late—the system had already committed to sleeping. The kernel recorded
clamshell closed 0andac 1, confirming that the lid was open and the Mac was plugged in.There was no Codex crash, process termination, memory pressure, thermal event, or macOS update involved.
I captured a separate occurrence on 17 July with the same pattern: Codex released an assertion it had held for more than 36 hours, and macOS began sleeping within milliseconds.
I also inspected the packaged Electron code in Codex
26.715.21425 (5488). The renderer requests the power assertion only while Remote Control is in theconnectingorconnectedstate. Its cleanup path explicitly sends both power-blocking flags as false.The main process then stops Electron’s
prevent-app-suspensionblocker immediately when no request remains. There does not appear to be a grace period for a transient Remote Control state change, renderer reload, or reconnect.This looks like a release/reacquire race rather than a macOS permission or Accessibility issue: Codex successfully creates the assertion, briefly releases it, and then recreates it after sleep has already started.
A possible fix would be to retain the assertion while Remote Control is enabled and the Mac is on AC power, or add a reconnect/grace interval before releasing it.