[BUG] Windows: Claude Code computer use leaves the desktop window stuck always-on-top (cu-side-panel restore races with Win32 screenshot re-pin)

Confirming this on a newer build and in a different configuration than the original report, plus two data points that may help narrow it down.

Environment

| Item | Value |
|---|---|
| Claude Desktop | 2.2553.1 |
| Electron | 44.2.0 |
| Node | 24.20.0 |
| Platform | win32, x64 |
| Session type | cloud session linked to a local Windows machine over the remote-devices bridge (not a local-only session) |
| Computer-use grants | AutoCAD 2024 (tier full), Google Chrome (tier read) |
| Screenshot filtering | mask |
| Observed | 2026-09-20 / 2026-09-21 |

Reproduction

Extended computer-use automation driving a desktop application (AutoCAD 2024): alternating
computer_screenshot, computer_batch (click / type / key / zoom) and computer_open_application
calls, with the side panel opening and closing repeatedly during the task.
Volume, approximate: 30–40 screen captures over ~90 minutes in a single session.

After that, the main window rendered above all other applications and stayed there. Other
applications were reachable only by minimising the Claude window.

Data point 1 — clearing WS_EX_TOPMOST externally does not work

The watchdog approach suggested earlier in this thread had no effect here:

Add-Type -Name W -Namespace N -MemberDefinition '[DllImport("user32.dll")] public static extern bool SetWindowPos(IntPtr h,IntPtr a,int x,int y,int cx,int cy,uint f);'
$h = (Get-Process claude | Where-Object MainWindowHandle -ne 0 | Select-Object -First 1).MainWindowHandle
[N.W]::SetWindowPos($h, [IntPtr]-2, 0,0,0,0, 0x0013)   # HWND_NOTOPMOST

The call targets the handle Windows reports as MainWindowHandle. The window that is actually
pinned appears to be a different top-level window of the same process, and/or the style is
re-applied immediately. A per-MainWindowHandle workaround is therefore not reliable.

Escalation ladder actually observed:

| Action | Result |
|---|---|
| Switching focus to another application | no change |
| SetWindowPos(HWND_NOTOPMOST) on MainWindowHandle | no change |
| Closing the window (app keeps running in tray) | no change |
| Full Exit (process termination) + relaunch | cleared |

Since close-to-tray does not clear it, the stuck state survives in the process, not in the
window instance. That also means the only working remedy terminates the running session.

Data point 2 — foreground stealing during automation causes wrong-target input

Separate from z-order: during the same task the Claude Desktop window repeatedly raised itself
to the foreground while the target application was mid-operation. Recorded consequences:

• Clicks issued at coordinates computed from the preceding screenshot landed on the Claude

Desktop window instead of the target application, because the foreground window changed
between the screenshot and the click.

• Text sent through the clipboard paste path (computer_type) was delivered to the wrong

window. In AutoCAD this started an unintended PASTECLIP command, which then blocked the
command line and required several recovery steps before automation could continue.

• Steps had to be re-issued. Approximate overhead in this session: **10–15 wasted tool calls,

on the order of 20–30% of the computer-use calls made**.

(The two counts above are estimates from the session log, not instrumented measurements.)

This is arguably the more serious half of the problem. An agent driving a desktop application
cannot rely on "frontmost window at screenshot time" still being frontmost at click time if the
host application can raise itself asynchronously. The failure is silent — input goes somewhere
else and the agent only discovers it from the next screenshot.

Requests

1. Serialise access to the always-on-top state between the screenshot path and the side-panel

dock/restore path, so the style cannot persist beyond the operation that required it.

1. Add a user-facing setting to disable always-on-top for the main window (also requested in

#89467). At present the only remedy is a full Exit, which ends the running session.

1. During computer-use automation, suppress asynchronous raising of the Claude Desktop window,

or surface foreground-window changes to the agent so stale-coordinate input can be detected
rather than silently misdelivered.

Same fault here on Windows 11 (desktop app 2.2553.1): the main window stays always-on-top after any computer-use session. PowerToys Win+Ctrl+T does not clear it.

One-click workaround for non-developers until this is fixed. Save the text below as Unpin Claude.cmd on the Desktop and double-click it whenever the window is stuck. It clears the topmost flag on every visible window owned by a claude process and changes nothing else. Confirmed working here. The pin returns after the next computer-use session, so run it again then.

@echo off
powershell -NoProfile -ExecutionPolicy Bypass -Command "iex (((Get-Content -Raw -LiteralPath '%~f0') -split '(?m)^:PSSTART\r?\n',2)[1])"
exit /b
:PSSTART
$src = @'
using System;
using System.Runtime.InteropServices;
public static class ClaudeUnpin {
  delegate bool EnumProc(IntPtr h, IntPtr l);
  [DllImport("user32.dll")] static extern bool EnumWindows(EnumProc cb, IntPtr l);
  [DllImport("user32.dll")] static extern uint GetWindowThreadProcessId(IntPtr h, out uint pid);
  [DllImport("user32.dll")] static extern bool IsWindowVisible(IntPtr h);
  [DllImport("user32.dll")] static extern int GetWindowLong(IntPtr h, int i);
  [DllImport("user32.dll")] static extern bool SetWindowPos(IntPtr h, IntPtr after, int x, int y, int cx, int cy, uint flags);
  public static int Run(int[] pids) {
    int n = 0;
    EnumWindows(delegate(IntPtr h, IntPtr l) {
      uint pid; GetWindowThreadProcessId(h, out pid);
      if (Array.IndexOf(pids, (int)pid) >= 0 && IsWindowVisible(h) && (GetWindowLong(h, -20) & 8) != 0) {
        SetWindowPos(h, new IntPtr(-2), 0, 0, 0, 0, 0x13);
        n++;
      }
      return true;
    }, IntPtr.Zero);
    return n;
  }
}
'@
Add-Type -TypeDefinition $src
$ids = @(Get-Process -Name claude -ErrorAction SilentlyContinue | ForEach-Object { $_.Id })
if ($ids.Count -eq 0) { Write-Host 'Claude is not running.' }
else {
  $n = [ClaudeUnpin]::Run([int[]]$ids)
  if ($n -gt 0) { Write-Host "Unpinned $n Claude window(s)." } else { Write-Host 'No pinned Claude window found.' }
}
Start-Sleep -Seconds 2

Workaround written with Claude.

Also reproduces on macOS, so this doesn't seem to be Windows-only.

The Claude Desktop main window got stuck always-on-top right after a session where Claude controlled my computer (computer use). Before that session the window behaved normally; after it ended, the main window kept rendering above every other app even when another window had focus.

OS: macOS 26.6.2 (25G83)
Claude Desktop: 2.9939.2 (d3e504), built 2026-09-24
Workaround: quitting Claude and opening it again fixes it.