Description
On OpenCode Desktop for Windows, permission auto-accept appears to stop processing pending permission requests while Windows is locked (Win + L).
The agent works normally while the desktop is unlocked. After locking Windows, the backend process remains alive, but the active agent becomes stuck on a permission request. As soon as Windows is unlocked again, the permission flow resumes and the agent continues almost immediately.
This is reproducible.
Environment
- OS: Windows 11
- OpenCode Desktop: 1.18.15
- Power: plugged in
- Windows "Make my device sleep after": Never
- Auto-accept permissions enabled
- Provider/model during reproduction: OpenCode / DeepSeek V4 Flash Free
Steps to reproduce
- Open OpenCode Desktop.
- Enable Auto-accept permissions.
- Start an agent task that performs tool calls and may trigger permission requests.
- Confirm that permission requests are being auto-approved normally while Windows is unlocked.
- Lock Windows with
Win + L.
- Leave the machine locked for several minutes.
- Unlock Windows.
Actual behavior
While Windows is locked:
- OpenCode's backend remains running.
- Background maintenance continues.
- The active agent stops progressing when it reaches an
ask permission.
- The permission is not auto-approved while the desktop is locked.
- Immediately after unlocking, permission processing resumes and the agent continues.
Example reproduction:
2026-08-09T05:12:42.938Z
evaluated permission=external_directory ... action.action=ask
2026-08-09T05:12:42.938Z
asking id=... permission=external_directory
[Windows locked]
2026-08-09T05:27:21.455Z
evaluated permission=bash ... action.action=ask
2026-08-09T05:27:23.222Z
loop ... step=59
2026-08-09T05:27:23.767Z
stream ... agent=build
This is about a 14m38s stall corresponding to the lock period.
A longer reproduction showed the same pattern:
2026-08-08T20:09:35.118Z
asking ... permission=external_directory
2026-08-08T20:30:30Z cleanup
2026-08-08T21:30:30Z cleanup
2026-08-08T22:30:30Z cleanup
...
2026-08-09T03:37:08Z cleanup
2026-08-09T04:17:47.043Z
evaluated permission=bash ...
asking ...
The periodic cleanup activity is important: the OpenCode backend was still alive during the lock period, so this does not appear to be Windows putting the machine to sleep or suspending the entire OpenCode process.
When Windows is unlocked, comparable ask requests are normally handled within roughly 1-2 seconds.
Expected behavior
If Auto-accept permissions is enabled, permission requests should continue to be auto-approved while Windows is locked.
Auto-accept should ideally be handled independently of renderer/window visibility so unattended agents can continue working on a locked workstation.
If the current implementation intentionally requires an active Desktop renderer to auto-approve permissions, this should at least be documented because it prevents unattended agent operation.
Additional observations
The blocking permissions in these reproductions included:
Changing those permission rules from ask to allow works as a temporary workaround, but it changes the user's security policy and should not be required just to keep Auto-accept working while the workstation is locked.
This may be related to existing Desktop permission/auto-accept state handling issues, but the Windows lock-screen trigger appears distinct and reproducible.
Description
On OpenCode Desktop for Windows, permission auto-accept appears to stop processing pending permission requests while Windows is locked (
Win + L).The agent works normally while the desktop is unlocked. After locking Windows, the backend process remains alive, but the active agent becomes stuck on a permission request. As soon as Windows is unlocked again, the permission flow resumes and the agent continues almost immediately.
This is reproducible.
Environment
Steps to reproduce
Win + L.Actual behavior
While Windows is locked:
askpermission.Example reproduction:
This is about a 14m38s stall corresponding to the lock period.
A longer reproduction showed the same pattern:
The periodic cleanup activity is important: the OpenCode backend was still alive during the lock period, so this does not appear to be Windows putting the machine to sleep or suspending the entire OpenCode process.
When Windows is unlocked, comparable
askrequests are normally handled within roughly 1-2 seconds.Expected behavior
If Auto-accept permissions is enabled, permission requests should continue to be auto-approved while Windows is locked.
Auto-accept should ideally be handled independently of renderer/window visibility so unattended agents can continue working on a locked workstation.
If the current implementation intentionally requires an active Desktop renderer to auto-approve permissions, this should at least be documented because it prevents unattended agent operation.
Additional observations
The blocking permissions in these reproductions included:
external_directorybashChanging those permission rules from
asktoallowworks as a temporary workaround, but it changes the user's security policy and should not be required just to keep Auto-accept working while the workstation is locked.This may be related to existing Desktop permission/auto-accept state handling issues, but the Windows lock-screen trigger appears distinct and reproducible.