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

[Excelmist]

Summary

The Claude Code desktop app window stays above all other windows. There is no setting, shortcut, or menu item to turn this off.

Environment

• Claude Code 2.1.138 (desktop app)
• Windows 10 Pro 22H2 (10.0.19045)

Steps to reproduce

1. Open the Claude Code desktop app
2. Open any other window (browser, editor, file explorer)
3. Click that window, or Alt+Tab to it

Expected: the other window comes to the front.

Actual: it takes keyboard focus but renders behind the Claude Code window, which stays on top.

Why this matters

It makes ordinary side-by-side work impractical — reading documentation in a browser while working in Claude Code, or copying between the two. The app cannot be used as one window among several.

What I checked before filing

• No alwaysOnTop key in ~/.claude/settings.json
• No window or appearance toggle in the app
• No documented keyboard shortcut

Workaround

Windows virtual desktops (Win+Ctrl+D), which works because "always on top" is per-desktop. Minimising the window also works but is not practical for frequent switching.

Related issues (both closed, neither fixed)

• [BUG] Claude Desktop window stays always on top on Windows #87895 (Windows) — closed as a duplicate of [BUG] Claude Desktop macOS window stays always on top of other apps #66516
• [BUG] Claude Desktop macOS window stays always on top of other apps #66516 (macOS) — closed as "not planned" / "invalid"

#87895 was closed as a duplicate of an issue that had itself been closed as not-planned, so this looks like it fell between the two rather than having been declined on merit. It still reproduces on 2.1.138.

[hkbird]

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.

[nvi-nsi]

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.

[chaitanyahanumanthavajjala]

I am having the same issue.

[renegrob]

This is absolutely annoying. Please fix this!

[marcOcram]

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

[Shadowjump]

Same here!

[nelsonpoon]

same here, we are the most biggest testing team for claude code,
we have no salary ever we paid for the service with bugs

[richgel999]

any fixes coming? this bug is really annoying

[Starfield3]

Still reproducing on 1.44121.4 (today) — and the same machine produced two different z-order anchors, which rules out a taskbar-specific fix

Posting here rather than on #85891 because this issue appears to be the correctly-triaged one (bug / has repro / platform:windows / area:desktop), whereas #85891 carries invalid despite ~67 comments of evidence. More on that at the end.

Environment: Windows 11 Home, build 26200, x64, single display. No PowerToys, DeskPins, AutoHotkey, DisplayFusion or comparable pinning utility — re-checked today across the uninstall registry (HKLM, WOW6432Node, HKCU), Get-AppxPackage, and the running process list.

Today's occurrence, handle-level

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

2026-09-03 10:22:46 [stealth-update]   Triggering stealth update after idle timeout
2026-09-03 10:22:46 [stealth-relaunch] Saved z-order anchor: 0x100dc (above our 0x2060c)
2026-09-03 10:22:56 [updater] Version changed since last launch: 1.40609.1 → 1.44121.4
2026-09-03 10:22:56 [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, otherAppFullScreen=false)
2026-09-03 10:22:56 [stealth-relaunch] Loaded z-order anchor: 0x100dc
2026-09-03 10:22:56 [stealth-relaunch] Restored z-order: our 0xb0490 behind anchor 0x100dc

Measured immediately after:

hwnd=0x0B0490  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) → 0x00280100, stayed cleared.

The anchor is not stable even on one machine

This is the part I think is new. The anchor resolves to:

hwnd=0x100DC  class=Shell_TrayWnd  proc=explorer     (2026-09-03)

On this same machine, six days earlier, it was:

hwnd=0x101E0  class=IslandWindow   proc=ClickToDo    (2026-08-28)

The thread so far has had Shell_TrayWnd on some machines and Click to Do on others, which left open the reading that it's per-machine configuration. It isn't — one machine, unchanged setup, two different anchors on two occurrences. It really is whatever topmost-band window happens to sit directly above Claude at capture time. A fix that special-cases the taskbar will not close this.

Four consecutive updates on one machine

Date	Version transition	[stealth-update] fired	Anchor saved	Topmost after
2026-08-28 08:50	1.37937.1 → 1.37937.3	yes	0x101e0 (ClickToDo)	yes
2026-08-29 09:26	1.37937.3 → 1.40609.0	no	—	no
2026-09-01 21:17	1.40609.0 → 1.40609.1	yes	0x19082e	yes
2026-09-03 10:22	1.40609.1 → 1.44121.4	yes	0x100dc (Shell_TrayWnd)	yes

Every update that took the idle-timeout stealth path with windowVisible=true set the flag; the one that didn't take that path (29 Aug) didn't. Three for three.

Two things follow. First, this is continuous, not a regression reintroduced in a recent build — same mechanism across 1.37937.x, 1.40609.x and now 1.44121.4. Second, I'd caution anyone against inferring the introducing version from an absence of the log line, as has been attempted a couple of times in #85891: the 29 Aug row above has no anchor line purely because the stealth path never ran, not because the code was missing from that build.

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)

SetWindowPos(hwnd, HWND_NOTOPMOST, SWP_NOSIZE|SWP_NOMOVE|SWP_NOACTIVATE) — drops the window out of the topmost band, touches nothing else. Restarting the app clears it too; nothing persists the flag. It comes back on the next qualifying update, so it's an unstick, not a fix.

Since the restore only runs when the window is visible, minimizing before stepping away should avoid it — consistent with the 29 Aug row and with the tables others have posted, though I haven't deliberately tested it.

Triage request

There are currently nine open or closed Windows reports of this one defect — #85891, #88093, this one, #90361, #88359, #91742, #87895, #89851, #87084 — carrying over 100 comments, plus #66516 on macOS. Five of the six open ones are labelled invalid, so the bulk of the evidence (including the root-cause analysis in #87084, closed as not-planned) is sitting outside the tracked issue. Could the others be marked duplicates of this one so it consolidates here?