Windows: app window is always-on-top with no way to disable it

Still reproducing on Windows 11 Pro 25H2 (OS build 26200.9168), Claude Desktop 1.34493.1 (255293). Same symptom as described here — Claude Desktop stays on top of every other window; the other app takes focus but renders behind Claude instead of in front. No alwaysOnTop setting, no toggle in the app.

Agree this got lost in the shuffle between #87895 and #66516 — neither was actually resolved on the merits, and it's still broken. Would be good to get this reopened/tracked properly rather than closed as a dup of a dup.

Workaround for now: minimizing manually, or closing app.

Reproduced on Windows 11 Enterprise 10.0.26200, Claude desktop app 1.37937.1 (bundled Claude Code 2.1.246). I dug into the logs and I think I have the root cause, at least for this variant of the symptom.

Root cause: the stealth-update z-order restore anchors on the taskbar

Before applying a background ("stealth") update, the app saves the window that was immediately above it in z-order, so it can put itself back in the same place after relaunching. After the relaunch it re-inserts its window behind that saved anchor. If the anchor happens to be a topmost window, the app inherits WS_EX_TOPMOST from it, because on Win32 SetWindowPos(hwnd, <a topmost window>, ...) makes hwnd topmost too.

On my machine the anchor was the Windows taskbar.

%LOCALAPPDATA%\Claude\Logs\main.log:

2026-08-26 12:31:52 [info] [stealth-update] Triggering stealth update after idle timeout
2026-08-26 12:31:52 [info] [stealth-relaunch] Saved z-order anchor: 0x100de (above our 0x20624)
2026-08-26 12:31:52 [info] beforeQuitForUpdate handler fired, going down for update
2026-08-26 12:31:58 [info] Starting app { appVersion: '1.37937.1', ... }
2026-08-26 12:31:58 [info] [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, otherAppFullScreen=false)
2026-08-26 12:31:58 [info] [stealth-relaunch] Loaded z-order anchor: 0x100de
2026-08-26 12:32:00 [info] [stealth-relaunch] Restored z-order: our 0x80c42 behind anchor 0x100de

Identifying both handles afterwards with GetWindowLong(GWL_EXSTYLE):

| hwnd | process | class | ExStyle | topmost |
|---|---|---|---|---|
| 0x100DE (the anchor) | explorer.exe | Shell_TrayWnd — the Windows taskbar | 0x00000088 = WS_EX_TOPMOST \| WS_EX_TOOLWINDOW | yes |
| 0x80C42 (Claude main window) | claude.exe | Chrome_WidgetWin_1, title "Claude" | 0x00280108 (contains WS_EX_TOPMOST) | yes |

The same code path ran on an earlier update with a different anchor (2026-08-21 09:29:18 [info] [stealth-relaunch] Loaded z-order anchor: 0x10428), so which window ends up as the anchor — and therefore whether you get the bug — depends on what was above the app when the update fired. That would explain why this is intermittent for some people and permanent for others.

Ruled out on my machine:

• Not a stored preference — no alwaysOnTop key in %APPDATA%\Claude\config.json or window-state.json.
• Not the popout "Keep window on top" pin — that control only renders inside detached session popouts, and the log shows [popout-restore] Saving 0 session popout(s) for next launch.
• Not the computer-use side panel, which also pins the window — the log only ever contains [cu-side-panel] initialized, never docked.

Why restarting the app appears not to help

I restarted the app three times and the window stayed on top. The log explains it: clicking the icon starts a second process that hands off to the still-running primary and exits, so the offending window is never recreated.

2026-08-26 12:52:26 [info] Not main instance, returning early from app ready
2026-08-26 12:54:26 [info] second-instance: suppressing duplicate argv

A real fix requires quitting from the tray, not closing the window. Worth knowing when triaging reports that say "restarting doesn't help".

Suggested fix

In the stealth-relaunch z-order restore, don't inherit topmost from the anchor: check GetWindowLong(anchor, GWL_EXSTYLE) & WS_EX_TOPMOST and, if set, insert with HWND_NOTOPMOST (or pick the first non-topmost window below the anchor) instead of inserting after it. Excluding WS_EX_TOOLWINDOW and shell windows (Shell_TrayWnd, Shell_SecondaryTrayWnd) when saving the anchor would work too. Explicitly re-asserting the pre-update topmost state after the restore would make it robust either way.

Live workaround, no restart needed

Clears the flag on the running window:

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

Verified: ExStyle went from 0x00280108 to 0x00280100 and the window behaves normally again. It will come back at the next stealth update if the anchor is topmost again.

I am having the same issue.

This is absolutely annoying. Please fix this!

I can confirm that the workaround from @nvi-nsi works to fix the issue for the moment.

Same here!