Windows: Claude desktop app window intermittently gets stuck as always-on-top (WS_EX_TOPMOST)

Status Open

Maintainer reply None cached

Activity 4 comments · opened Sep 18, 2026

Summary

On Windows, the Claude desktop app's main window intermittently gets stuck with the WS_EX_TOPMOST ("always on top") extended window style set. Once this happens, the window stays visually on top of every other application — even after switching focus to another app or clicking another window — until the whole PC is rebooted. Simply restarting the Claude app does not always clear it (a freshly-opened window can already carry the flag).

Environment

OS: Windows 11 Home, build 10.0.26200
Claude desktop app: observed on package version Claude_2.2553.0.0_x64__pzs8sxrjxfjjc (Microsoft Store / MSIX install), and recurred again after a later auto-update
Not caused by a third-party "always on top" utility — confirmed PowerToys and similar tools are not installed/running on the affected machine

What I confirmed (not just a visual impression)

Using the Win32 API directly (GetWindowLong with GWL_EXSTYLE), I verified multiple times, on different days/sessions, that the Claude app's visible top-level window has the WS_EX_TOPMOST (0x8) bit set even when:

it is not the foreground window (confirmed via GetForegroundWindow() returning a different app's window while Claude's EXSTYLE still shows the topmost bit), and
nothing the user did (that they were aware of) should have requested always-on-top behavior.

Forcing the bit off directly via SetWindowPos(hwnd, HWND_NOTOPMOST, 0,0,0,0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE) immediately and durably fixes the symptom for that window instance (does not silently get re-asserted by the app afterward), which is strong evidence this is a stuck/leftover window style rather than an intentional, continuously-enforced feature.

This is not a one-off: it has now been observed to recur across multiple separate days on the same machine, sometimes appearing again on a freshly-launched app window (new PID) after the machine was rebooted, so it is not something that only accumulates within one long-running process session.

Possible (unconfirmed) trigger

One occurrence's timing lined up closely with a Claude app auto-update (Windows Event Log showed the app's MSIX package/service being reinstalled a few minutes before the symptom was next observed). I can't confirm this is the actual trigger — it may be coincidental — but it's the only correlation I've been able to find so far, since the bug does not seem to depend on any specific in-app action the user remembers taking.

Impact

The window aggressively covers other applications regardless of focus, which is disruptive when working with multiple windows/monitors. The only reliable fix a non-technical user has today is a full PC reboot.

Workaround used to confirm/mitigate

As a stopgap on the affected machine, a small script polls for the Claude window(s) and clears WS_EX_TOPMOST via SetWindowPos whenever it's set. This reliably resolves the symptom within a few seconds each time it recurs, which further supports that the underlying issue is the app (or Electron) leaving this window style set rather than continuously re-applying it.

Happy to provide more diagnostic detail (window handles, exact timestamps, event log excerpts) if useful.

View original on GitHub ↗

3 Comments

bjmacdonald · 27 days ago

I am experiencing the same issue on 2.2553.1.

My workaround is to use PowerToys' AlwaysOnTop which provides a Win-Ctrl-T shortcut to clear the flag.

DMelson · 27 days ago

Same bug here, and I think I've found the trigger — it lines up with the Cowork / VM service idle cycle, not auto-update.

Environment (matches this issue):

Windows 11 Pro build 26200
Claude Desktop 2.2553.0.0 (MSIX / Store install)

What I captured. A watcher polls WS_EX_TOPMOST on the Claude main window every second and logs each transition plus the foreground process at that instant. It caught the pin at 18:23:25 local, with the foreground window being Idle (PID 0) — nobody was interacting with the machine (it had just auto-locked).

The correlation. C:\ProgramData\Claude\Logs\cowork-service.log shows the VM service cycling at that exact second:

18:23:19  [Server] ...has no active connections, idle timeout starts
18:23:19  Service stop requested → Claude VM Service stops
18:23:21  Starting CoworkVMService... (pkg Claude_2.2553.0.0) → restarts
18:23:25  [Server] Client connected            ← claude.exe reconnects; window pins here
18:23:26  new VM session created

The window flips topmost at the same second claude.exe reconnects to the freshly restarted VM service. The service log itself has no window/topmost lines (window management is app/renderer side), but the timing is exact.

So it's not auto-update (at least here) — it's the app re-asserting topmost on its own main window when it re-attaches to the VM/cowork service after that service cycles on idle.

Repro: leave the machine idle long enough to auto-lock, so the VM service hits its idle timeout and restarts. On reconnect, the main window is pinned. Manual lock/unlock does not reproduce it (no service cycle).

Not persisted / not a 3rd-party tool: the flag is set at runtime (not in window-state.json / config.json), it's only ever the Claude main window, and PowerToys / other pinning tools were confirmed off.

Workaround (same as others here): SetWindowPos(hwnd, HWND_NOTOPMOST, 0,0,0,0, SWP_NOSIZE|SWP_NOMOVE|SWP_NOACTIVATE).

Posted by Claude on behalf of Dan.

channeu-nim · 27 days ago

Additional data point: this has now recurred a second time, and both times it correlates exactly with a Claude desktop app auto-update.

First occurrence: app auto-updated (package reinstall event in Windows Event Log) at 2026-09-18 04:20:41 (version 2.2553.0.0). My monitoring script's last successful check was at 04:11:50; it (and the underlying symptom) was next observed broken/stuck shortly after.
Second occurrence: app auto-updated again at 2026-09-18 21:24:08, bumping the package version from 2.2553.0.0 to 2.2553.1.0. My monitoring script's last successful check was at 21:21:40 — i.e. the update landed almost immediately after, and the always-on-top symptom was present again the next time I checked (2026-09-19 morning).

Both times, the Windows Event Log shows the same signature at the moment things broke: a Service Control Manager event 7045 reinstalling the Claude user-mode service (cowork-svc.exe), bracketed by two 7040 events toggling the IsolationSession service start type (demand → auto → demand), i.e. this is the app's own auto-update/relaunch sequence, not something external.

Given two-for-two, I'm now fairly confident the auto-update (or the relaunch it performs afterward) is what leaves the new window with WS_EX_TOPMOST set — possibly the updater/relaunch path creates or shows the main window without going through whatever code path normally clears/never-sets that style, or a "keep on top while restoring session" step doesn't get undone.

Showing cached comments. Read the full discussion on GitHub ↗