Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Windows desktop: keep-awake protection is dropped when remote-control status becomes errored

Open
  • Is something wrong?
#52,371 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
electron, javascript, node.js
Domain
desktop-dev, devtools

Research direction

The predicate is in the bundled app-shared JS (export EY) and the flag is computed in app-initial I8s; the blocker logic is in main-p91kJShj.js (updatePowerSaveBlocker / syncPowerSaveBlocker). Start by reading how remote status feeds the keep-awake flag, then reproduce the connected-to-errored transition with mocked powerSaveBlocker calls. Done means errored keeps protection when the saved setting is on, while disabled still releases it, with tests covering both.

Written by the indexing model from the issue text.

Description

app bug connectivity remote windows-os

Summary

On Windows desktop, the saved "keep this computer awake while plugged in" setting is gated on the remote-control transport being connecting or connected. A transition to errored clears that protection even though the preference remains enabled. If no independent blocker is present, the desktop main process calls powerSaveBlocker.stop.

This is a reproducible logic-level protection gap in the installed desktop bundle. A real overnight local task also suffered system-idle sleep with this setting enabled, but the complete causal chain for that incident is not proven (limitations below).

Environment

  • Windows x64, desktop package OpenAI.Codex_26.1002.7124.0_x64.
  • Bundled CLI: 0.162.0-alpha.2.
  • Saved preference: [desktop] keepRemoteControlAwakeWhilePluggedIn = true.
  • Current Windows power API reports AC power and no system battery.
  • Windows balanced plan: AC idle sleep after 900 seconds.
  • No entries shown by powercfg /requestsoverride.
  • Local HTTP proxy/TUN is in use; a remote network failure should not silently defeat a saved keep-awake preference.

Confirmed implementation path

Inspected the installed app's app.asar without modifying it:

  1. app-shared-40678a67f0e3.js: the derived remote-enabled predicate (local name Uzr, export EY) is true only when not suppressed and remote status is connecting or connected. It returns false for errored, disabled, or missing status.
  2. app-initial-25361a10f2bf.js, I8s: the renderer sends the keep-awake flag as saved setting AND the above remote-enabled predicate, considering local/WSL hosts.
  3. main-p91kJShj.js, updatePowerSaveBlocker / syncPowerSaveBlocker: when that flag becomes false, the web contents is removed from the remote keep-awake set. On AC, if the display-sleep and independent app-suspension sets are also empty, the main process stops the existing blocker.

The remote branch does not check whether a local task is still running. An independent blocker can protect the task if one exists; this report does not claim all other branches are disabled in every configuration.

Reproduction / validation performed

I extracted the actual predicate and syncPowerSaveBlocker method from this installed bundle and ran them in a Node harness. Electron's power monitor and blocker APIs were mocked to record calls; the renderer's saved-setting/remote-state conjunction was reproduced in the harness.

With AC power, saved setting=true, suppression=false, and no independent/display blocker:

State transition Result
Initial connected starts prevent-app-suspension
connected → errored calls stop; no active blocker
errored → connecting starts prevent-app-suspension again
errored with independent blocker present keeps app-suspension protection
disabled with no independent blocker stops protection (expected for intentional disable)

All five assertions passed. This validates the bundled logic and stop/start calls under those inputs. It is not a live Electron/Windows sleep reproduction, and I did not disconnect the user's network or alter the installed application.

Real incident, separate from the logic reproduction

All times below are UTC, October 8–9, 2026.

  • Desktop logs show successful responses to remoteControl/enable on October 8 at 12:49:35, 12:49:48, and 12:49:54.
  • A local presentation task ran from October 8 15:25:12 to October 9 01:00:00.
  • October 8 16:40:11.037: Local Work executor rendezvous connection reported read_error.
  • 16:40:12.899: reconnect reported websocket_error.
  • 16:40:17.909: executor exited with code 1.
  • 16:40:18.911: executor restart attempted.
  • Windows Power-Troubleshooter reports sleep beginning 16:40:19.441081, waking October 9 00:06:41.7431809: about 7 h 26 min.
  • Kernel-Power event 42 records sleep reason System Idle.
  • 16:40:19.538: executor startup failed with ERR_NETWORK_IO_SUSPENDED.
Limits of attribution

The Local Work executor connection above is not itself the exact remoteControl/status input used by the keep-awake predicate. Historical logs do not contain the needed status value and blocker start/stop snapshots. Network disruption may also be part of sleep preparation. Therefore I cannot assert that the proven logic gap caused this particular overnight sleep.

The available execution environment could not obtain an administrator-level powercfg /requests snapshot. No claim is made that Windows ignored an active Codex power request.

Expected behavior / suggested investigation

When the user explicitly enables keeping an AC-powered computer awake for remote access, transient remote transport errors should not remove the protection needed for reconnection, especially while local tasks continue running.

Please consider:

  • tracking user-enabled remote-access intent separately from transient connection health;
  • retaining protection through recoverable errors/reconnect backoff, while respecting intentional disable and battery policy;
  • ensuring active local work has an independent protection path on Windows;
  • logging credential-free keep-awake decisions and blocker transitions so real sleep incidents can be attributed.

Related symptom report: #23294 (macOS; this report adds Windows-specific bundle logic and a tested error-state transition). Image-history latency from the same overnight task is documented separately in #43015; its request waits must not be conflated with the 7 h 26 min of system sleep.

No private conversation contents, credentials, account identifiers, document payloads, or full logs are included.

Dominant language
Rust
Stars
129k
Forks
20.3k
Avg merge
1m
Merged PRs (30d)
998

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.