Prevent sleep while running for increased reliability #7049

Filling in the Windows and Linux evidence that #5535 asked for and could not get, because it was only verified on macOS.

Why the WSL case is not covered by the provider's own flag

For a WSL environment, a provider's sleep prevention cannot help. Codex's prevent_idle_sleep calls systemd-inhibit inside the WSL namespace, and WSL2 has no power management of its own, so the assertion is scoped to the VM and never reaches the Windows host that actually powers down. Holding a Windows host awake needs a Win32 power request, and the desktop client's Electron main process is the only process in the stack that can make one. So for local and WSL environments this is either a T3 Code feature or nothing.

The same applies to a WSL-hosted Codex thread specifically, which is why enabling prevent_idle_sleep is not a workaround here.

What I measured

WSL2 on Windows 11 Home, "Legion Balance Mode" power scheme, codex-cli 0.157.1.

• powercfg /q SCHEME_CURRENT SUB_SLEEP STANDBYIDLE reports 0x00000000 for both AC and DC. That is the current workaround, the idle sleep timer disabled outright, and it is why the machine does not sleep after threads finish. Restoring a real value is the fix for that half, and it is independent of this feature.
• powercfg /requests is empty when no turn is running, so nothing is being leaked or held between turns on a machine that never took the assertion.
• WSL has systemd as PID 1 and systemd-inhibit at /usr/bin/systemd-inhibit, confirming the Linux backend is present and running, while still being unable to affect the host sleep timer.

What I can add

I can build the #5535 branch, run a turn against a WSL environment, and confirm the assertion appears in powercfg /requests while the turn runs and clears when it settles. That is the one piece of evidence the previous attempt did not have. Happy to open a PR with that verification if it is wanted.

Asking for an explicit scope decision

The two reasons #5535 was closed (no selected default, no rule for remote hosts) were already answered in this thread: @leo-mathurin's comment above and @satyalyadav's #13893 both propose that it is off by default and that only turns on local/WSL environments hold the blocker. Could a maintainer confirm whether that scope is acceptable, or say what would need to change?

Two small additions to that scope, if helpful:

• Hold the blocker only on AC power, never on battery, instead of a battery threshold.
• Tests that the assertion is released on every path (last turn settles, setting turned off, switch to battery, app quits), given the stray wake lock reports in [Bug]: Desktop app held a Chromium "Video Wake Lock" for 14 hours, so the Mac never turned off its display or locked #15343 and macOS desktop: preview screencast leaves "Capturing" wake lock held, Mac never idle-sleeps #17870.

I can verify on macOS; @satyalyadav has offered to cover Windows/WSL.

+1, with a use case and two points on scope.

I run several Claude Code threads at once in T3 Code, each with subagents and delegated tasks. Right now I keep the Mac awake with caffeinate -is -w <T3 Code pid>. That works, but I have to start it again every time the app relaunches, and it keeps the Mac awake when nothing is running.

On the scope question above:

1. "Running" should include background work, not only the active turn. Subagents, delegated tasks and background shells keep going after a thread's turn ends. If the blocker only follows active turns, the Mac can sleep in the middle of that work. Hold it while any local thread has a running turn, subagent, delegated task or background command, and release it when all of them are done (related: Should background commands keep a thread in the Working section? #15433, Let Pi extensions pin a session that owns live background work, so long-running supervisors survive the idle release #18093).

2. Lid closed, as a separate opt-in. Neither powerSaveBlocker nor caffeinate stops a MacBook from sleeping when the lid closes. The only way I know is sudo pmset -a disablesleep 1, which is system-wide, needs admin rights, and stays on if the app crashes. If that's in scope, I'd want it as its own toggle that asks for admin rights, sets disablesleep back to 0 when the last run ends or the app quits, and resets it on the next launch after a crash. I understand if it's out of scope given the device-policy concern on feat(desktop): keep the machine awake while local agents work #5535; the first toggle covers most of what I need.

I can test on macOS (MacBook Pro, Apple Silicon) with pmset -g assertions.

I have created a menu bar app for macOS that prevents the mac from sleeping with the option to keep it awake until auto-resume is triggered. There is also a new experimental feature that I've added today but still gotta test that it let's your mac sleep while you wait for the auto-resume (to save energy) and then it automatically wakes up. It also keeps mac awake when agent is waiting for user input for 2 hours so you can still reply from your phone or other device.

It also supports keeping the mac awake while the lid is closed and disconnecting bluetooth devices while you do it (requires root)

https://github.com/szymonograbek/bee

One fact that matters for the scope here: on a MacBook, none of these assertions survives closing the lid. powerSaveBlocker (prevent-app-suspension) and caffeinate, even caffeinate -s, hold off idle sleep, but macOS still sleeps a MacBook when its lid closes unless an external display, keyboard and power are connected (closed-display mode). So even with the feature discussed here, a MacBook that is closed while T3 Code serves a phone or another machine goes to sleep and the connection drops.

Since that is OS policy rather than something T3 Code should own (the closing note on #5535), a small docs change could help whatever is decided about the feature: one sentence in "Platform support" of docs/user/background-service.md, after "Keep the Mac logged in and awake for unattended remote access.":

A MacBook also sleeps when its lid closes, unless an external display, keyboard and power are connected; to keep one awake closed without them, use a keep-awake app such as Keep Mac Awake.

A vendor-neutral version without the link works too. If a maintainer agrees with the direction, I can open a docs-only PR that links this discussion.

Disclosure: I make Keep Mac Awake, a paid macOS app (3-day free trial, then 9 USD once per Mac) that keeps a MacBook with Apple silicon awake with the lid closed for a session you start, with a watchdog that restores normal sleep if a service stops or hangs. I use T3 Code daily with it.

Another use case: reaching the Mac from my phone

I mostly use T3 Code from the iPhone app over T3 Connect, with my MacBook on the charger at my desk. Since I fully switched from the Codex app to T3 Code, the phone gets stuck on "Reconnecting" (tunnel_down, HTTP 530) a few minutes after I lock the Mac and walk away.

It took me over half an hour with pmset -g log to find the cause: the Mac was asleep. The Codex app used to be open all the time, and it kept the Mac awake on its own. Claude's desktop app has a "Keep computer awake while Claude works" setting too. Because the other agent apps do this, I assumed T3 Code did as well, and I went looking for network problems instead.

I've now turned on macOS's "Prevent automatic sleeping on power adapter when the display is off", but that keeps the Mac awake even when I'm not using any of these apps. I'm confused why T3 Code doesn't offer this as an option, especially since being reachable from my phone is a big part of why I use it.

Drafted with Claude Opus 5.5 (Claude Code) on behalf of @lingolooper-simon.

I'd like T3 Code to match the user-visible behavior of ChatGPT/Codex desktop's “Prevent sleep while running” setting. I use it on KDE Plasma, and it already fits my use case: start a task, step away, and let the computer return to its normal sleep policy once the work ends.

My preferred scope:

• Make this an optional setting that prevents inactivity-based system sleep while local work is running. It should work on battery as well as AC power. An AC-only restriction would miss my use case.
• Count local subagents, delegated work, background commands belonging to a task, and WSL work, including when the parent turn has ended but that work is still running. For WSL, keep the Windows host awake.
• Release the inhibitor when there is no active local work left. A thread that has finished or is only waiting for my answer, approval, or feedback should not hold it. Another thread or background task still working should continue to hold it.
• Remote work that continues independently when this computer sleeps should not keep this computer awake just because I am viewing it here.
• Let the screen turn off and lock normally. Turning the setting off or exiting the app should release the inhibitor, and crashes should not leave a stale inhibitor behind.
• Preserve the OS's critical-battery hibernate/shutdown policy. I would prefer relying on that policy rather than adding an arbitrary 10% cutoff that can let an unfinished task be suspended early.

Keeping the computer reachable from a phone is a separate need. ChatGPT has a separate keep-awake control under its connection settings; I would keep that separate here too, with remote-host availability restricted to AC power. It should not make task sleep prevention AC-only or keep an idle laptop awake on battery.

For lid closure, follow the platform's normal behavior rather than adding a privileged system-wide override to this feature. OpenAI's Mac guidance describes plugged-in operation and an external display for closed-lid use. My request is to prevent automatic sleep from inactivity while work is running.

References: ChatGPT settings, remote connections.

The documentation confirms the separate settings, but does not establish every internal detail, including battery thresholds or all background-work transitions. Those bullets express my requested behavior rather than claiming a complete implementation audit of ChatGPT.

Drafted with Codex (gpt-6.1-sol) in T3 Code on my behalf.

I built this in my fork and run it on a MacBook Air, in case a working reference helps settle the scope.

What it does

• It lives in the server, not in Electron, so the machine that runs the agents is the one kept awake. That covers a headless Linux server and the "reach my Mac from my phone" case above, and it can be switched from another device.
• Modes: off, while agents are working (default), for a duration, until a time, indefinitely. "While agents are working" releases as soon as no thread is running, so the normal sleep policy returns on its own.
• Options: let the display sleep (on by default, so auto-lock policies keep working), and stop below a battery percentage.
• macOS uses /usr/bin/caffeinate -i -w <server pid>, so the assertion is dropped even if the server is killed. Linux uses systemd-inhibit. Where neither is available the control shows as unsupported instead of pretending.
• On the lid-closed point @bartdudzic raised: as he says, no assertion survives closing a MacBook's lid. The only thing that does is pmset -a disablesleep 1, which needs root. I made that a separate opt-in that installs a narrow sudoers rule for exactly those two pmset commands, and it requires power to be connected. That part is a real product decision (asking for admin rights) and I would not expect it in a first version.

What I have and have not checked

Tested by hand on macOS desktop. The Linux path has unit tests but I have not hand-tested it on a desktop Linux session. Windows is not implemented.

Code

Server service and tests are under apps/server/src/keepAwake in my fork. The fork is behind main, so this is a reference, not a PR-ready diff. If maintainers approve a scope (I would suggest: the server service, the "while agents are working" mode and the display/battery options, without the lid-closed part), I am happy to rebuild that subset on current main as one focused PR.

Written with Claude (Fable 5.2) via Claude Code.

Prior effort: #30651 (closed in the unvouched sweep; Macroscope had approved the approach).

What we learned trying it

• One boolean is too coarse. Useful modes were Off / While agents work / Always, scoped per environment, default Off so existing installs stay quiet.
• “While agents work” has to track more than a single foreground turn — scheduled tasks and remote clients still need the host up, so the blocker ownership belongs on the server (OS sleep API), not only the desktop window.
• Keep screen-off / lock policies intact; prefer prevent-app-suspension style blockers over keeping the display awake.

Data point from KDE Plasma 6.6 (Wayland, desktop PC), for the Linux side of this.

My PC suspended this week while threads were running. I want to keep idle suspend, just not while agents are working. Until this lands I run a small watcher, and testing it turned up a few things:

• PowerDevil honors both kde-inhibit --power (org.freedesktop.PowerManagement.Inhibit) and systemd-inhibit --what=idle --mode=block. Either one blocks automatic suspend and still allows manual suspend from the menu. PowerDevil only applies an inhibition about 5 seconds after it's taken (HasInhibition stays false until then), so tests with short-lived locks will look like they fail.
• Here the T3 server runs as the t3code.service systemd user unit and I mostly use it from the browser. A blocker in the Electron main process would miss that setup, so +1 to the server owning it, as @wincrack07 and @wSedlacek suggest.
• On what counts as working, I agree with @vibhor1102: a run in waiting doesn't hold the lock in my watcher. A parent waiting on a delegated child is covered by the child's own running run, and a thread waiting for my answer shouldn't keep the machine up. Only queued, preparing, starting and running count.

QUERY="SELECT count(*) FROM orchestration_v2_projection_runs
       WHERE status IN ('queued', 'preparing', 'starting', 'running')"
holder=""
while :; do
  count=$(systemctl --user is-active --quiet t3code.service &&
    sqlite3 -readonly -cmd ".timeout 2000" ~/.t3/userdata/statev2.sqlite "$QUERY")
  if [ "${count:-0}" -gt 0 ] && [ -z "$holder" ]; then
    kde-inhibit --power tail -f /dev/null & holder=$!
  elif [ "${count:-0}" -eq 0 ] && [ -n "$holder" ]; then
    pkill -P "$holder"; wait "$holder"; holder=""
  fi
  sleep 30
done

Drafted with Claude Opus 5.5 (Claude Code) in T3 Code on my behalf.

macOS counterpart of the watcher above, for anyone who wants it before this lands.

Same query, same rule: hold an assertion only while a run is queued, preparing, starting, or running, and drop it otherwise.

caffeinate2 -i is the idle-sleep equivalent of kde-inhibit --power. The display can still sleep and lock, and closing the lid still sleeps the machine. The caffeinate2 tray helper (work-in-progress) can upgrade that assertion to prevent lid sleep as well. -w $$ ties the assertion to this loop, so killing the loop drops it even if caffeinate2 is reparented.

kill -0 on the pid in server-runtime.json stands in for systemctl is-active. A dead server does not hold, which matters because a crash can leave rows stuck at running.

QUERY="SELECT count(*) FROM orchestration_v2_projection_runs
       WHERE status IN ('queued', 'preparing', 'starting', 'running')"
home="${T3CODE_HOME:-$HOME/.t3}/userdata"
holder=
while :; do
  pid=$(sed -n 's/.*"pid":[[:space:]]*\([0-9]*\).*/\1/p' "$home/server-runtime.json")
  count=$(kill -0 "$pid" 2>/dev/null &&
    sqlite3 -readonly -cmd ".timeout 2000" "$home/statev2.sqlite" "$QUERY")
  if [ "${count:-0}" -gt 0 ] && [ -z "$holder" ]; then
    caffeinate2 -i -w $$ & holder=$!
  elif [ "${count:-0}" -eq 0 ] && [ -n "$holder" ]; then
    kill "$holder" 2>/dev/null; wait "$holder" 2>/dev/null; holder=
  fi
  sleep 30
done