Repository navigation
/keep-alive in WSL2 does not prevent the Windows host from sleeping #5304
Description
Describe the bug
When Copilot CLI runs inside WSL2, /keep-alive does not prevent the Windows host from sleeping. WSL is treated as Linux, so the CLI attempts to use systemd-inhibit; that does not create a Windows host power request visible through powercfg -requests.
This means long-running Copilot tasks can be suspended when the Windows host sleeps, even though keep-alive is enabled.
Affected version
1.0.105
Steps to reproduce the behavior
- Run Copilot CLI inside WSL2 on Windows.
- Enable
/keep-alive onor the busy-mode equivalent. - From Windows, run
powercfg -requests. - Observe that Copilot CLI has not registered a Windows host power request.
- Allow the Windows host's configured idle timeout to expire.
- Observe that the host can sleep and suspend the WSL2/Copilot workload.
Expected behavior
Enabling /keep-alive inside WSL2 should prevent the Windows host from sleeping, just as running Copilot CLI natively on Windows does.
The implementation could detect WSL2 and invoke an appropriate Windows-host mechanism, or clearly expose a supported integration that creates and releases the host power request for the lifetime of the Copilot task.
Additional context
The original implementation uses systemd-inhibit on Linux and Windows power APIs only for native Windows processes:
https://github.com/github/copilot-agent-runtime/pull/5669
A later fix explicitly handles WSL as an environment where the Linux inhibitor may fail, but does not forward sleep inhibition to the Windows host:
https://github.com/github/copilot-agent-runtime/pull/13161
WSL2 is important for file-heavy Rust, Go, and similar development because working on its Linux filesystem can be substantially faster than working directly on NTFS. Requiring a separate Windows keep-awake utility makes /keep-alive ineffective for this common workflow.
Originating discussion:
https://github.slack.com/archives/C093WSH3L8J/p1793378606869279
Activity
heaths commentedon Oct 30, 2026
Likely something that will best to be done in WSL itself: microsoft/WSL#42121; however, Copilot CLI could ship a small executable that basically does nothing more than below when running under WSL (various easy ways to detect) in addition to calling
org.freedesktop.login1.Manager.Inhibit():Preventing shutdown isn't entirely possible—much like with systemd—and methods to "discourage" it are far more involved, but disabling the idle timer this way would accomplish most of the same goals. It's at least analogous to the CLI setting just "idle" as the inhibitor now.