[BUG] Claude Desktop (Windows 11): main window stays always-on-top of other applications, with no setting to disable it

I'm having this same issue. Why is it being marked as invalid?

Same problem on my end

I'm having this same issue. Why is it being marked as invalid?

I think theres some confusion whether or not this repro is for only claude code or if it also includes claude desktop. I reported this issue to support too.

Having the same issue today. Completely exiting Claude desktop didn't help and it was fine yesterday. I left the window open all night and this morning it's behaving this way.

Logging out & ending task on everything claude.exe seems to have resolved it, FYI.

Another independent reproduction, this time via Cowork's computer-use feature specifically.

Environment

• OS: Windows 10 Pro, build 19045 (22H2)
• Two displays attached

What I observed
While Claude was actively driving another application via computer-use (a legitimate GUI automation task, not the "Claude is using your computer" overlay itself), the main Claude chat window stayed rendered above the target application on every screenshot, even when that application was deliberately brought to focus and positioned on top. The only reliable fix was minimizing the Claude window before each screenshot.

This matches the repro and "Ruled out" section above exactly - no PowerToys, DeskPins, AutoHotkey, or other pinning utility installed, so the topmost behavior is coming from the app itself, not a third-party tool.

Worth reiterating: this isn't just a cosmetic annoyance. During active computer-use sessions it actively interferes with the task, since a target window can be correctly positioned by the user but still visually obscured by the always-on-top Claude window, making it hard to tell what's actually on screen versus what's simply covered. +1 on the suggested fix (explicit opt-in "Keep window on top" toggle, default off).

Same happened to me on Desktop App on Windows 11. Open Task Manager and 'End Task' on all open instances of Claude (I had 12 running even though it was closed). I think this might have something to do with remote-control.

I am having the exact same issue.

Same issue for me.

Confirm, I have same issue. Windows 11 and Claude 1.32885.1 (a757f5)

Logging out & ending task on everything claude.exe seems to have resolved it, FYI.

Worked for me, too.

Issue started past couple of days, and there was at least one update. Closing/killing all Claude related app (just the desktop app for me) fixed it.

Had same issue on Windows 11 Claude version 1.34493.1. Ending task seems to have fixed it for now

Confirming this on Windows 11 Pro, latest Claude Desktop, no update available.
Multi-monitor setup (3 displays). When the Claude window is filled on one
monitor and I switch to ANY app behind it (Word, Excel, etc.), that app does
not come to the front. Clicking the background window and Alt+Tab both fail
to raise it. Only minimizing Claude reveals what's behind it.

Not app-specific — happens with every application. PowerToys does not override
it, matching the original report. There is no in-app setting to disable it.

A simple on/off toggle for always-on-top would fix this.

One additional update - had this happen for a second time. Both times it has been when I was away from my computer for ~24h, so there's probably something related to the computer going to a low power state/sleep. Then when you come back, it's triggered as always on top.

I'm on 1.34493.1 on Win11.

Windows 11, same issue here. Claude Desktop persists over all other windows/programs whether maximized (cant switch to a different program), shunken but not minimized (it overlaps every program). Only fix is to minimize it or pin Claude to a side and another program to the other side.

Same issue. For me, this occurs when having an open/active project on Claude Desktop and then utilizing the Claude Mobile app for follow-ups. Force closing the desktop app returns the app to normal.

+1

Same issue here, "always on top"

same. following.

Confirming this is still happening. Windows 11, Claude Desktop reports "running the latest version" (checked via Help → Check for Updates), and the always-on-top behavior is still present. A restart of the app did fix the issue for me, but I'm not convinced it won't return.

Still present on Windows 11 in desktop app 1.34493.1 (binary 2.1.237).

WS_EX_TOPMOST is set on the main window; no other application on the same machine has the bit set. It survives a full quit and restart, and there is no entry for it under Datei / Bearbeiten / Ansicht / Hilfe. Nothing is persisted in config.json or window-state.json, so it looks like a runtime setAlwaysOnTop(true) rather than a restored preference.

Workaround, has to be repeated after every start: SetWindowPos(hWnd, HWND_NOTOPMOST, ...) via PowerShell.

in Windows, I shut down Claude, CTRL-ALT-DEL to task manager, searched for claude, and end task on claude background. it worked.

+2 , have to restart the whole app every now and then, kinda frustrating

Third confirmed instance of the #87084 mechanism — plus a version correction

Adding an independent reproduction with handle-level log correlation, and a correction to the version attribution in #87084 (which was auto-closed as "not about Claude Code", but contains the correct root-cause analysis).

Environment: Windows 11 Enterprise 26200, Claude Desktop 1.37937.0 (MSIX), single display.

The incident

From %LOCALAPPDATA%\Claude\Logs\main.log — note this is the live log; the %APPDATA%\Claude\logs\ copy is stale and misled me at first:

16:39:38  [stealth-relaunch] Saved z-order anchor: 0x501d6 (above our 0xee0cf4)
16:39:43  [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, ...)
16:39:44  [stealth-relaunch] Restored z-order: our 0x200724 behind anchor 0x501d6

Measured afterwards: hwnd 0x200724, GetWindowLong(GWL_EXSTYLE) = 0x00280108 → WS_EX_TOPMOST set. Same handle as the log line. Cleared with SetWindowPos(HWND_NOTOPMOST) → 0x00280100, and it stayed cleared. No PowerToys or other pinning utility installed.

The anchor is not necessarily the taskbar

#87084 identified Shell_TrayWnd. Here the anchor 0x501d6 is still alive and resolves to:

hwnd=0x0501D6  class=I  pid=14884  proc=ClickToDo  ex=0x00280088  TOPMOST=True

Windows Click to Do — a different topmost-band window. So the defect isn't taskbar-specific: any topmost-band window that happens to sit directly above Claude at capture time will do it. Fixes that special-case the taskbar won't be sufficient.

Trigger condition, which likely explains the intermittency in this thread

The restore only runs when the window is visible. My three most recent relaunches:

| Relaunch | windowVisible | Outcome |
|---|---|---|
| 2026-08-20 20:17 | false (minimized) | Window was minimized, restoring minimized — no z-order restore, no bug |
| 2026-08-21 00:28 | false (minimized) | same — no bug |
| 2026-08-25 16:39 | true | Restored z-order — topmost acquired |

That matches jalexand42's report above of it appearing overnight and being fine the day before: it depends on whether the window happened to be visible when the silent update landed.

Version correction

#87084 states the defect was "introduced in the 1.30096.x line." My logs put the z-order anchor code one release earlier, in 1.28929.0:

| Date | Version running at relaunch | z-order step logged? |
|---|---|---|
| 2026-08-07 10:15 | 1.26832.0 | No — navigation history only |
| 2026-08-13 19:49 | 1.28929.0 | Yes — Saved z-order anchor: 0x2056a |

This machine updated 1.26832.0 → 1.28929.0 with no intermediate version, so the anchor/restore step landed in 1.28929.0. [stealth-relaunch] itself is older — first seen here 2026-07-17 — so the anchor step was added to a pre-existing feature rather than shipping with it.

Scope caveat, which I think matters for triage of this thread

This mechanism cannot explain every report here. This issue's original report is on 1.26832.0, which predates the anchor code, and DreikalCC above attributes theirs to computer-use specifically. #87084 §E describes a second path — the screenshot wrapper re-asserting a sampled alwaysOnTop at the fixed screen-saver level, which can make a transient side-panel dock state permanent. There appear to be at least two independent routes to the same end state, and fixing only the stealth-relaunch anchor will leave the other one live.

Workaround

Clears until the next qualifying relaunch; restarting the app also clears it, since nothing persists the flag:

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 MainWindowTitle).MainWindowHandle
[N.W]::SetWindowPos($h, [IntPtr]-2, 0,0,0,0, 0x0013)

+1. The workaround from v-tab-vispero did the trick, I am saving that as claude-fix.ps1 until the actual fix comes around

If you close the application correctly the flag persists and application remains always-on-top on next load. If you kill the process via task manager the flag clears.

this is actually pissing me off

This just started happening to me tonight and it's really irritating.

Another data point — same [stealth-relaunch] anchor mechanism, still live on 1.37937.3, single display

Adding a fresh reproduction because this one sits on a newer version pair than anything reported in this thread so far, and the flag was acquired by the update that landed on this machine today. Until that update I had never seen the window get stuck on top.

Environment: Windows 11 Pro, build 26200, x64, MSIX / Store install, single display. No PowerToys, DeskPins, AutoHotkey or any comparable pinning utility installed or running (checked the uninstall registry, Get-AppxPackage, Program Files, and the running process list). Claude Desktop 1.37937.3, bundled Claude Code 2.1.246.

Handle-level correlation

From %LOCALAPPDATA%\Claude\logs\main.log (trimmed to the relevant lines):

20:34:41 [stealth-update]   Triggering stealth update after idle timeout
20:34:41 [stealth-relaunch] Saved z-order anchor: 0x1014c (above our 0x105b0)
20:34:41 beforeQuitForUpdate handler fired, going down for update
20:34:44 [updater] Version changed since last launch: 1.37937.1 -> 1.37937.3
20:34:44 [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, otherAppFullScreen=false)
20:34:44 [stealth-relaunch] Loaded z-order anchor: 0x1014c
20:34:44 [stealth-relaunch] Restored z-order: our 0x505e8 behind anchor 0x1014c

Measured ~3 h later at 23:59, window untouched in between:

hwnd=0x505E8  class=Chrome_WidgetWin_1  title='Claude'  proc=claude.exe
GWL_EXSTYLE=0x00280108  ->  WS_EX_TOPMOST set

Same handle as the log line. The saved anchor is still alive and resolves to:

hwnd=0x1014C  class=Shell_TrayWnd  proc=explorer.exe  ex=0x00000088  TOPMOST=True

— the taskbar, i.e. the anchor identity from #87084 rather than the Click to Do window @danim-hub measured. Both have now been observed in the wild on different machines, which supports their conclusion that the anchor is simply whatever topmost-band window happens to sit directly above Claude at capture time, and that a taskbar-specific fix would not be sufficient.

Single display

The original report raises multi-monitor as possibly relevant. This machine has exactly one display attached, so a second monitor is not required to reproduce.

The version attribution does not line up — this may not be a clean version cut

#87084 places the anchor code in the 1.30096.x line; @danim-hub's logs place it in 1.28929.0. My log covers 2026-08-21 to now and contains exactly one Saved z-order anchor line, on 1.37937.1. The previous update-quit, five days earlier, went 1.34493.1 -> 1.37937.1 and visibly took a different code path:

| Date | Outgoing version | Marker detected on the incoming side | z-order step logged | Topmost afterwards |
|---|---|---|---|---|
| 2026-08-25 23:10 | 1.34493.1 | [update-restart] Detected nav-restore marker, launching normally | none | no |
| 2026-08-26 20:34 | 1.37937.1 | [stealth-relaunch] Detected via marker file (windowVisible=true, ...) | saved + restored | yes |

Both quits were otherwise the same shape (beforeQuitForUpdate -> Windows session ending (close-app)), and the incoming 1.37937.1 did restore 30 navigation entries, so the old build clearly wrote a marker — just one without an anchor in it.

On this machine, then, the anchor step is absent from 1.34493.1 and present in 1.37937.1, which is later than either earlier attribution. Since 1.34493.1 is well past both 1.28929.0 and 1.30096.x, "introduced in version X" may be the wrong model — the step looks gated (feature flag or install channel; this box is MSIX and the app boots a growthbook client at startup) rather than being a straight version cut. That seems worth confirming before this is closed as "fixed in \<version\>", since a gated rollout can re-enable the path on machines that already look patched.

Why it seems to appear out of nowhere

Several reports here describe it turning up overnight or "just started tonight". On an MSIX install the log shows [CCD-autoupdate] Disabled: MSIX install, and the relaunch is driven by [stealth-update] Triggering stealth update after idle timeout — no user action and no visible restart. Combined with @danim-hub's finding that the restore only runs when windowVisible=true, that accounts for the "it was fine yesterday" pattern: it lands on whichever idle-time update happens to catch the window on screen.

Open question on the workaround

I have deliberately not cleared the flag on this machine yet, so I cannot speak to whether it survives a clean quit — @jaymaart reports that it does and that killing the process is what clears it, while @zeldakos reports the same via Task Manager. If a clean before/after measurement of GWL_EXSTYLE across quit-vs-kill would help triage separate the two paths described in #87084, I still have the untouched state here and am happy to log it.

Same issue here

This is really annoying, please fix asap

Having the same issue, but only after I upgraded to 1.37937.3

Another confirmation of the [stealth-relaunch] anchor mechanism — single display, Click to Do anchor, acquired on 1.37937.1 → 1.37937.3

Environment: Windows 11 Home, build 26200, x64. Single display (1920×1080). Claude Desktop 1.37937.3. No PowerToys, DeskPins, AutoHotkey, DisplayFusion or comparable pinning utility — checked the uninstall registry (HKLM, HKLM\WOW6432Node, HKCU), Get-AppxPackage, and the running process list; nothing matched.

Handle-level correlation

From %LOCALAPPDATA%\Claude\logs\main.log:

2026-08-28 08:49:38 [stealth-update]   Triggering stealth update after idle timeout
2026-08-28 08:49:38 [stealth-relaunch] Saved z-order anchor: 0x101e0 (above our 0x1065a)
2026-08-28 08:50:45 [updater] Version changed since last launch: 1.37937.1 → 1.37937.3
2026-08-28 08:50:45 [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, otherAppFullScreen=false)
2026-08-28 08:50:45 [stealth-relaunch] Loaded z-order anchor: 0x101e0
2026-08-28 08:50:45 [stealth-relaunch] Restored z-order: our 0x30632 behind anchor 0x101e0

Measured ~4 h later, window untouched in between:

hwnd=0x30632  class=Chrome_WidgetWin_1  title='Claude'  proc=claude.exe
GWL_EXSTYLE=0x00280108  ->  WS_EX_TOPMOST set

Same handle as the log line. SetWindowPos(HWND_NOTOPMOST) cleared it to 0x00280100 and it stayed cleared.

The saved anchor is still alive and resolves to:

hwnd=0x101E0  class=IslandWindow  pid=25716  proc=ClickToDo  ex=0x00280088  TOPMOST=True

Windows Click to Do — the same anchor identity reported above rather than Shell_TrayWnd. That's now two independent machines on Click to Do and two on the taskbar, which supports the conclusion that the anchor is simply whatever topmost-band window happens to sit directly above Claude at capture time. A fix that special-cases the taskbar would not cover this.

Single display

This machine has exactly one display attached, matching the other single-display reports above — a second monitor is not required to reproduce, despite the original report raising it as possibly relevant.

A caution on the version attribution

This thread currently places the anchor step in 1.28929.0 and in the 1.30096.x line. My log runs 2026-08-22 to now and contains exactly one Saved z-order anchor, on 1.37937.1, with none on the two earlier updates in the window.

I would caution against reading that as a version cut, including for my own machine. The 26 Aug update took a visibly different path:

2026-08-26 06:36:42 [updater] Version changed since last launch: 1.34493.1 → 1.37937.1
2026-08-26 06:36:42 [update-restart] Detected nav-restore marker, launching normally

No [stealth-update] Triggering line preceded it, so the idle-timeout path never ran and the anchor step had no opportunity to fire — regardless of which version the code was in. Absence of the log line means "the stealth path didn't run here", not "the code isn't in this build". Only the positive sightings constrain the version; inferences from absence (mine included) aren't reliable.

Workaround

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)

Restarting the app clears it too — nothing persists the flag. And since the restore only runs when windowVisible=true, minimizing the window before stepping away avoids it entirely.

Finally: this is still labelled invalid with 30+ independent confirmations and handle-level log evidence from several machines. Could it be re-triaged?

I discovered this issue for myself this morning. Really annoying UX. Would you like me to spin up Claude Code and fix it for you 😂

Annoyed!😡 Please fix.

I'm worried that it's marked as invalid, as it may cause it to be ignored.

@mullman2 You don't have to wait for the fix to get unstuck — nothing persists the flag, so it's clearable right now. Three options, easiest first:

1. Fully quit and restart Claude Desktop. Check Task Manager afterwards and make sure no claude.exe survives — several people in this thread (and I) found a dozen or more background instances still running after "closing" the app. This clears it until the next qualifying update.

2. Clear it in place, without restarting. PowerShell, no admin needed:

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)

That is just SetWindowPos(hwnd, HWND_NOTOPMOST, SWP_NOSIZE|SWP_NOMOVE|SWP_NOACTIVATE) — it drops the window out of the topmost band, exactly like unticking an "always on top" box. It doesn't touch the app, your conversations, or any setting. It prints True if it worked. To confirm, read GetWindowLong(hwnd, GWL_EXSTYLE): 0x00280108 before, 0x00280100 after — bit 0x8 is WS_EX_TOPMOST.

3. Stop it recurring. The z-order restore only runs when the window is visible at update time — the log line reads windowVisible=true. If you minimize Claude Desktop before stepping away, the idle-timeout update takes the harmless path and the flag is never applied. That's been the pattern across the logs posted here, including mine.

Caveat on 2: it holds until the next update that re-triggers the restore, so you may need to re-run it. It's an unstick, not a fix.

On the label — agreed, that's the real risk, and it's why I asked about re-triage in my comment above. It might also be worth people filing through Anthropic support in parallel, since that routes to the desktop team directly and this tracker apparently doesn't for area:desktop.

. Clear it in place, without restarting. PowerShell, no admin needed:

That did the trick! I now have a work-around to the annoying condition. Thanks @Starfield3 for the help!!!

@mullman2 You don't have to wait for the fix to get unstuck — nothing persists the flag, so it's clearable right now. Three options, easiest first: 1. Fully quit and restart Claude Desktop. Check Task Manager afterwards and make sure no claude.exe survives — several people in this thread (and I) found a dozen or more background instances still running after "closing" the app. This clears it until the next qualifying update.

For me, just closing out those other instances fixed the issue. Thank you.

I ran into this today, just chiming in that I was able to fix the issue temporarily, ironically, by enabling PowerToys's Always on Top via the shortcut and then disabling it.

The issue resolved for me by going to the task manager and ending the task for all claude instances, when I reopened the Claude desktop again, it worked like normal.

To alleviate the issue and keep Claude desktop running, here's a PowerShell command that will leave Claude desktop running but force the ghost window to the bottom of the screen stack: force_claude_to_background.cmd

Confirming the same issue on Windows 11 Home, version 25H2 (OS Build 26200.9278).
Claude Desktop app version: 1.40609.0.0
Multi-monitor setup: yes, 2 monitors in use.
Symptom matches exactly: main chat window stays topmost even after switching focus to another app. Minimizing is the only workaround.

Use the gist above and you won't need to minimize it: issue comment 5458891280.