[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).