computer-use: ending screen control un-minimizes user-minimized windows and steals foreground focus (Windows)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When a computer-use screen-control session ends, the window-restore pass restores windows that were minimized before the session, and gives foreground focus to an unrelated application. A window the user had deliberately minimized comes back un-minimized and in front of everything.

Captured with a 250 ms polling script recording IsIconic, IsWindowVisible, z-order index, and the foreground window title:

time            minimized  z-index  foreground
08:26:50.958    True       6        Claude                      <- minimized, buried
08:27:54.761    False      2        Alienware Command Center    <- un-minimized + focused
08:27:55.034    False      1        Alienware Command Center
08:28:02.537    False      1        Claude                      <- focus returns ~7.5s later

The Minimized True -> False transition is the core defect. The window was minimized and was actively restored by the exit, not merely uncovered by a z-order change.

A related observation, possibly the same root cause: when an app's window exists but has never been shown, the restore pass appears to show it for the first time, so it presents as a newly launched application rather than a restored one. In my case that window had never painted, so it appeared as a blank white window in front of everything, which initially looked like the Claude client was launching third-party software.

This is not specific to the app involved (Alienware Command Center 5.9.2, a UWP app). It merely made the bug obvious, because its window paints white when shown without having rendered. Any application with a minimized or never-shown window should exhibit the same restore behavior.

Note: statements about what the client does internally (minimizing windows on entry, restoring them on exit) are inferred from observed window-state transitions, not from source. The logged transitions above are direct observations.

What Should Happen?

Ending screen control should restore the window stack to its pre-session state.

Specifically:

1. A window that was minimized before the session should remain minimized after it.
2. Foreground focus should return to the application that held it, not to an arbitrary restored window.

The restore pass should return windows to the state it found them in.

Error Messages/Logs

Steps to Reproduce

1. On Windows, have a second application running with a top-level window that is minimized (or one that was created but has never been shown).
2. In the Claude desktop app (Code tab), start a computer-use screen-control session. Any computer_batch call will do, e.g. a single screenshot:

``
computer_batch: [{"action": "screenshot"}]
``

1. Let screen control end.
2. Observe the previously minimized window.

Expected: it is still minimized, and focus is where it was.
Actual: it is un-minimized, raised to the top of the z-order, and has foreground focus. Focus returned to the Claude window ~7.5 s later.

To observe it precisely rather than by eye, poll the window state on a short interval and log IsIconic / IsWindowVisible / z-order index / foreground title. A 250 ms PowerShell poll was enough to capture the transition cleanly.

One measurement gotcha if the app under test is UWP: it has both a Windows.UI.Core.CoreWindow and an ApplicationFrameWindow (owned by ApplicationFrameHost). The CoreWindow reports Visible=True even when the app is closed, so track the ApplicationFrameWindow or the readings will mislead.

Reproduced multiple times on this machine.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.212 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Workaround currently in use, in case it helps confirm the mechanism:

A PostToolUse hook matching mcp__computer-use__.* that sends WM_CLOSE to the affected window immediately after the tool call returns.

A Stop hook alone was not sufficient, and the reason is diagnostic: Stop fires at the end of the turn, so the window stays visible for the entire duration of the assistant's reply. Measured at 9.2 s and 12.7 s across two turns, which tracked response length rather than any hook latency (the hook script itself runs in ~150 ms). That timing is consistent with the restore happening when screen control releases, near the start of the turn's tail rather than at its end.

Environment note: this was on the Claude desktop app's Code tab, not a terminal, so the Terminal/Shell field below isn't really applicable.