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!

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

any fixes coming? this bug is really annoying

**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?

Confirmed via Win32 API on Claude Desktop 1.44121.4.0, Windows 11 Pro:

Get-Process | Where-Object { $_.MainWindowHandle -ne 0 -and $_.ProcessName -like "laude" } | ForEach-Object {
$ex = [W]::GetWindowLong($_.MainWindowHandle, -20)
[PSCustomObject]@{ Process=$_.ProcessName; Titre=$_.MainWindowTitle; Topmost=(($ex -band 0x8) -ne 0) }
}

Result: Topmost = True (WS_EX_TOPMOST flag confirmed set)

Manually clearing it via SetWindowPos(HWND_NOTOPMOST) restores normal window
behavior for the session - confirms this is set by the app itself, not the OS
or a third-party tool. Flag returns on next app relaunch.

Third distinct anchor process: TextInputHost.exe — an invisible IME helper window (1.44121.4, Windows 11 Pro 26200)

Adding one data point to @Starfield3's "the anchor is whatever topmost-band window happens to sit above Claude" finding, since this one is neither the taskbar nor Click to Do.

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

2026-09-03 11:22:11 [info] [stealth-update]   Triggering stealth update after idle timeout
2026-09-03 11:22:11 [info] [stealth-relaunch] Saved z-order anchor: 0x10438 (above our 0x50998)
2026-09-03 11:22:12 [info] [updater] Version changed since last launch: 1.44121.2 → 1.44121.4
2026-09-03 11:22:12 [info] [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, otherAppFullScreen=false)
2026-09-03 11:22:12 [info] [stealth-relaunch] Loaded z-order anchor: 0x10438
2026-09-03 11:22:13 [info] [stealth-relaunch] Restored z-order: our 0x60998 behind anchor 0x10438

Both handles resolved afterwards with GetWindowLongPtrW(GWL_EXSTYLE):

| hwnd | process | class | ExStyle | topmost |
|---|---|---|---|---|
| 0x10438 (anchor) | TextInputHost.exe | Internet Explorer_Hidden | 0x08000088 = WS_EX_TOPMOST \| WS_EX_TOOLWINDOW \| WS_EX_NOACTIVATE | yes |
| 0x60998 (main window) | claude.exe | Chrome_WidgetWin_1, title "Claude" | 0x00280108 | yes |

SetWindowPos(HWND_NOTOPMOST) → 0x00280100, stayed cleared.

No pinning utility on this machine (checked uninstall registry, Get-AppxPackage, running processes), and no alwaysOnTop key in config.json, window-state.json, Local Storage or IndexedDB. The main window is created with alwaysOnTop:!1 in the bundle and no setAlwaysOnTop appears anywhere in the log — consistent with the flag being acquired from the anchor rather than set by the app.

Two notes on the suggested fixes upthread:

• A class-based filter on Shell_TrayWnd / Shell_SecondaryTrayWnd would not have caught this anchor. The WS_EX_TOOLWINDOW exclusion would have, but only incidentally — the window is a hidden IME host that a user never sees or interacts with, so "skip anything the user can't have been looking at" isn't a property you can derive from class or visibility here.
• Testing WS_EX_TOPMOST on the anchor before inserting after it (or clearing with HWND_NOTOPMOST after the restore) remains the only check that is robust regardless of which window wins the race.

This machine was also topmost on 1.37937.3 and 1.40609.0 in the preceding days, matching the "continuous, not a recent regression" reading; I only have anchor-level log evidence for today's occurrence, as the log had rotated.

I make it short for the anyone else, who is also affected, should give this a thumps up.

me is also affected

Same issue happening for me. It happens on both on Desktop and Laptop with Windows 11, even on different accounts. Very annoying.

Important information here, the trigger condition for this bug: https://github.com/anthropics/claude-code/issues/85891#issuecomment-5518654248

Fourth distinct anchor process: a tooltip control owned by an unrelated third-party app (SumatraPDF / tooltips_class32)

Confirming @nvi-nsi's stealth-relaunch z-order-anchor mechanism on another machine, with handle-level log correlation. Posting because the anchor here is neither a shell window nor an IME helper — it is an ordinary tooltip control belonging to an unrelated application, which I think matters for how the fix is scoped.

Environment

• Claude Desktop 1.46388.3.0, x64, MSIX/Store install (Claude_1.46388.3.0_x64__pzs8sxrjxfjjc)
• Windows 11 Pro 10.0.26200
• Bundled Claude Code 2.1.260

Correlation

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

2026-09-05 07:34:15 [info] [stealth-update]   Triggering stealth update after idle timeout
2026-09-05 07:34:15 [info] [stealth-relaunch] Saved z-order anchor: 0xaa0c8c (above our 0x2812e6)
2026-09-05 07:34:18 [info] [stealth-relaunch] Loaded z-order anchor: 0xaa0c8c
2026-09-05 07:34:19 [info] [stealth-relaunch] Restored z-order: our 0x340874 behind anchor 0xaa0c8c

I independently noticed the window was pinned about 25 minutes later and only then went to the logs, so the handle correlation was not something I went looking for. Enumerating both handles at that point:

| hwnd | process | class | ExStyle | topmost |
|---|---|---|---|---|
| 0xAA0C8C (the anchor) | SumatraPDF.exe | tooltips_class32 | 0x00080088 = WS_EX_TOPMOST \| WS_EX_TOOLWINDOW \| WS_EX_LAYERED | yes |
| 0x340874 (Claude main window) | claude.exe | Chrome_WidgetWin_1, title "Claude" | 0x00280108 (contains WS_EX_TOPMOST) | yes |

0x340874 in the log line is exactly the window that was pinned.

Ruled out on this machine

• Not PowerToys. PowerToys 0.98.1 is installed here with the Always On Top module enabled and its settings file absent (so the default Win+Ctrl+T hotkey is live) — so rather than just asserting it, I ran it as a positive control. When PowerToys pins a window, PowerToys.AlwaysOnTop.exe creates a visible AlwaysOnTop_Border window; pressing Win+Ctrl+T reproduced that on demand and pressing it again removed it. In the bug state that border window did not exist, and a screenshot of the window edge showed no border. It is also the only always-on-top-capable utility running on this machine.
• Not the computer-use side panel. [cu-side-panel] appears 20 times in the live log, always initialized, never docked — matching @nvi-nsi's observation. I had initially suspected this path: app.asar does contain a dock/undock pair for the main window that pins on dock and restores the previous state on undock, and its undock clears the saved state before awaiting the un-dock animation, so a generation-counter guard can skip the restore entirely and strand the pin. That race looks real on inspection, but the logs falsify it as the cause here, and I mention it only so it can be discounted or fixed separately rather than re-derived by the next person.
• Not persisted. window-state.json holds only bounds/maximized/fullscreen; config.json has no alwaysOnTop key. Restarting the app clears it.
• Not re-applied. After clearing the flag with SetWindowPos(hwnd, HWND_NOTOPMOST, ...) I polled GWL_EXSTYLE for 90 s of normal use: zero transitions back. Consistent with one-shot inheritance at relaunch rather than a repeating code path.

Why this data point matters for the fix

@nvi-nsi's suggested fix would cover this case — 0x00080088 has both WS_EX_TOPMOST and WS_EX_TOOLWINDOW, so either the topmost check or a tool-window exclusion catches it.

But with the anchors now reported being the taskbar (Shell_TrayWnd), TextInputHost.exe, and now a third-party app's tooltip control, the anchor set clearly isn't limited to shell or system windows. Any application that happens to own a topmost tooltip, overlay or HUD sitting above the Claude window at the moment the idle stealth update fires can become the anchor. That argues for the general form of the fix rather than a class/process denylist:

1. When restoring, never insert after an anchor that has WS_EX_TOPMOST — use HWND_NOTOPMOST, or walk down to the first non-topmost window.
2. Explicitly re-assert the app's own pre-update topmost state after the restore, instead of letting it be implied by the anchor.

(2) alone would make this robust regardless of what the anchor turns out to be.

Confirming on the latest Windows build 1.46388.4 (MSIX Claude_1.46388.4.0_x64__pzs8sxrjxfjjc), Windows 11 Pro 10.0.26200, and adding another handle-level match for the stealth-relaunch z-order-anchor mechanism described in https://github.com/anthropics/claude-code/issues/85891#issuecomment-5518654248.

Measured: main window 0x80534 carried WS_EX_TOPMOST (ExStyle 0x00280108). Clearing with SetWindowPos(hwnd, HWND_NOTOPMOST, 0,0,0,0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE) gave 0x00280100 and normal z-order immediately. It was the only visible top-level window on the process.

Log correlation (%LOCALAPPDATA%\Claude\Logs\main.log): that exact handle is the one the stealth relaunch re-inserted behind the anchor, and the anchor is the taskbar:

2026-09-05 12:38:45 [stealth-relaunch] Saved z-order anchor: 0x10146 (above our 0xe068a)
2026-09-05 12:38:50 [stealth-relaunch] Restored z-order: our 0x80534 behind anchor 0x10146

FindWindow("Shell_TrayWnd", NULL) = 0x10146 on this machine (explorer.exe, itself topmost). The same anchor 0x10146 appears in the two previous relaunches on 2026-09-04 18:17 and 2026-09-05 05:27 as well, so every recent silent update on this machine has re-inserted the main window into the topmost band.

Relaunch cadence here is roughly daily (2026-08-26, 08-27, 08-31, 09-02, 09-03 x2, 09-04 x2, 09-05 x2), which is why the symptom reads as "random / intermittent" to users.

Ask: after a stealth relaunch, never use a topmost-band window (e.g. Shell_TrayWnd) as the z-order anchor, or explicitly clear WS_EX_TOPMOST after the restore step.

Reproducible trigger on Windows 10: right-click the Claude Desktop taskbar entry → "Show this window on all desktops". The window immediately acquires WS_EX_TOPMOST and keeps it — it renders above every other application even when another window takes focus. Minimizing, closing and reopening the app do not clear it; only an external SetWindowPos(hwnd, HWND_NOTOPMOST, ...) does, and the flag returns as soon as the pin is reapplied.

Worth noting File Explorer pinned the same way does not become topmost, so this isn't Windows promoting pinned windows — the app appears to be setting the topmost flag itself in response to the virtual-desktop pin, and never clearing it. App version and OS build: [fill in from Settings → About and winver].

fix this bug pleaseeeeeeeee

Adding a real-world impact report on this, because I don't think the severity is obvious from the title.

I run a martial arts gym and I use the Claude desktop app all day as an operations tool — it's genuinely central to how the business runs now. The always-on-top behaviour makes normal work almost impossible, because I can't put anything alongside it.

The specific things it breaks for me:

Snipping Tool — I can't drag it over Claude, so grabbing a screenshot of something to show Claude means minimising Claude first, which defeats the point.
Side-by-side work — I've got our management portal open in a browser and Claude next to it, checking one against the other all day. Claude covers the browser even when the browser has focus.
Any small utility window — calculator, file explorer, a PDF — disappears behind Claude the moment I click it.

The virtual desktop workaround (Win+Ctrl+D) does work, but it's not really a fix for something you're switching between every couple of minutes — it turns a glance into a context switch.

What I'm asking for is simply a toggle. It doesn't need to change the default. A checkbox in settings for "keep window on top" that I can turn off would completely solve it.

Worth noting this looks like it fell through the cracks rather than being deliberately declined — #87895 was closed as a duplicate of something closed as "not planned". I'd ask for it to be looked at fresh.

Windows 11. Claude desktop app, latest version as of 8 September 2026.

For what it's worth, Claude suggested that I submit this bit of observation when I asked why this was happening intermittently. This seems possibly related to my Claude client window being moved by Windows from one virtual desktop to another.

What I have observed is on my machine LENOVO_MT_21DH_BU_idea_FM_ThinkBook 14 G4 IAP, Windows 11 Enterprise 10.0.26200 Build 26200, Claude client for Windows version 1.46388.4 09/04/2026 9:57 pm - Ther are times when my Claude desktop client is moved by Windows from one virtual desktop to another. This seems possibly caused by a flaky older USB-C dock. Whatever the cause, the Claude app window is moved from my Desktop #1 to Desktop #2, which is where I typically have the largest number of windows open and displayed. This is shown in Win+Tab. When I drag the Claude app back to my primary desktop in Win+Tab, then I get the issue of Claude app suddenly being on-top always.

Any chance y'all could spend a little less time solving esoteric fluid dynamics problems and a little more time fixing basic UI issues? This bug should take 10 minutes to fix - just point Claude at it and you are good. This is extremely annoying.

Same problem

Adding an accessibility case to this one, because neither of the two earlier tickets had one and that may be why they closed so easily.

I have ADHD and dysgraphia. The forced always-on-top window causes distinct problems for each.

ADHD. A window I cannot see is a window I forget exists. Keeping two things in view at once is not a convenience, it is how I hold both in working memory. The virtual-desktop workaround in this thread does not solve that, it is the failure mode: it makes Claude invisible and charges me a context switch to get it back. Same for minimizing.

Dysgraphia. I dictate nearly all of my input with Dragon, which makes every task a two-window task. I need the source visible while I talk, because re-reading is cheap for me and re-dictating is expensive. Transcription errors then have to be checked against that source visually, which again needs both windows at once. Dragon's own floating bar and correction window also compete for the top layer with an app that will not yield it.

And the workaround compounds it. Win+Ctrl+Left/Right, Alt+Tab hunting, dragging windows in Task View: these are all motor-channel tasks, which is exactly the channel dysgraphia taxes. The proposed fix runs through the impairment.

The ask is small. One toggle in Settings. Default it to on if always-on-top is the intended behavior for most users. Just make it possible to turn off. Right now the app cannot be one window among several, and for anyone who works this way that rules it out of an ordinary desktop workflow.

Still reproduces. Windows 11 Enterprise 26200.

Still reproduces on Claude desktop 1.52386.6 (Windows 11 Home 10.0.26200, two monitors). Same stealth-relaunch z-order anchor cause described above; here the anchor was the second monitor's taskbar.

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

2026-09-13 21:16:23 [info] [stealth-relaunch] Saved z-order anchor: 0xa0bb4 (above our 0x20560)
2026-09-13 21:16:23 [info] [stealth-update] Triggering stealth update after idle timeout
2026-09-13 21:16:26 [info] [stealth-relaunch] Loaded z-order anchor: 0xa0bb4
2026-09-13 21:16:26 [info] [stealth-relaunch] Restored z-order: our 0x4043e behind anchor 0xa0bb4

• 0xa0bb4 is explorer.exe, class Shell_SecondaryTrayWnd, visible, WS_EX_TOPMOST.
• 0x4043e is the Claude main window. Later that evening it had WS_EX_TOPMOST, with no computer-use run in between (the first [cu-side-panel] docked line after the relaunch comes later).
• SetWindowPos(hwnd, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE) clears it, and it stayed cleared.

Another data point confirming the stealth-relaunch z-order anchor cause described above, on Windows 11 ARM64.

Environment

• Claude desktop 1.52386.6 (MSIX Claude_1.52386.6.0_arm64__pzs8sxrjxfjjc)
• Windows 11 Home 10.0.28000, ARM64 (Surface), two displays
• Razer Synapse running (RazerAppEngine)
• PowerToys Always On Top module disabled (ruled out)

Evidence

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

2026-09-14 17:39:26 [info] [stealth-relaunch] Saved z-order anchor: 0x20630 (above our 0x301f4)
2026-09-14 17:39:32 [info] [stealth-relaunch] Loaded z-order anchor: 0x20630
2026-09-14 17:39:32 [info] [stealth-relaunch] Restored z-order: our 0x20976 behind anchor 0x20630

Enumerating top-level windows a few hours later:

• 0x20976 = the Claude main window (Chrome_WidgetWin_1, title "Claude"), ExStyle 0x00280108 → WS_EX_TOPMOST set.
• 0x20630 = RazerAppEngine.exe, class/title RzMonitorForegroundWindow, WS_EX_TOPMOST.

So the anchor chosen at save time was a third-party topmost helper window. SetWindowPos(ours, hwndInsertAfter = <topmost window>) implicitly makes ours topmost too (documented behaviour of hWndInsertAfter), and nothing later clears it. On the earlier relaunches in my log (09-11, 09-12) the anchor was 0x10580 and no pin resulted, so it only bites when whatever happens to sit directly above the app is topmost — here Razer's monitor window, in the comment above a secondary taskbar.

Suggested fix: when restoring z-order after the stealth relaunch, skip any anchor whose ExStyle has WS_EX_TOPMOST (or call SetWindowPos(hwnd, HWND_NOTOPMOST, …) right after the restore). Two related things in the bundle make the pin sticky once it exists: the computer-use screenshot wrapper snapshots isAlwaysOnTop() on every BrowserWindow before a capture and re-applies setAlwaysOnTop(true, "screen-saver") afterwards, so it faithfully preserves the accidental pin; and there is no user-facing toggle to clear it.

Workaround that works immediately, no restart: SetWindowPos(hwnd, HWND_NOTOPMOST, 0,0,0,0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE) on the main window (e.g. from PowerShell via P/Invoke).

Same issue has been happening for a few weeks, going on several weeks.
Also, when the button that asks for permissions comes up, it's very hard to select it. I have to line up the cursor before it's on top of the Claude window and wait to see a glitchy selection, and it takes a few tries before it will work.

I wonder if I call on Mamdani, if he can fix this too?

OS: Windows 11 Pro, version 25H2, OS build 26200.9445
Claude Desktop app version: 1.52386.6
Processor: 13th Gen Intel Core i7-1365U (1.80 GHz)
RAM: 32.0 GB
Duration: several weeks
No PowerToys, DeskPins, AutoHotkey, or similar pinning utility installed
No in-app setting found to disable always-on-top behavior

Confirming this on Windows 11, Version 10.0.26200 Build 26200
Claude desktop app 1.52386.6 (612f3f) 2026-09-13T00:45:40.000Z

The main chat window carries WS_EX_TOPMOST. Another window takes keyboard focus but still renders behind Claude. No PowerToys, DeskPins, AutoHotkey, or other pinning utility on this machine, so the flag is coming from the app.

The workarounds all clear the flag on the current window only. PowerToys Win+Ctrl+T, a SetWindowPos call with HWND_NOTOPMOST, and AutoHotkey's WinSet all work once, then the next silent auto-update relaunch reinstates it. Virtual desktops work because topmost is per-desktop, but that is not a practical answer for frequent switching between Claude and a browser or editor.

On triage history: #87895 was closed as a duplicate of #66516, and #66516 was itself closed as not planned, so the Windows reports have been absorbed into a dead thread rather than assessed. This looks like it fell through rather than being declined on the merits.

The ask is small. A "Keep window on top" checkbox in Settings, defaulting to off, would resolve it without changing behavior for anyone who wants the current arrangement.

Confirmed this has happened on a Win 11 Ent machine with desktop v 1.49585.0.

Can't post any logs as this is a company laptop and I work in InfoSec. I know that people have tried to restart claude from within windows.

Without giving my system uptime, I used the long-standing running joke; when in doubt, reboot. When in real doubt, shutdown, unplug, wait then start up cold.

The warm reboot worked for me.

IMPO, FWIW, sure it is an annoyance and we all want to be the ones to solve it. Try the reboot methods and go about your day. In the grand scheme of things, it is not exactly the sky is falling down.

(disclaimer: these are my opinions and mine alone, and not the ones of my current or future employers)

Same issue, quite annoying. Windows details:
Edition Windows 11 Home
Version 25H2
Installed on ‎23/‎10/‎2024
OS build 26200.9445

When I fully quit Claude (checking Task Manager for any lingering claude.exe processes) and reopen it clears the flag until the next silent update triggers it again.

+1, seeing this on Windows too. Started right after a system restart (Windows Update triggered reboot) — the main window got stuck pinned in the foreground: after maximizing it, clicking on other windows (including Chrome) wouldn't bring them to focus. Not sure if related to the session/auth issues also being reported around the same restart, but noting the timing correlation in case it helps triage.

Okay yeah this just happened to me now and is driving me mental.

Have not updated in a week or two, and was not happening before today.

Claude 2.110.1 (ae8d2a) 2026-09-17T03:04:01.000Z

Edit: relaunching the app has fixed it for now, but nothing else did

This issue is really annoying. I'm getting to the point where I skip using the desktop app for now, as it blocks productive work because it hides other windows. I'm working on Win11 with Claude 2.110.1 (ae8d2a) 2026-09-17T03:04:01.000Z

The workaround above sometimes works until the next restart

I'm seeing this same issue on Windows 11 — Claude desktop app (version 2.110.1.0) window has been stuck "always on top" for about 2 days now.

One detail that doesn't match the trigger described in this thread: my taskbar icon's right-click context menu doesn't have a "Show this window on all desktops" option at all. My menu only shows: New Code Session (with recent project shortcuts), Opravila/Tasks (New Chat, New Code Session, Continue <recent session>), Claude, Unpin from taskbar, Close window.

So whatever is setting the always-on-top flag in my case, it isn't that specific menu action — might be worth looking for another trigger path.

Workaround that does help: switching to a new Windows virtual desktop (Win+Ctrl+D) avoids the always-on-top behavior there, since it appears to be scoped per-desktop.

Happening to me right now. Version 2.2553.1 (c38127)
Sep 17, 2026, 7:41 PM. No updates available. Very annoying. Relaunching the app SOMETIMES fixes it

Reproduces here too.

Windows 11 Pro 25H2 (build 26200.9168), Claude desktop 2.2553.1.
Main window keeps WS_EX_TOPMOST, other apps take focus but stay behind it.
Closing and reopening the Cowork window does not clear it.

Another data point, plus a reframe I think is worth considering.

Repro: Claude Desktop 2.2553.1, Electron 44.2.0, Windows 11 x64. Window
inherits WS_EX_TOPMOST after an idle auto-update and keeps it across app
restarts. SetWindowPos(hwnd, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE |
SWP_NOSIZE | SWP_NOACTIVATE) clears it instantly, which confirms the flag is
being left set rather than continuously re-applied.

The reframe: I don't think this should be tracked purely as a z-order bug.
That framing is arguably why it keeps falling out of triage — it's been
reproducing since 1.34493.1, and the parent issues (#87895, #66516) were
closed as "not planned." An intermittent Windows z-order defect is never going
to win a bug queue.

Suggest owning the flag deliberately instead: expose always-on-top as a user
setting backed by win.setAlwaysOnTop(), and have the stealth-relaunch
z-order restore read from that setting rather than inheriting whatever anchor
window happened to be topmost at update time. That's a one-line Electron API
plus a menu item, and it buys two things for the same change:

1. The bug class disappears. One source of truth for the flag instead of

an inherited accident — no anchor-walking logic, no special-casing
Shell_TrayWnd / TextInputHost.exe / tooltip windows.

1. It's a feature people want. Pinning a chat assistant above an editor or

terminal is a legitimate workflow. There are third-party utilities on macOS
that exist purely to bolt this onto Claude.

As it stands the state exists, is unreachable, and is unintentional — which is
the worst of the three options.

I just encountered this. It's a great way for Anthropic to generate bad will. This is an early 1990s-level neophyte programmer mistake. Fix it. Yesterday.

Stuck on top and I don't like it. :) It started this week. I did not request computer use, but it could have happened.
OS: Microsoft Windows 11 Enterprise 10.0.26200
Claude app: Claude Code: 2.1.258 (Claude Code)
Monitors: 3

Same issue here.

• OS: Windows 11
• Claude Desktop: 2.19675.0

The Claude window stays on top of all other windows. Clicking another app does not send it to the background; the only option is to minimize it. During a Cowork session with computer use, the Claude window also came to the front by itself while Claude was working in Settings and Task Manager.

Still reproducing on Windows as of October 10, 2026.

Real-world impact: I use Claude Desktop all day as a work tool next to a browser, an editor and spreadsheets. With the main window stuck topmost, every other app renders behind it — even after Alt+Tab or clicking it. Closing the window and reopening from the tray icon does not help, because it just hands off to the running instance. The only fix is fully quitting from the tray, and the next silent update pins it again.

Where this bug stands:

• Open since Aug 25. The root cause was identified in this thread weeks ago (stealth-relaunch z-order restore inheriting WS_EX_TOPMOST from whatever topmost window was the anchor), with a concrete, small fix proposed.
• Reproduced on many machines and versions, from 1.34xxx through 2.x — 287 👍 on #85891 and 70+ here.
• The workaround users are passing around is a PowerShell P/Invoke to SetWindowPos(HWND_NOTOPMOST). Nobody should need Win32 calls to use a desktop chat app.

Requests:

1. Fix the restore: never insert after an anchor that has WS_EX_TOPMOST, or call SetWindowPos(HWND_NOTOPMOST) right after the restore.
2. Add a "Keep window on top" toggle in Settings, default off.
3. Consolidate the duplicates (#85891 and others labeled invalid) into this issue so the evidence lives in one place.

A maintainer acknowledgement with an ETA would go a long way.

Workaround confirmed: toggling PowerToys Always On Top clears the stuck flag

Same issue here. Claude Desktop stayed above all other windows even when another app had focus.

OS: Windows 11 26H2
Claude Desktop: 2.37337.1

What fixed it:

PowerToys was installed but not running, so it wasn’t causing the problem. Pressing Win+Ctrl+T did nothing.
I launched PowerToys, clicked on the Claude window, and pressed Win+Ctrl+T. It played the “pinned” sound. No visible change, since the window was already on top.
I pressed Win+Ctrl+T again to unpin it.
After that, Claude Desktop behaved normally and could sit behind other windows.

This lines up with the earlier finding that the window has the topmost flag set (WS_EX_TOPMOST) without any saved setting causing it. Pinning and then unpinning through PowerToys clears that flag on the running window. The flag may come back when the app restarts, but repeating the toggle should fix it again.