[BUG] [BUG] Claude Desktop (Windows) window stays always on top of other apps Environment

[BUG] Claude Desktop (Windows) window stays always on top of other apps

Environment

OS: Windows (win32, x64)
Claude Desktop app version: 1.32885.1
Electron version: 42.9.2

Description The main Claude Desktop window stays pinned above all other application windows on Windows — it doesn't behave like a normal window and won't drop behind other apps when they're focused. This started after a recent app update; I did not have this issue on the previous version I was running.

There's a related closed/existing report for the same symptom on macOS (#66516), but this is happening on Windows, and I don't see a Windows-specific report filed yet.

Expected behavior The Claude Desktop window should behave like a standard Windows window — i.e., not float above other applications once another app is focused.

Steps to reproduce

Open Claude Desktop on Windows.
Switch focus to any other application window.
Observe that the Claude Desktop window remains visible on top of the other window instead of moving behind it.

Workaround found Minimizing the Claude Desktop window is the only workaround; there's no in-app setting to disable "always on top" behavior.

Additional notes

Fully quitting the app via the system tray icon and relaunching does not resolve it.
Already on the latest available app version (1.32885.1), so this is not fixed by updating.

This bug was reported under Claude code and closed....
https://github.com/anthropics/claude-code/issues/66516

I'm also experiencing the bug... Their suggested workaround also worked for me.

$sig = 'using System;using System.Runtime.InteropServices;public class WT{[DllImport("user32.dll")]public static extern bool SetWindowPos(IntPtr h,IntPtr a,int x,int y,int cx,int cy,uint f);}'
Add-Type -TypeDefinition $sig
$h = (Get-Process claude | Where-Object {$_.MainWindowHandle -ne 0}).MainWindowHandle
[WT]::SetWindowPos($h, [IntPtr](-2), 0, 0, 0, 0, 0x0013) # HWND_NOTOPMOST, NOSIZE|NOMOVE|NOACTIVATE

Update — still present on a newer build.

Confirming this is not fixed by updating. I'm now on:

• Claude Desktop 1.34493.1 (three releases newer than the 1.32885.1 in the original report)
• Electron 42.9.2 / Node 24.18.1
• Windows, win32 x64

Behavior is unchanged: the main window keeps WS_EX_TOPMOST and stays above other applications on focus change, with no in-app setting to disable it. The SetWindowPos / HWND_NOTOPMOST snippet above does clear the flag, but it has to be re-run — I haven't confirmed whether the app re-applies it on show/focus or whether it's only lost across restarts.

Really annoying issue, shoudl be easy to fix, just get claude to fix it !

happening to me too - very annoying

Confirming this — Claude Desktop stays on top and won't yield focus to another (already-running) app when maximized via the taskbar. Same symptom as described above. Quite annoying.

Same issue here, confirming on another machine and a newer build.

OS: Windows 11 Pro (10.0.26200)
Claude Desktop app version: 1.37937.3.0 (Microsoft Store install)
Embedded Claude Code: 2.1.220
Exact symptom as the original report: the window stays topmost after focus moves to another app — Alt+Tab does switch focus but Claude keeps covering the target window, so it feels like you can't leave it. Minimising is the only thing that releases it. Started after a recent update; fully quitting and relaunching doesn't clear it.

Same issue here!

Me too.

Hi guys,

Full re-install worked for me like a charm and fixed the issue.

Platform: Windows 11
App version: 1.40609.0.0
Personal device

FYI this means re-downloading of the Cowork VM bundle ~8.4GB -- you can try saving it before nuking by backing up LocalCache\Roaming\Claude\vm_bundles

After I restart the system, it automatically recovers.

Platform: Windows 11 Enterprise
App version: 1.40609.0

Still reproducing on 1.40609.0.0 (Microsoft Store install), so the latest build does not fix it.

Environment

• OS: Windows 11 Home China, build 10.0.26200
• Claude Desktop: 1.40609.0.0 (Microsoft Store install)
• Single display, 1440x900 logical, scaleFactor 2
• Personal account (no Team/Enterprise entitlements)

Measured, not just observed

I enumerated top-level windows and read the extended window style directly rather than judging by eye. The main Claude window really does have the topmost bit set:

PID 29024 | title "Claude" | rect -7,-7 -> 1446,858 (maximized) | WS_EX_TOPMOST = set

The only other legitimately topmost windows on the desktop were the taskbar (explorer) and the Windows 11 "Click to Do" overlay. So this is genuinely WS_EX_TOPMOST on the main window, not a focus or z-order quirk.

This also explains why clicking a taskbar button "does nothing": the target window is restored and does receive focus (keystrokes reach it), it is simply drawn underneath the topmost Claude window, which was maximized to full screen.

Clearing it in place worked

Same approach @Starfield3 posted in #85891: SetWindowPos with HWND_NOTOPMOST and SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE. After the call the style bit reads clear and the window behaves normally again. No restart, no window moved, no focus stolen. This also independently confirms their observation that nothing persists the flag — I checked config.json, window-state.json and claude_desktop_config.json and none of them contain an always-on-top key.

Trigger data point: I have never used the Office add-in

I am on a personal account and cannot use it. So whatever sets the flag is not confined to that code path.

Please be careful with the "end all claude.exe tasks" advice in this thread

On my machine there are 12 processes named claude.exe, and they are not stray instances:

• 10 are the normal Electron tree for a single app instance: 1 main process, 2 renderers, 1 GPU process, 1 crashpad handler, and utility processes for network, audio, video capture, and two Node services.
• 1 is a separate Claude Code CLI that the desktop app itself spawns from AppData\Roaming\Claude\claude-code\<version>\claude.exe, running with --resume=<session-id>. Killing it drops a live session.
• 1 is my own unrelated Claude Code CLI in .local\bin.

So "a dozen or more background instances still running" is, at least here, just Electron's normal multi-process architecture. Advising people to end every claude.exe is more destructive than it sounds.

Possible root cause (hypothesis, for whoever picks this up)

There are several call sites that set always-on-top in the app bundle, and at least two of them touch the main window:

1. The Office add-in bridge's focus_desktop handler, on win32, effectively does:

``
setAlwaysOnTop(true) -> focus() -> setTimeout(() => setAlwaysOnTop(false), 100)
``

That is a focus-stealing workaround guarded only by a 100 ms timer. Anything that interrupts those 100 ms leaves the flag set permanently. (On my machine this specific path cannot be the trigger, since I never use the add-in — but the same fragile pattern may exist on other paths.)

1. A screenshot / content-protection helper snapshots isAlwaysOnTop() for every window, enables content protection, and in a finally block re-applies always-on-top to each window that was topmost. If that snapshot is taken during another mechanism's temporary topmost interval, it will re-apply topmost afterwards — and that re-application is not on a timer, so it sticks.

A race between those two would explain both why the flag survives and why it appears unrelated to anything the user did.

Suggested fixes, in increasing order of effort

1. Ship a user-facing "Always on top" toggle, default off. Even if the underlying race remains, users stop being trapped with no way out.
2. Replace the 100 ms timer with an explicit restore tied to the focus result, or use SetForegroundWindow + AttachThreadInput instead of borrowing topmost to steal focus.
3. Make the content-protection restore skip windows whose topmost state was set by the focus workaround (e.g. tag it, or ignore states set within the last N ms).

@GeekShopAdmin you asked whether the flag gets re-applied on show/focus or is
only lost across restarts. Data point from my machine, it is neither, it stayed
clear:

• cleared once, then normal z-order behaviour across arbitrary focus changes
• survived a full app restart (quit via tray icon, relaunch)
• survived a Windows reboot, still normal since

Caveat: @ReasonDuan reports a reboot alone restored normal behaviour, so the
reboot is not proof that the clearing itself is permanent. What it does show is
that nothing re-applies WS_EX_TOPMOST at startup, which fits the race hypothesis
above rather than a persisted setting.

Also worth adding for non-technical readers: the same fix is available without
running any code. Install Microsoft PowerToys, focus the Claude window and press
Win+Ctrl+T twice (pin, then unpin). The Always on Top utility ends up making the
same HWND_NOTOPMOST call as the PowerShell snippet above. No restart, no
reinstall, no 8.4 GB Cowork bundle re-download.

Environment:

• Claude Desktop 1.40609.0 (f65e38), build 2026-08-27
• Windows 11 25H2, build 26200.9168
• PowerToys 0.100.2
• Personal account, single user

Same app build that @mckeygilham618-hub still reproduces on, and the same
26200 branch, so this is a way out on the current version rather than a fix
that arrived with an update.

Same issue here. As a workaround, I'm using Microsoft PowerToys to disable 'Always On Top' for Claude every time I launch it.

Surprisingly, after two weeks, Anthropic have not yet fixed this problem, even though it should be a fairly easy fix. The usability of their desktop app doesn't seem to be a priority.

Having the same issue where the Claude Desktop windows app is always on top and it is seriously annoying!

Same issue on 1.44121.2

me parece incomprensible que una app como claude tenga ese "bug". Me da la impresión de que es a proposito, el sistema de ventanas lleva decadas, no se me ocurre ninguna forma de que los ingenieros de claude "no sepan" como corregirlo

I dug into this on Windows and think I have the root cause. It isn't an always-on-top setting at all — the window gets promoted into the topmost band by the stealth auto-update relaunch, via a SetWindowPos side effect.

Mechanism

To avoid visibly stealing focus during a background update, the app records the window sitting directly above ours before quitting:

let n = Xp(V), r = e.getWindowAbove(n);
r && (t.zOrderAnchorHwnd = r, D.info(`[stealth-relaunch] Saved z-order anchor: %s (above our %s)`, ...))

and on relaunch re-inserts itself at that position:

Ao(), e.showInactive();
if (cN) { let t = Dr(); if (t) { let r = Xp(e); t.moveWindowBehind(r, cN), ... } }

moveWindowBehind is a SetWindowPos(hwnd, anchor, ..., SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE) in claude-native-binding.node. Per the documented Win32 contract for hWndInsertAfter:

If the window identified by the hWndInsertAfter parameter is a topmost window, the window being positioned becomes a topmost window.

So whenever the saved anchor happens to be a topmost window, the restore silently promotes the main window to WS_EX_TOPMOST — permanently, and invisibly to the app's own state.

That explains why there's no way to turn it off: the app never calls setAlwaysOnTop, so Electron's internal alwaysOnTop stays false, no pin or menu item reflects it, and nothing is persisted in config.json / window-state.json.

This is not a rare race. getWindowAbove returns the next window up the z-order, and shell surfaces like the taskbar are themselves topmost, so they sit above every ordinary window.

Evidence

Six stealth updates from my %LOCALAPPDATA%\Claude\logs\main.log, with each saved anchor handle resolved back to a window. The anchor's topmost state predicts the outcome exactly:

| Date | Version change | Anchor window | Anchor topmost? | Restored z-order logged | Pinned |
|---|---|---|---|---|---|
| 08-20 | 1.34493.0 → 1.34493.1 | explorer Shell_TrayWnd (taskbar) | yes | yes | yes |
| 08-26 | 1.34493.1 → 1.37937.1 | (handle no longer valid) | ? | no | no |
| 08-26 | 1.37937.1 → 1.37937.3 | ClickToDo IslandWindow | yes | yes | yes |
| 09-01 | 1.40609.0 → 1.40609.1 | a TeamsWebView window | no | no | no |
| 09-02 | 1.40609.1 → 1.44121.2 | ClickToDo IslandWindow | yes | yes | yes |
| 09-02 | 1.44121.2 → 1.44121.4 | explorer ApplicationManager_ImmersiveShellWindow | yes | yes | yes |

Four distinct anchor windows across three processes, all topmost, all producing the pin. The one anchor confirmed not topmost did not. Four occurrences in fourteen days — roughly every other forced update.

Most recent, still reproducing on 1.44121.4:

2026-09-02 23:53:38 [stealth-update]   Triggering stealth update after idle timeout
2026-09-02 23:53:38 [stealth-relaunch] Saved z-order anchor: 0x101e8 (above our 0x3202e6)
2026-09-02 23:53:43 [updater]          Version changed since last launch: 1.44121.2 -> 1.44121.4
2026-09-02 23:53:43 [stealth-relaunch] Loaded z-order anchor: 0x101e8
2026-09-02 23:53:44 [stealth-relaunch] Restored z-order: our 0xd0b7e behind anchor 0x101e8

Window 0xd0b7e afterwards: ex=0x280108 = WS_EX_TOPMOST | WS_EX_LAYERED | WS_EX_WINDOWEDGE | WS_EX_NOREDIRECTIONBITMAP.

Note the runs that logged Loaded z-order anchor but never Restored z-order did not pin, which localizes the promotion specifically to the moveWindowBehind call.

Ruled out: no third-party always-on-top utility running (no PowerToys, AutoHotkey, DeskPins, WindowTop); [cu-side-panel] only ever logged initialized, never docked, so the side-panel dock path is not involved.

Suggested fix

Check whether the anchor is topmost before calling moveWindowBehind and skip the anchor restore if it is, falling back to the existing focusWindow(previousForeground) path. Alternatively, skip past topmost windows when capturing the anchor, or follow the insert with an explicit SetWindowPos(hwnd, HWND_NOTOPMOST, ...) when the window was not topmost before the relaunch.

Workaround

Clearing the style externally holds — I have watched it stay cleared across normal use, and nothing in the app re-asserts it until the next stealth relaunch:

SetWindowPos(hwnd, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE)

One open question: this report says quitting from the tray and relaunching does not resolve it. On my reading of the code it should, because the relaunch marker is unlinked after it is read, so an ordinary launch has no anchor to restore and creates a fresh non-topmost window. I have not verified a clean tray-quit myself. If others can confirm a full restart really doesn't clear it, there may be a second path that re-applies the anchor — worth checking whether the tray quit is fully terminating the process.

Triage note

Since the mechanism is in the desktop app's stealth-relaunch path rather than in Claude Code, this may need routing to the desktop app team. #85891 describes the same bug and is currently labelled invalid as "not related to Claude Code"; #87895 looks like the same issue, and #66516 is the macOS analogue, closed as invalid.

Still reproducing on a much newer build. Adding a concrete measurement of the
window flag, which I don't think has been posted on any of the related issues yet.

Environment

• OS: Windows 11 (win32, x64)
• Claude Desktop: 1.46388.4
• Electron: 42.10.0
• Node: 24.18.1
• Install: MSIX package (Claude_pzs8sxrjxfjjc), installed from the official

Windows installer — not from the Microsoft Store

Root cause is WS_EX_TOPMOST on the main window

The extended window style of the Claude main window is 0x00280108:

| Bit | Flag |
|-----|------|
| 0x00000008 | WS_EX_TOPMOST |
| 0x00000100 | WS_EX_WINDOWEDGE |
| 0x00080000 | WS_EX_LAYERED |
| 0x00200000 | WS_EX_NOREDIRECTIONBITMAP |

Reproduced with:

Add-Type @"
using System;
using System.Runtime.InteropServices;
public class W {
  [DllImport("user32.dll")] public static extern int GetWindowLong(IntPtr h, int i);
}
"@
Get-Process | Where-Object { $_.MainWindowHandle -ne 0 -and $_.Name -match 'Claude' } |
  ForEach-Object {
    $ex = [W]::GetWindowLong($_.MainWindowHandle, -20)  # GWL_EXSTYLE
    "TOPMOST={0}  exstyle=0x{1:X8}" -f (($ex -band 0x8) -ne 0), $ex
  }
# => TOPMOST=True  exstyle=0x00280108

It is not persisted state

I checked the app's own config under
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\:

• window-state.json only stores

{width, height, x, y, isMaximized, isFullScreen, displayBounds} —
no alwaysOnTop key at all

• config.json contains no always-on-top / topmost key either

So the flag is being applied by the app at runtime, not restored from a saved
setting. That also explains why a restart doesn't clear it, as other reporters
have noted.

Workaround

Clearing the flag externally works and survives until the next app launch:

# SetWindowPos(hwnd, HWND_NOTOPMOST, 0,0,0,0, NOSIZE|NOMOVE|NOACTIVATE)
[W]::SetWindowPos($h, [IntPtr](-2), 0,0,0,0, 0x0013)

Since a single call is enough per launch, the app appears to set TOPMOST once
at window creation rather than re-applying it periodically.

Why this matters

During long-running tasks the window covers the editor / browser the whole time,
and minimising it or moving it to a separate virtual desktop are the only
in-product options. An explicit "always on top" toggle in Settings would be fine
too — the problem is that it is on with no way to turn it off.

Still Happening

It's very annoying, can this get prioritized.

Very annoying bug. Please fix this one. :(