The power-save blocker added for #276546 does not appear to cover Agent sessions that use models provided by third-party LanguageModelChatProvider extensions.
The implementation in commit de441dc178462184fb8772bfff47d325f752bf3e acquires the power-save blocker in ChatMLFetcher, i.e. around model requests made through Copilot's own fetch path.
However, when an Agent session uses a model registered by another extension through LanguageModelChatProvider, the model request is handled by that provider instead and does not pass through ChatMLFetcher.
As a result, the computer can still go to sleep while such an Agent session is actively working.
Example
I am using a Codex model exposed to Copilot Chat through the third-party Universal Chat Provider extension.
The effective path is roughly:
Copilot Agent
↓
VS Code LanguageModelChatProvider API
↓
third-party model provider
↓
Codex
An Agent task can be actively running through this provider, but Windows still goes to sleep according to the configured idle timeout.
Expected behavior
The power-save blocker should ideally follow the Agent execution lifecycle, independent of which language-model provider is being used.
While at least one Agent session is actively working, VS Code should prevent automatic system sleep.
This should include activity such as:
model request
→ tool call
→ terminal command
→ file operation
→ model request
→ tests/build
→ model request
The display should still be allowed to turn off normally.
Sleep inhibition should be released once the Agent session has:
- finished;
- been cancelled; or
- reached a state where it is waiting for user interaction.
Why the Agent/session layer may be preferable
The current implementation is tied to individual model requests and keeps the blocker alive for a grace period after a request completes.
That works for many cases, but it has two limitations:
- Third-party model providers are not covered if their requests bypass
ChatMLFetcher.
- Long-running tool calls may outlive the grace period, even though the Agent itself is still actively working.
For example:
model response finishes
→ build/test command runs for several minutes
→ next model request
The Agent is active for the entire period, but a blocker attached only to model fetching cannot reliably represent that state.
Moving or additionally applying the power-save blocker at the Agent/session execution level would make the behavior provider-independent and would cover the complete Agent workflow.
Multiple VS Code windows
This should also work when multiple VS Code windows are open.
If any window has an Agent session that is actively working, the system should remain awake. Normal sleep should resume only after there are no actively working Agent sessions in any window.
Related
This is not intended to duplicate #276546, but to report a gap in its current implementation for custom language-model providers and for Agent activity occurring between model requests.
VS Code version: Code 1.134.0 (110a328, 2026-08-18T18:24:44Z)
OS version: Windows_NT x64 10.0.26200
Modes:
Remote OS version: Linux x64 6.18.33.2-microsoft-standard-WSL2
The power-save blocker added for #276546 does not appear to cover Agent sessions that use models provided by third-party
LanguageModelChatProviderextensions.The implementation in commit
de441dc178462184fb8772bfff47d325f752bf3eacquires the power-save blocker inChatMLFetcher, i.e. around model requests made through Copilot's own fetch path.However, when an Agent session uses a model registered by another extension through
LanguageModelChatProvider, the model request is handled by that provider instead and does not pass throughChatMLFetcher.As a result, the computer can still go to sleep while such an Agent session is actively working.
Example
I am using a Codex model exposed to Copilot Chat through the third-party Universal Chat Provider extension.
The effective path is roughly:
An Agent task can be actively running through this provider, but Windows still goes to sleep according to the configured idle timeout.
Expected behavior
The power-save blocker should ideally follow the Agent execution lifecycle, independent of which language-model provider is being used.
While at least one Agent session is actively working, VS Code should prevent automatic system sleep.
This should include activity such as:
The display should still be allowed to turn off normally.
Sleep inhibition should be released once the Agent session has:
Why the Agent/session layer may be preferable
The current implementation is tied to individual model requests and keeps the blocker alive for a grace period after a request completes.
That works for many cases, but it has two limitations:
ChatMLFetcher.For example:
The Agent is active for the entire period, but a blocker attached only to model fetching cannot reliably represent that state.
Moving or additionally applying the power-save blocker at the Agent/session execution level would make the behavior provider-independent and would cover the complete Agent workflow.
Multiple VS Code windows
This should also work when multiple VS Code windows are open.
If any window has an Agent session that is actively working, the system should remain awake. Normal sleep should resume only after there are no actively working Agent sessions in any window.
Related
de441dc178462184fb8772bfff47d325f752bf3eThis is not intended to duplicate #276546, but to report a gap in its current implementation for custom language-model providers and for Agent activity occurring between model requests.
VS Code version: Code 1.134.0 (110a328, 2026-08-18T18:24:44Z)
OS version: Windows_NT x64 10.0.26200
Modes:
Remote OS version: Linux x64 6.18.33.2-microsoft-standard-WSL2