[Computer use] Non-allowlisted windows get minimized on session start, disruptive on multi-monitor
Environment: Windows 10 Pro, dual monitor, Claude Code computer-use MCP, Chrome 149.
Behavior: As soon as a computer-use session starts (first screenshot/action), windows of apps that are not in the request_access allowlist are minimized/hidden, not just masked. The screenshot tool even reports "X were open and got hidden before this screenshot (not in the session allowlist)."
Impact: On a multi-monitor setup this clears windows across both monitors down to the bare desktop. Parallel work is broken, the user has to manually restore everything every time computer use kicks in.
Current workaround: grant every app you want to keep visible via request_access (so nothing is "non-allowlisted"). Works, but you must predeclare every window.
Requests (any one would help):
- Option to capture/interact with only the target window instead of the full display, so other windows never need to be hidden.
- A "mask instead of minimize" mode that overlays a rectangle but leaves windows in place (the docs describe masking, but on Windows the windows are actually minimized).
- At minimum, document this behavior so it isn't a surprise.
3 Comments
On a multi-monitor setup, having the computer-use session minimize every window that isn’t explicitly allowlisted is pretty disruptive. You lose your whole desktop layout just to run one agent session.
We’ve been thinking about permission and isolation models that are less all-or-nothing. Being able to run agent work without it wrecking your existing workspace feels important for real daily use.
You working around this with specific allowlists or just living with it?
Can confirm this on Windows 11, ARM64 (Surface), three monitors with mixed layout.
Additional finding: the documented workaround ("grant every app you want to keep visible via
request_access") does not reliably prevent it. I granted a native Win32/Tauri app full tier access explicitly, and it still got minimized on every subsequentscreenshotcall — not just on session start, but on every single screenshot, reproducibly, even with a single clean call (open app → wait → one screenshot). It also affected Claude Code's own window in the same way, per live confirmation from the person sitting at the physical machine.So the actual trigger seems to be "any screenshot", not "non-allowlisted + session start" as currently described — worth re-checking whether the allowlist check is being applied at all on Windows, or only accounts for session start and not later calls.
+1, same behavior here. Windows 11, Claude desktop app, three monitors of different sizes and resolutions.
When computer use starts (for example
request_accessfollowed byopen_application), the tool reports that every app outside the allowlist was hidden: about 22 windows in my case, across all monitors. The overall effect looks like what Windows does when you unplug one of several monitors: the windows and the desktop layout get reorganized. As soon as computer use stops, everything goes back to normal.Expected: nothing about the user's windows or monitor layout should change while computer use is running. Non-allowlisted windows should be masked in screenshots only, not minimized or moved.