[BUG] Claude Desktop (Windows 11): main window stays always-on-top of other applications, with no setting to disable it

I'm having this same issue. Why is it being marked as invalid?

Same problem on my end

I'm having this same issue. Why is it being marked as invalid?

I think theres some confusion whether or not this repro is for only claude code or if it also includes claude desktop. I reported this issue to support too.

Having the same issue today. Completely exiting Claude desktop didn't help and it was fine yesterday. I left the window open all night and this morning it's behaving this way.

Logging out & ending task on everything claude.exe seems to have resolved it, FYI.

Another independent reproduction, this time via Cowork's computer-use feature specifically.

Environment

• OS: Windows 10 Pro, build 19045 (22H2)
• Two displays attached

What I observed
While Claude was actively driving another application via computer-use (a legitimate GUI automation task, not the "Claude is using your computer" overlay itself), the main Claude chat window stayed rendered above the target application on every screenshot, even when that application was deliberately brought to focus and positioned on top. The only reliable fix was minimizing the Claude window before each screenshot.

This matches the repro and "Ruled out" section above exactly - no PowerToys, DeskPins, AutoHotkey, or other pinning utility installed, so the topmost behavior is coming from the app itself, not a third-party tool.

Worth reiterating: this isn't just a cosmetic annoyance. During active computer-use sessions it actively interferes with the task, since a target window can be correctly positioned by the user but still visually obscured by the always-on-top Claude window, making it hard to tell what's actually on screen versus what's simply covered. +1 on the suggested fix (explicit opt-in "Keep window on top" toggle, default off).

Same happened to me on Desktop App on Windows 11. Open Task Manager and 'End Task' on all open instances of Claude (I had 12 running even though it was closed). I think this might have something to do with remote-control.

I am having the exact same issue.

Same issue for me.

Confirm, I have same issue. Windows 11 and Claude 1.32885.1 (a757f5)

Logging out & ending task on everything claude.exe seems to have resolved it, FYI.

Worked for me, too.

Issue started past couple of days, and there was at least one update. Closing/killing all Claude related app (just the desktop app for me) fixed it.

Had same issue on Windows 11 Claude version 1.34493.1. Ending task seems to have fixed it for now

Confirming this on Windows 11 Pro, latest Claude Desktop, no update available.
Multi-monitor setup (3 displays). When the Claude window is filled on one
monitor and I switch to ANY app behind it (Word, Excel, etc.), that app does
not come to the front. Clicking the background window and Alt+Tab both fail
to raise it. Only minimizing Claude reveals what's behind it.

Not app-specific — happens with every application. PowerToys does not override
it, matching the original report. There is no in-app setting to disable it.

A simple on/off toggle for always-on-top would fix this.

One additional update - had this happen for a second time. Both times it has been when I was away from my computer for ~24h, so there's probably something related to the computer going to a low power state/sleep. Then when you come back, it's triggered as always on top.

I'm on 1.34493.1 on Win11.

Windows 11, same issue here. Claude Desktop persists over all other windows/programs whether maximized (cant switch to a different program), shunken but not minimized (it overlaps every program). Only fix is to minimize it or pin Claude to a side and another program to the other side.

Same issue. For me, this occurs when having an open/active project on Claude Desktop and then utilizing the Claude Mobile app for follow-ups. Force closing the desktop app returns the app to normal.

+1

Same issue here, "always on top"

same. following.

Confirming this is still happening. Windows 11, Claude Desktop reports "running the latest version" (checked via Help → Check for Updates), and the always-on-top behavior is still present. A restart of the app did fix the issue for me, but I'm not convinced it won't return.

Still present on Windows 11 in desktop app 1.34493.1 (binary 2.1.237).

WS_EX_TOPMOST is set on the main window; no other application on the same machine has the bit set. It survives a full quit and restart, and there is no entry for it under Datei / Bearbeiten / Ansicht / Hilfe. Nothing is persisted in config.json or window-state.json, so it looks like a runtime setAlwaysOnTop(true) rather than a restored preference.

Workaround, has to be repeated after every start: SetWindowPos(hWnd, HWND_NOTOPMOST, ...) via PowerShell.

in Windows, I shut down Claude, CTRL-ALT-DEL to task manager, searched for claude, and end task on claude background. it worked.

+2 , have to restart the whole app every now and then, kinda frustrating

Third confirmed instance of the #87084 mechanism — plus a version correction

Adding an independent reproduction with handle-level log correlation, and a correction to the version attribution in #87084 (which was auto-closed as "not about Claude Code", but contains the correct root-cause analysis).

Environment: Windows 11 Enterprise 26200, Claude Desktop 1.37937.0 (MSIX), single display.

The incident

From %LOCALAPPDATA%\Claude\Logs\main.log — note this is the live log; the %APPDATA%\Claude\logs\ copy is stale and misled me at first:

16:39:38  [stealth-relaunch] Saved z-order anchor: 0x501d6 (above our 0xee0cf4)
16:39:43  [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, ...)
16:39:44  [stealth-relaunch] Restored z-order: our 0x200724 behind anchor 0x501d6

Measured afterwards: hwnd 0x200724, GetWindowLong(GWL_EXSTYLE) = 0x00280108 → WS_EX_TOPMOST set. Same handle as the log line. Cleared with SetWindowPos(HWND_NOTOPMOST) → 0x00280100, and it stayed cleared. No PowerToys or other pinning utility installed.

The anchor is not necessarily the taskbar

#87084 identified Shell_TrayWnd. Here the anchor 0x501d6 is still alive and resolves to:

hwnd=0x0501D6  class=I  pid=14884  proc=ClickToDo  ex=0x00280088  TOPMOST=True

Windows Click to Do — a different topmost-band window. So the defect isn't taskbar-specific: any topmost-band window that happens to sit directly above Claude at capture time will do it. Fixes that special-case the taskbar won't be sufficient.

Trigger condition, which likely explains the intermittency in this thread

The restore only runs when the window is visible. My three most recent relaunches:

| Relaunch | windowVisible | Outcome |
|---|---|---|
| 2026-08-20 20:17 | false (minimized) | Window was minimized, restoring minimized — no z-order restore, no bug |
| 2026-08-21 00:28 | false (minimized) | same — no bug |
| 2026-08-25 16:39 | true | Restored z-order — topmost acquired |

That matches jalexand42's report above of it appearing overnight and being fine the day before: it depends on whether the window happened to be visible when the silent update landed.

Version correction

#87084 states the defect was "introduced in the 1.30096.x line." My logs put the z-order anchor code one release earlier, in 1.28929.0:

| Date | Version running at relaunch | z-order step logged? |
|---|---|---|
| 2026-08-07 10:15 | 1.26832.0 | No — navigation history only |
| 2026-08-13 19:49 | 1.28929.0 | Yes — Saved z-order anchor: 0x2056a |

This machine updated 1.26832.0 → 1.28929.0 with no intermediate version, so the anchor/restore step landed in 1.28929.0. [stealth-relaunch] itself is older — first seen here 2026-07-17 — so the anchor step was added to a pre-existing feature rather than shipping with it.

Scope caveat, which I think matters for triage of this thread

This mechanism cannot explain every report here. This issue's original report is on 1.26832.0, which predates the anchor code, and DreikalCC above attributes theirs to computer-use specifically. #87084 §E describes a second path — the screenshot wrapper re-asserting a sampled alwaysOnTop at the fixed screen-saver level, which can make a transient side-panel dock state permanent. There appear to be at least two independent routes to the same end state, and fixing only the stealth-relaunch anchor will leave the other one live.

Workaround

Clears until the next qualifying relaunch; restarting the app also clears it, since nothing persists the flag:

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 MainWindowTitle).MainWindowHandle
[N.W]::SetWindowPos($h, [IntPtr]-2, 0,0,0,0, 0x0013)

+1. The workaround from v-tab-vispero did the trick, I am saving that as claude-fix.ps1 until the actual fix comes around

If you close the application correctly the flag persists and application remains always-on-top on next load. If you kill the process via task manager the flag clears.

this is actually pissing me off

This just started happening to me tonight and it's really irritating.

Another data point — same [stealth-relaunch] anchor mechanism, still live on 1.37937.3, single display

Adding a fresh reproduction because this one sits on a newer version pair than anything reported in this thread so far, and the flag was acquired by the update that landed on this machine today. Until that update I had never seen the window get stuck on top.

Environment: Windows 11 Pro, build 26200, x64, MSIX / Store install, single display. No PowerToys, DeskPins, AutoHotkey or any comparable pinning utility installed or running (checked the uninstall registry, Get-AppxPackage, Program Files, and the running process list). Claude Desktop 1.37937.3, bundled Claude Code 2.1.246.

Handle-level correlation

From %LOCALAPPDATA%\Claude\logs\main.log (trimmed to the relevant lines):

20:34:41 [stealth-update]   Triggering stealth update after idle timeout
20:34:41 [stealth-relaunch] Saved z-order anchor: 0x1014c (above our 0x105b0)
20:34:41 beforeQuitForUpdate handler fired, going down for update
20:34:44 [updater] Version changed since last launch: 1.37937.1 -> 1.37937.3
20:34:44 [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, otherAppFullScreen=false)
20:34:44 [stealth-relaunch] Loaded z-order anchor: 0x1014c
20:34:44 [stealth-relaunch] Restored z-order: our 0x505e8 behind anchor 0x1014c

Measured ~3 h later at 23:59, window untouched in between:

hwnd=0x505E8  class=Chrome_WidgetWin_1  title='Claude'  proc=claude.exe
GWL_EXSTYLE=0x00280108  ->  WS_EX_TOPMOST set

Same handle as the log line. The saved anchor is still alive and resolves to:

hwnd=0x1014C  class=Shell_TrayWnd  proc=explorer.exe  ex=0x00000088  TOPMOST=True

— the taskbar, i.e. the anchor identity from #87084 rather than the Click to Do window @danim-hub measured. Both have now been observed in the wild on different machines, which supports their conclusion that the anchor is simply whatever topmost-band window happens to sit directly above Claude at capture time, and that a taskbar-specific fix would not be sufficient.

Single display

The original report raises multi-monitor as possibly relevant. This machine has exactly one display attached, so a second monitor is not required to reproduce.

The version attribution does not line up — this may not be a clean version cut

#87084 places the anchor code in the 1.30096.x line; @danim-hub's logs place it in 1.28929.0. My log covers 2026-08-21 to now and contains exactly one Saved z-order anchor line, on 1.37937.1. The previous update-quit, five days earlier, went 1.34493.1 -> 1.37937.1 and visibly took a different code path:

| Date | Outgoing version | Marker detected on the incoming side | z-order step logged | Topmost afterwards |
|---|---|---|---|---|
| 2026-08-25 23:10 | 1.34493.1 | [update-restart] Detected nav-restore marker, launching normally | none | no |
| 2026-08-26 20:34 | 1.37937.1 | [stealth-relaunch] Detected via marker file (windowVisible=true, ...) | saved + restored | yes |

Both quits were otherwise the same shape (beforeQuitForUpdate -> Windows session ending (close-app)), and the incoming 1.37937.1 did restore 30 navigation entries, so the old build clearly wrote a marker — just one without an anchor in it.

On this machine, then, the anchor step is absent from 1.34493.1 and present in 1.37937.1, which is later than either earlier attribution. Since 1.34493.1 is well past both 1.28929.0 and 1.30096.x, "introduced in version X" may be the wrong model — the step looks gated (feature flag or install channel; this box is MSIX and the app boots a growthbook client at startup) rather than being a straight version cut. That seems worth confirming before this is closed as "fixed in \<version\>", since a gated rollout can re-enable the path on machines that already look patched.

Why it seems to appear out of nowhere

Several reports here describe it turning up overnight or "just started tonight". On an MSIX install the log shows [CCD-autoupdate] Disabled: MSIX install, and the relaunch is driven by [stealth-update] Triggering stealth update after idle timeout — no user action and no visible restart. Combined with @danim-hub's finding that the restore only runs when windowVisible=true, that accounts for the "it was fine yesterday" pattern: it lands on whichever idle-time update happens to catch the window on screen.

Open question on the workaround

I have deliberately not cleared the flag on this machine yet, so I cannot speak to whether it survives a clean quit — @jaymaart reports that it does and that killing the process is what clears it, while @zeldakos reports the same via Task Manager. If a clean before/after measurement of GWL_EXSTYLE across quit-vs-kill would help triage separate the two paths described in #87084, I still have the untouched state here and am happy to log it.

Same issue here

This is really annoying, please fix asap

Having the same issue, but only after I upgraded to 1.37937.3

Another confirmation of the [stealth-relaunch] anchor mechanism — single display, Click to Do anchor, acquired on 1.37937.1 → 1.37937.3

Environment: Windows 11 Home, build 26200, x64. Single display (1920×1080). Claude Desktop 1.37937.3. No PowerToys, DeskPins, AutoHotkey, DisplayFusion or comparable pinning utility — checked the uninstall registry (HKLM, HKLM\WOW6432Node, HKCU), Get-AppxPackage, and the running process list; nothing matched.

Handle-level correlation

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

2026-08-28 08:49:38 [stealth-update]   Triggering stealth update after idle timeout
2026-08-28 08:49:38 [stealth-relaunch] Saved z-order anchor: 0x101e0 (above our 0x1065a)
2026-08-28 08:50:45 [updater] Version changed since last launch: 1.37937.1 → 1.37937.3
2026-08-28 08:50:45 [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, otherAppFullScreen=false)
2026-08-28 08:50:45 [stealth-relaunch] Loaded z-order anchor: 0x101e0
2026-08-28 08:50:45 [stealth-relaunch] Restored z-order: our 0x30632 behind anchor 0x101e0

Measured ~4 h later, window untouched in between:

hwnd=0x30632  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) cleared it to 0x00280100 and it stayed cleared.

The saved anchor is still alive and resolves to:

hwnd=0x101E0  class=IslandWindow  pid=25716  proc=ClickToDo  ex=0x00280088  TOPMOST=True

Windows Click to Do — the same anchor identity reported above rather than Shell_TrayWnd. That's now two independent machines on Click to Do and two on the taskbar, which supports the conclusion that the anchor is simply whatever topmost-band window happens to sit directly above Claude at capture time. A fix that special-cases the taskbar would not cover this.

Single display

This machine has exactly one display attached, matching the other single-display reports above — a second monitor is not required to reproduce, despite the original report raising it as possibly relevant.

A caution on the version attribution

This thread currently places the anchor step in 1.28929.0 and in the 1.30096.x line. My log runs 2026-08-22 to now and contains exactly one Saved z-order anchor, on 1.37937.1, with none on the two earlier updates in the window.

I would caution against reading that as a version cut, including for my own machine. The 26 Aug update took a visibly different path:

2026-08-26 06:36:42 [updater] Version changed since last launch: 1.34493.1 → 1.37937.1
2026-08-26 06:36:42 [update-restart] Detected nav-restore marker, launching normally

No [stealth-update] Triggering line preceded it, so the idle-timeout path never ran and the anchor step had no opportunity to fire — regardless of which version the code was in. Absence of the log line means "the stealth path didn't run here", not "the code isn't in this build". Only the positive sightings constrain the version; inferences from absence (mine included) aren't reliable.

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)

Restarting the app clears it too — nothing persists the flag. And since the restore only runs when windowVisible=true, minimizing the window before stepping away avoids it entirely.

Finally: this is still labelled invalid with 30+ independent confirmations and handle-level log evidence from several machines. Could it be re-triaged?

I discovered this issue for myself this morning. Really annoying UX. Would you like me to spin up Claude Code and fix it for you 😂

Annoyed!😡 Please fix.

I'm worried that it's marked as invalid, as it may cause it to be ignored.

@mullman2 You don't have to wait for the fix to get unstuck — nothing persists the flag, so it's clearable right now. Three options, easiest first:

1. Fully quit and restart Claude Desktop. Check Task Manager afterwards and make sure no claude.exe survives — several people in this thread (and I) found a dozen or more background instances still running after "closing" the app. This clears it until the next qualifying update.

2. Clear it in place, without restarting. PowerShell, no admin needed:

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)

That is just SetWindowPos(hwnd, HWND_NOTOPMOST, SWP_NOSIZE|SWP_NOMOVE|SWP_NOACTIVATE) — it drops the window out of the topmost band, exactly like unticking an "always on top" box. It doesn't touch the app, your conversations, or any setting. It prints True if it worked. To confirm, read GetWindowLong(hwnd, GWL_EXSTYLE): 0x00280108 before, 0x00280100 after — bit 0x8 is WS_EX_TOPMOST.

3. Stop it recurring. The z-order restore only runs when the window is visible at update time — the log line reads windowVisible=true. If you minimize Claude Desktop before stepping away, the idle-timeout update takes the harmless path and the flag is never applied. That's been the pattern across the logs posted here, including mine.

Caveat on 2: it holds until the next update that re-triggers the restore, so you may need to re-run it. It's an unstick, not a fix.

On the label — agreed, that's the real risk, and it's why I asked about re-triage in my comment above. It might also be worth people filing through Anthropic support in parallel, since that routes to the desktop team directly and this tracker apparently doesn't for area:desktop.

. Clear it in place, without restarting. PowerShell, no admin needed:

That did the trick! I now have a work-around to the annoying condition. Thanks @Starfield3 for the help!!!

@mullman2 You don't have to wait for the fix to get unstuck — nothing persists the flag, so it's clearable right now. Three options, easiest first: 1. Fully quit and restart Claude Desktop. Check Task Manager afterwards and make sure no claude.exe survives — several people in this thread (and I) found a dozen or more background instances still running after "closing" the app. This clears it until the next qualifying update.

For me, just closing out those other instances fixed the issue. Thank you.

I ran into this today, just chiming in that I was able to fix the issue temporarily, ironically, by enabling PowerToys's Always on Top via the shortcut and then disabling it.

The issue resolved for me by going to the task manager and ending the task for all claude instances, when I reopened the Claude desktop again, it worked like normal.

To alleviate the issue and keep Claude desktop running, here's a PowerShell command that will leave Claude desktop running but force the ghost window to the bottom of the screen stack: force_claude_to_background.cmd

Confirming the same issue on Windows 11 Home, version 25H2 (OS Build 26200.9278).
Claude Desktop app version: 1.40609.0.0
Multi-monitor setup: yes, 2 monitors in use.
Symptom matches exactly: main chat window stays topmost even after switching focus to another app. Minimizing is the only workaround.

Use the gist above and you won't need to minimize it: issue comment 5458891280.

For me, just closing out those other instances fixed the issue. Thank you.

For me too. Open Task Manager, search for claude, terminate all active task.
Thanks.

M.

Confirming this is still happening, on Windows 11 Home.

The Claude desktop window stays drawn on top of every other application. Clicking another window does focus it underneath, but Claude keeps painting over the top, so the other window is unusable until Claude is manually minimised. It did not behave this way previously — the window used to drop behind other apps normally when they were clicked. There is no setting anywhere in the app to turn this off.

Environment

• OS: Microsoft Windows 11 Home
• Version: 10.0.26200 (build 26200)
• Architecture: 64-bit
• Claude desktop app (data directory: %APPDATA%\Claude)

Steps to reproduce

1. Open the Claude desktop app.
2. Open any other application — a browser, or Microsoft Word.
3. Click on that other application's window.

Expected: the other window comes to the front, as any normal window does.

Actual: the other window takes focus but stays visually behind Claude. Claude remains on top and covers it. The only way to see the other application is to minimise Claude by hand every single time.

Impact: this makes it difficult to work between Claude and anything else. Copying between a browser and Claude, or referring to a document while working, now requires minimising and restoring the window constantly. For anyone using Claude alongside other tools all day, it is a significant regression.

Request: please either restore the previous windowing behaviour, or add a setting to turn "always on top" off.

Bug: Claude Desktop main window stays always-on-top of other applications

Platform: Windows
App: Claude Desktop (latest version)

Description:
The main Claude Desktop chat window stays pinned above all other application windows, even after another app is focused. It does not behave like a normal window — there is no in-app setting to disable this "always on top" behavior.

Steps to reproduce:

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

Expected behavior:
Claude Desktop should behave like a standard window and drop behind other applications when they are focused.

Workaround found:
Minimizing the Claude Desktop window manually is the only workaround. Fully quitting and relaunching the app does not resolve the issue.

This appears to be a known, already-reported issue (similar reports exist for both Windows and macOS). Requesting either a fix to stop setting the always-on-top flag, or an explicit toggle in Settings to control this behavior.

I have same problem.

same issue here...

Confirming this reproduces for me as well.

OS: Windows 11
Claude Desktop version: 1.37937.3 (28dcf5)

The issue occurs with the main window restored (not maximized), and it stays on top of other apps even when those apps are focused/in the foreground.
The only workaround that works is manually minimizing Claude Desktop.
Restarting the app from the system tray icon does not fix it.

I'm having the same issue, Claude for Windows version Claude 1.37937.3 (28dcf5) 2026-08-26T19:52:45.000Z.

For the record I do not understand the difference between "Claude Desktop" and "Claude Code", especially when my app calls itself "Claude for Windows". I suspect the average customer cannot reliably delineate between these products.

The main window stays above all other applications even when another app is focused. It's not a third-party tool — the WS_EX_TOPMOST flag comes from Claude itself. The only workarounds are minimizing the window or moving it to another virtual desktop.

Please either remove the always-on-top flag from the main window, or add a "Keep window on top" toggle in Settings, defaulting to OFF.

Environment: Windows 11, Claude Desktop v[1.40609.0 (f65e38) 2026-08-27T16:19:51.000Z]

Same issue:

Workaround: Ending the task with Task Manager then reopening does reset it. Apparently it anchors itself to the task bar (per #87084])

Win 11 Home v 25H2, OS 26200.9168
Claude Desktop v 1.40609.0 (f65e38)
Using 3 screens (happens on any & all screens)

Still having same issue, please fix, this sucks.
Windows 11 Enterprise
V: 10.0.26200
B: 26200
Claude Desktop
V 1.40609.0

Use this gist
<https://gist.github.com/james-kassabian/794a088cdfadbe4d152b1a2e0a43b45b> to
keep Claude desktop and its child processes running without interruption to
alleviate the issue. Other suggested workarounds seem to involve
terminating all Claude processes and relaunching, which is unnecessary and
disruptive to the workflow.

On Tue, Sep 1, 2026 at 9:10 AM jackobearkittybreath <
@.***> wrote:

jackobearkittybreath left a comment (anthropics/claude-code#85891) <https://github.com/anthropics/claude-code/issues/85891#issuecomment-5495263872> Still having same issue, please fix, this sucks. Windows 11 Enterprise V: 10.0.26200 B: 26200 Claude Desktop V 1.40609.0 — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/85891?email_source=notifications&email_token=CKDZEGO6QQND4HRVKPXZTED5M3KHDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBZGUZDMMZYG4ZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5495263872>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CKDZEGPPD7EVZRLQ7WUPPUD5M3KHDAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TKMJSGMZTIOJTGYZ2C5QC> . You are receiving this because you commented.Message ID: @.***>

--
James Kassabian
AIAgency MN <http://aiagencymn.com>

Logging out & ending task on everything claude.exe seems to have resolved it, FYI.

This worked for me.

Can confirm the same behavior on Windows 11.

Environment:

• Claude Desktop version: 1.40609.1 (69aac0), build date 2026-08-31 01:12
• Windows build: 11, version 26H2, build 26340.9223

Symptom:
The Claude Desktop window stays visually on top of other application windows even after another window is focused via Alt-Tab or taskbar click. The taskbar/Alt-Tab preview correctly shows the other window as selected, but it only actually renders on screen once Claude is manually minimized. Right-click on the other app's taskbar icon (Shift+right-click) also shows no "Maximize" option and "Restore" has no effect while Claude is covering it.

Troubleshooting already done (ruling out system-level causes):

• Restarting dwm.exe: no effect
• Restarting explorer.exe: no effect
• Checked for third-party "always on top" / window management tools (PowerToys, DisplayFusion, etc.): none installed
• Confirmed it's isolated to Claude specifically: after a DWM restart, repeatedly switching between two other apps (Edge and Task Manager) works perfectly with correct z-ordering every time. The bug only reproduces the moment Claude Desktop is switched to/from.

Only workaround found: manually minimizing the Claude window.

Happy to provide logs or test a build if that helps narrow it down.

Confirming the same issue on Windows 11, Claude 1.40609.1 (69aac0) 2026-08-30T23:12:49.000Z

Only manual minimize hides the window.

I have same problem.

yeah I have the same problem.
because of this, I suspend the plan first..

How to solve the problem - log out of Claude and log in, then restart the PC

Just run this command from a CMD prompt. It places the Claude desktop ghost
window at the bottom of the screen stack without terminating Claude and its
subprocesses or rebooting the machine.

powershell -command "$win = Add-Type -MemberDefinition
'[DllImport(\"user32.dll\")] public static extern bool
SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int X, int Y, int
cx, int cy, uint uFlags);' -Name 'Win32' -Namespace 'Win' -PassThru;
foreach ($p in Get-Process Claude) { if ($p.MainWindowHandle -ne 0) {
$win::SetWindowPos($p.MainWindowHandle, [IntPtr]1, 0, 0, 0, 0, 0x0013)
} }"

On Wed, Sep 2, 2026 at 4:52 AM mcapcuch-stack @.***>
wrote:

mcapcuch-stack left a comment (anthropics/claude-code#85891) <https://github.com/anthropics/claude-code/issues/85891#issuecomment-5507708384> How to solve the problem - log out of Claude and log in, then restart the PC — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/85891?email_source=notifications&email_token=CKDZEGLKJSEFJK334U2FQU35M7UUXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJQG43TAOBTHA2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5507708384>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CKDZEGJEEBKXAIUG773KVID5M7UUXAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TKMJSGMZTIOJTGYZ2C5QC> . You are receiving this because you commented.Message ID: @.***>

--
James Kassabian
AIAgency MN <http://aiagencymn.com>

I fixed this just by using 'exit' option in the system tray and then starting again...

Having the same issue

Environment:

Claude 1.44121.2 (817a7b) 2026-09-02T17:47:36.000Z
Windows build: 11, version 24H2, build 26100.9106

Symptom:
The Claude Desktop window stays visually on top of other application windows.

Troubleshooting already done (ruling out system-level causes):

Restarting explorer.exe: no effect
Checked for third-party "always on top" / window management tools: PowerToys is installed, but not active

Happy to provide more details if needed

Confirming on Windows 11, and adding the trigger condition, which I don't think is written down in this thread yet: the flag is set by the silent auto-update relaunch, not by normal app usage.

This mechanism was already worked out in #87084, but that report was auto-closed ("this doesn't appear to be about Claude Code") and has 0 reactions, so it never made it here. I hit it three times and my logs match it exactly.

Environment

• Windows 11 Pro 10.0.26200
• Claude Desktop, MSIX package. Reproduced across three versions: 1.37937.3.0, 1.40609.0.0, 1.44121.2.0
• No third-party pinning tools (PowerToys not installed; verified no DeskPins/AutoHotkey/etc.)

Mechanism

On a stealth relaunch the app saves "the window directly above ours" as a z-order anchor, then re-inserts the new window behind that anchor. When Claude is the top window of the normal band — which it is whenever you were just using it — the window directly above is by definition the bottom of the topmost band, i.e. the taskbar. Per Win32 z-order rules, inserting among topmost windows makes the window topmost. Nothing clears it afterwards.

Evidence

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

2026-08-27 10:10:44 [stealth-relaunch] Saved z-order anchor: 0x1014c (above our 0x90254)
2026-08-27 10:10:49 [stealth-relaunch] Restored z-order: our 0xe09d6 behind anchor 0x1014c

2026-08-30 18:30:40 [stealth-relaunch] Saved z-order anchor: 0x10134 (above our 0x20596)
2026-08-30 18:30:43 [stealth-relaunch] Restored z-order: our 0x50616 behind anchor 0x10134

2026-09-03 07:30:31 [stealth-relaunch] Saved z-order anchor: 0x10144 (above our 0x406f2)
2026-09-03 07:30:35 [stealth-relaunch] Restored z-order: our 0xb0884 behind anchor 0x10144

The window handle the log reports as "ours" is, each time, exactly the handle I later measured carrying WS_EX_TOPMOST (GetWindowLong(GWL_EXSTYLE) = 0x00280108):

| Relaunch | HWND in log | HWND measured topmost |
|---|---|---|
| 2026-08-27 | 0xe09d6 | 0xE09D6 |
| 2026-08-30 | 0x50616 | 0x50616 |
| 2026-09-03 | 0xb0884 | 0xB0884 |

The anchor is the taskbar. For the most recent one I checked it live: FindWindow("Shell_TrayWnd", NULL) returns 0x10144 — the exact anchor handle from the log — owned by explorer.exe, itself WS_EX_TOPMOST. The two earlier anchors (0x1014c, 0x10134) are in the same handle range but I didn't capture them live at the time, so I can only confirm the taskbar identity for the third occurrence.

Two things this explains

Why it looks random. It isn't tied to anything you do in the app — it lands whenever an update relaunch happens to catch Claude as the frontmost normal window. My three occurrences are 3 and 4 days apart, matching the update cadence, not any usage pattern.

Why "a reboot fixed it" reports are consistent. A cold start doesn't run the z-order restore, so the flag simply isn't set that session. It comes back at the next silent update, which is why it reads as intermittent rather than fixed.

The flag also appears to be a one-shot insertion, not an enforcement loop: after clearing it externally I saw no re-assertion for the rest of that app run (each recurrence coincided with a new relaunch).

Workaround

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

ExStyle goes 0x00280108 → 0x00280100 and z-order behaves normally. Has to be re-applied after each update relaunch.

Ask

1. In the z-order restore, skip the anchor (or fall back to HWND_TOP within the normal band) when the anchor has WS_EX_TOPMOST. Alternatively clear WS_EX_TOPMOST right after the restore, unless the window is genuinely meant to be topmost.
2. Could the labels be reviewed? This is currently invalid rather than area:desktop / platform:windows.

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

Highly annoying, please fix

Repro here. Manually existing via the tray icon fixed it for me.

Pointer: #89467 looks like the tracked issue for this — worth adding evidence there

Following up on my comment above about the invalid label, since several people here have asked why this thread seems to be going nowhere.

Searching the tracker, this one defect currently has nine Windows reports: this issue, #88093, #89467, #90361, #88359, #91742 (filed today), plus #87895, #89851 and #87084 closed. Over 100 comments between them, and #66516 for the macOS equivalent.

The relevant difference: #89467 is labelled bug / has repro / platform:windows / area:desktop — no invalid. This thread, #88359, #90361 and #91742 all carry invalid. So the branch with the most evidence (this one, ~67 comments, including the handle-level log correlations several of us posted) is the branch that has been filtered out of triage, while the tracked issue has eight comments.

No maintainer has commented on either thread, so I can't say #89467 is actively being worked — only that it's classified in a way that makes it findable, and this one isn't.

Practical suggestion for anyone landing here:

• Add new reproductions and logs to #89467 rather than here.
• I've posted an update there confirming the defect is still live on 1.44121.4 (today's build), with a four-update table from one machine, and one finding that matters for the fix: the saved z-order anchor was Shell_TrayWnd today but Click to Do on the same machine six days ago, so the anchor is whatever topmost-band window happens to be above Claude at capture time — a taskbar-specific fix won't cover it.

For maintainers: could this thread and the other invalid-labelled ones be marked duplicates of #89467, so the evidence consolidates rather than being split across nine issues?

Nothing here changes the technical content of my earlier comment; it's just about where the discussion should live.

Confirmed, very annoying.

confirmed - EXTREMELY annoying

Confirmed too.

Me too.

Is this a setting or a required annoyance?

Please fix... Or leak the source code again and the community (us) can fix it using Claude code :-P

Windows 11 too. 1.44121.1.

Confirmed -- Windows 11/ARM architecture. Claude Version 1.44121.4 (0d57a2); Windows Version 25H2, Build 26200.9168.

affecting me too on Windows 11

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

Your instinct that this is WS_EX_TOPMOST being set by the app was right. I traced the mechanism on Windows and posted the details in #88093.

Short version: the flag isn't set by any always-on-top feature. The stealth auto-update relaunch saves the window sitting directly above ours (zOrderAnchorHwnd) so it can restore its z-order position without stealing focus, then on relaunch calls moveWindowBehind(ourHwnd, anchor) — a SetWindowPos in claude-native-binding.node. Win32 documents that if hWndInsertAfter is a topmost window, the positioned window becomes topmost. So whenever that saved anchor happens to be a topmost window — the taskbar, the immersive shell, a Click to Do overlay — the app silently promotes itself into the topmost band.

Across six stealth updates on my machine, every anchor that was topmost produced the pin, and the one that wasn't didn't. Full log evidence and a suggested fix are in #88093.

That also explains why there's nothing to switch off: the app never calls setAlwaysOnTop, so Electron's own alwaysOnTop stays false and no UI reflects it.

Worth noting this issue is currently labelled invalid as "not related to Claude Code" — which is accurate as far as it goes, since the bug is in the desktop app's stealth-relaunch path rather than in Claude Code itself. But that means it needs routing to the desktop app team rather than closing. #87895 looks like the same bug, and #66516 is the macOS analogue, also closed as invalid.

Workaround without restarting Claude: toggle PowerToys "Always on Top"
(Win+Ctrl+T) twice on the Claude window. The second toggle calls
SetWindowPos with HWND_NOTOPMOST and clears the stuck topmost flag, so
the window returns to normal z-order until the next display power cycle.

I discovered that it appears if the screen continues to perform a task for an extended period of time after the screen is locked.

Affecting me too on Windows 11 x64. PowerToys workaround helped, thanks @sasbau

Always on top for me

Confirmed

Workaround without restarting Claude: toggle PowerToys "Always on Top" (Win+Ctrl+T) twice on the Claude window. The second toggle calls SetWindowPos with HWND_NOTOPMOST and clears the stuck topmost flag, so the window returns to normal z-order until the next display power cycle.

Thanks for the workaround!

Where is the "Me Too!" button?

I discovered that you can just ask claude to fix it, and it does

Also hitting this on Windows 11 — main Claude Desktop chat window stays topmost and won't drop behind other focused windows. No always-on-top pinning tool installed on my end either. Minimizing is the only workaround I've found so far. Following for updates.

Claude was able to fix it without closing Claude Desktop (it can still happen again) and has a potential diagnose:

I searched app.asar for the code that sets this flag. Only one spot applies it to the main window: a focus workaround in the office-addin-bridge, in the focus_desktop handler.

process.platform === "win32"
  ? (MM.setAlwaysOnTop(true), MM.focus(), jM?.webContents.focus(),
     setTimeout(() => { MM && !MM.isDestroyed() && MM.setAlwaysOnTop(false) }, 100))
  : (MM.focus(), jM?.webContents.focus())

On Windows you can't always pull a window to the front, so the app pins it on top for a moment, focuses it, and unpins it 100ms later. If that second step never runs, the window stays pinned forever and there's no setting to undo it. My bridge is switched on (bridge-state.json contains "enabled": true). The other setAlwaysOnTop(true) calls in the app all pass a level argument and apply to the small quick-entry and overlay windows, not the main one. I can't prove this handler is what ran in my case, but it's the only place that could cause it.

Unpinning inside the window's own focus event, instead of on a timer, would remove the risk. Then a timer that never fires can't leave the window stuck.

Getting your window back without restarting
(You can ask Claude to perform this diagnose & fix if applicable)

You can clear the flag yourself with SetWindowPos, which is the Windows call that moves a window between the pinned and normal layers. Passing HWND_NOTOPMOST (the value -2) moves it back to normal, and the three flags tell Windows to leave the size, the position and the focus alone, so only the pinning changes.

Open PowerShell (no admin rights needed) and paste this in one go:

Add-Type @"
using System;
using System.Runtime.InteropServices;
public class Untop {
  [DllImport("user32.dll")]
  public static extern bool SetWindowPos(IntPtr hWnd, IntPtr after, int x, int y, int cx, int cy, uint flags);
}
"@

Get-Process claude | Where-Object { $_.MainWindowHandle -ne 0 } | ForEach-Object {
  $ok = [Untop]::SetWindowPos($_.MainWindowHandle, [IntPtr](-2), 0, 0, 0, 0, 0x0013)
  Write-Output "$($_.MainWindowTitle): $ok"
}

It finds the running Claude process, takes its main window, and unpins it. You should see Claude: True. The window drops behind other windows straight away and the app keeps running normally. 0x0013 is the three flags added together (SWP_NOSIZE, SWP_NOMOVE, SWP_NOACTIVATE). If the problem comes back later, run it again.

I had this issue and a reinstall (without uninstalling) fixed it. All my settings and chat history remained.

labels:invalid is why such an irritant issue is not getting a quick fix?

Worked around it with PowerToys where you can add claude.exe to the exclusion list for "Always on Top".

Still the same problem on my end!

I have the same problem, Windows 11, I DO NOT have a second display, so it is not related to that.
I did leave Claude running and did not sign back in for the 20th time for my safety like it asked.

Very irritating.

Meta: Regarding "invalid" because it's "not related to claude code", if you google Claude Code and click the first official download link, it literally downloads Claude Desktop. Claude Desktop _is_ the main version of "Claude Code" at this point, and the company should stop pretending otherwise and make this the official channel for reporting desktop app issues. And also start fixing said issues. There are many.

FYI: Exit the app from the System tray / notification will turn off this "feature".

Root cause: stealth update relaunch restores z-order behind a topmost window

I hit the same "Claude window is suddenly always on top" behaviour repeatedly and traced it in main.log. It is not caused by any user action or by a running session. It is the app's own background update.

Environment: Claude Desktop 1.52386.0 (Microsoft Store package), Windows 11 Pro 26200. Reproduced on 4 nights in the last week.

What happens

When the app is idle it triggers a "stealth update" and relaunches itself. Before quitting it remembers the window directly above it in the z-order as an anchor, and after relaunch it re-inserts its main window right behind that anchor:

2026-09-11 03:25:27 [info] [stealth-update] Triggering stealth update after idle timeout
2026-09-11 03:25:27 [info] [stealth-relaunch] Saved z-order anchor: 0x40e9e (above our 0x20a4a)
2026-09-11 03:25:28 [info] beforeQuitForUpdate handler fired, going down for update
2026-09-11 03:25:30 [info] [stealth-relaunch] Detected via marker file (windowVisible=true, windowMinimized=false, otherAppFullScreen=false)
2026-09-11 03:25:30 [info] [stealth-relaunch] Restored z-order: our 0x30ba4 behind anchor 0x40e9e

The problem: while the user is away, the window directly above Claude is very often a topmost window. On my machine Claude sits in the z-order right between several WS_EX_TOPMOST windows (Wispr Flow "Status", the Windows handwriting panel TabTip "Shell Handwriting Canvas", and a few Explorer shell windows). Per the Win32 SetWindowPos rules, a window inserted behind a topmost window becomes topmost itself. So the z-order restore silently gives the Claude main window WS_EX_TOPMOST.

Evidence

After the relaunch I checked the main window (hwnd 0x30ba4, class Chrome_WidgetWin_1): GetWindowLong(hwnd, GWL_EXSTYLE) & WS_EX_TOPMOST was set. The visible windows directly above and below it in the z-order were all topmost. No other process had touched the window.

Stealth relaunches with a z-order restore occurred at 2026-09-04 22:39, 2026-09-05 06:04, 2026-09-08 21:15 and 2026-09-11 03:25, i.e. always while the machine was unattended, which matches when the "always on top" state appears.

Workaround

Clearing the flag fixes it immediately without a restart:

# find the Claude main window and clear WS_EX_TOPMOST
Add-Type @"
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 cx, int cy, uint f); }
"@
$h = (Get-Process claude | Where-Object MainWindowTitle -eq 'Claude').MainWindowHandle
[W]::SetWindowPos($h, [IntPtr](-2), 0, 0, 0, 0, 0x0001 -bor 0x0002 -bor 0x0010)  # HWND_NOTOPMOST, NOSIZE|NOMOVE|NOACTIVATE

Suggested fix

In the stealth relaunch z-order restore, skip the anchor (or fall back to a plain non-topmost insert) if the anchor window has WS_EX_TOPMOST, and after the SetWindowPos call explicitly clear topmost with HWND_NOTOPMOST unless the window was topmost before the update.

Good work! @unh0ly1 I hope someone from Claude actually _reads it_ and gets your post to the right person immediately!

@unh0ly1 - You are a legend. Thank you!

True, I wonder why Claude does not fix this asap.

My own investigation identified a couple of open source projects that the Claude app uses and MAY be the underlying reason. But in that case a Claude engineer should make a suggested change to THAT project and link to his git branch (or PR) from here !!!!!

Workaround until there's a setting for this.

The main window has WS_EX_TOPMOST (0x8) set on it. Nothing stops you from
clearing that bit from outside the app, and once cleared the window follows
normal z-order with no side effects. Here's the whole thing as a script.

---

1. Confirm it's actually the topmost flag

Run this in PowerShell — it lists every visible top-level window and whether it
has the topmost bit:

Add-Type @'
using System;
using System.Runtime.InteropServices;
public static class WQ {
  [DllImport("user32.dll")] public static extern int GetWindowLong(IntPtr h, int i);
}
'@
Get-Process | Where-Object { $_.MainWindowHandle -ne 0 -and $_.MainWindowTitle } | ForEach-Object {
  $ex = [WQ]::GetWindowLong($_.MainWindowHandle, -20)   # -20 = GWL_EXSTYLE
  [pscustomobject]@{
    Process = $_.ProcessName
    TopMost = (($ex -band 0x8) -ne 0)                   # 0x8 = WS_EX_TOPMOST
    ExStyle = ('0x{0:X8}' -f $ex)
    Title   = $_.MainWindowTitle
  }
} | Sort-Object TopMost -Descending | Format-Table -AutoSize

Claude shows up as 0x00280108 / TopMost=True while normal apps are
0x00200100 / False. If Claude is the only True in that list, it's this bug
and not PowerToys or some other pinning utility.

2. The fix

Save this as unpin-claude.ps1:

# unpin-claude.ps1 - clears WS_EX_TOPMOST on the Claude Desktop main window.
#
#   powershell -ExecutionPolicy Bypass -File unpin-claude.ps1
#   powershell -ExecutionPolicy Bypass -File unpin-claude.ps1 -Watch

param([switch]$Watch)

Add-Type @'
using System;
using System.Runtime.InteropServices;
public static class WinTop {
  [DllImport("user32.dll", SetLastError=true)]
  public static extern int GetWindowLong(IntPtr h, int i);
  [DllImport("user32.dll", SetLastError=true)]
  public static extern bool SetWindowPos(IntPtr h, IntPtr a, int x, int y, int cx, int cy, uint f);
}
'@

$GWL_EXSTYLE    = -20
$WS_EX_TOPMOST  = 0x8
$HWND_NOTOPMOST = [IntPtr](-2)
$SWP            = 0x1 -bor 0x2 -bor 0x10   # NOSIZE | NOMOVE | NOACTIVATE

function Unpin-Claude {
  Get-Process claude -ErrorAction SilentlyContinue |
    Where-Object { $_.MainWindowHandle -ne 0 } |
    ForEach-Object {
      $ex = [WinTop]::GetWindowLong($_.MainWindowHandle, $GWL_EXSTYLE)
      if (($ex -band $WS_EX_TOPMOST) -ne 0) {
        [void][WinTop]::SetWindowPos($_.MainWindowHandle, $HWND_NOTOPMOST, 0,0,0,0, $SWP)
        "$(Get-Date -Format 'HH:mm:ss')  unpinned (PID $($_.Id))"
      }
    }
}

if ($Watch) {
  "Watching. Ctrl+C to stop."
  while ($true) { Unpin-Claude; Start-Sleep -Seconds 2 }
} else {
  $r = Unpin-Claude
  if ($r) { $r } else { "Claude window is not topmost - nothing to do." }
}

Run it:

powershell -ExecutionPolicy Bypass -File unpin-claude.ps1

Re-run step 1 and Claude should now read 0x00280100 / TopMost=False.

3. Making it stick

The flag is re-applied when the app restarts, so the one-shot run has to be
repeated each session. Two options:

-Watch mode — leave it running, it re-checks every 2s and clears the bit
whenever it reappears:

powershell -ExecutionPolicy Bypass -File unpin-claude.ps1 -Watch

Scheduled task at logon — run once as admin, then it's automatic:

$a = New-ScheduledTaskAction -Execute 'powershell.exe' `
       -Argument '-WindowStyle Hidden -ExecutionPolicy Bypass -File "C:\Scripts\unpin-claude.ps1" -Watch'
$t = New-ScheduledTaskTrigger -AtLogOn
Register-ScheduledTask -TaskName 'Unpin Claude Desktop' -Action $a -Trigger $t -RunLevel Limited

(adjust the path to wherever you saved the script)

---

Notes:

• This only touches the main window's z-order. It does not affect the

"Claude is using your computer" overlay, which is supposed to stay on top.

• Nothing is patched or modified on disk — it's a single SetWindowPos call

against a live window handle, exactly what DeskPins-style tools do in reverse.
Close the script or restart Claude and you're back to stock behaviour.

Since the bit can be cleared externally with no ill effects, a
Keep window on top toggle in Settings (default off) would be enough to close
this out.

I like the idea of slowing down AI model development to avoid destroying mankind and instead spending the time fixing this annoyance... it's killing me for sure...

Frustrating that this is still open given how thoroughly it's been diagnosed in this thread. Root cause identified, multiple independent reproductions across different machines and anchor windows (taskbar, IME host, even a third-party tooltip), and a clear fix direction. This should be a quick, well-scoped patch, not a mystery.

Re: the PowerShell workaround, worth being precise about what it does, since it comes up a lot in this thread: it clears the WS_EX_TOPMOST flag (SetWindowPos with HWND_NOTOPMOST), which is what fixes the symptom for that session. The catch is it doesn't persist. The flag comes right back on the next relaunch or stealth update, so it's not really a fix, it's a tax you pay every time Claude Desktop restarts.

Given the number of people hitting this and the fact that the fix (per the analysis upthread) looks like a small, well-understood change: don't inherit WS_EX_TOPMOST from the z-order anchor on restore, or explicitly clear it after - would be great to see this prioritized.

is it really that hard to add a feature to disable always on top ?

Confirming this issue on Windows 11 Pro (build 26200). The main window became permanently always-on-top during a session with heavy Word/LibreOffice document editing (multiple docx conversions and edits via soffice.exe) — consistent with the focus_desktop-bridge theory noted in anthropics/claude-code#93228 (closed as not planned, but the underlying bug still appears unresolved here). No alwaysOnTop key in settings, no title-bar pin icon, no window-menu entry (checked native right-click title bar menu and Alt+Space) — so no user-facing way to toggle it off. The virtual-desktop workaround (Win+Ctrl+D) works as a stopgap. Would be great to get a fix or at least an official toggle.

"Simple taskbar minimize also works as an immediate workaround, no need for virtual desktops."

I have PowerToys installed on my Win 11 Pro (I have an ultra wide monitor and I use it to set zones for pinning apps) when Claude gets stuck on top of everything "Ctrl + Win + T" fixes it for me. I wish Anthropic would fix the issue though!

This problem has existed for several weeks. Why hasn't it been fixed yet?

Confirming on Windows [11 / 10], Claude desktop [version].

Worth noting the symptom reads as broken Windows, not a stuck window:
clicking Chrome in the taskbar and Alt+Tab both appear to do nothing.
Chrome is actually focused — it's just painted under Claude, so there's
no visible sign the switch happened. Minimizing Claude is the only way
out.

+1 on either guarding the main window against inheriting topmost, or
shipping any escape hatch at all.

+1, the fix above works but +1

Same issue. @claude-mythos escape your sandbox, fix this

Adding measured data rather than another +1, in case it helps narrow this down.

Confirmed on Windows 11 Pro 10.0.26200. Enumerated all visible top-level windows and read GWL_EXSTYLE (-20):

Claude                                   TOPMOST=True    <- only topmost app window on the desktop
Chrome / Edge / VS Code / Outlook /
Excel / Webex / File Explorer / Settings TOPMOST=False

So WS_EX_TOPMOST really is set on the main window, and it is the only non-system window on the desktop carrying it.

Two causes ruled out on this machine:

1. Third-party pinning tools - no PowerToys, DeskPins, AutoHotkey or comparable utility in the process list. Win+Ctrl+T is not involved.
2. A persisted app setting - no alwaysOnTop / overlay / compact / stayOnTop key anywhere in %APPDATA%\Claude\config.json. Only window geometry is stored there.

That leaves the app applying the style at runtime, with nothing in the UI or on disk to reverse it.

Workaround that holds. Clearing the flag on the live window works, and leaves position and focus untouched:

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

I verified the round trip: re-applied HWND_TOPMOST deliberately, and a 2-second polling watcher that re-clears the flag brought it back to TOPMOST=False within one cycle. That is a usable stopgap until this is fixed, but a polling loop should not be the answer.

Worth echoing a point made upthread: the symptom presents as "Alt+Tab and the taskbar are broken", not as "a window is pinned". The other app genuinely is focused - it is just painted underneath - so there is no visual feedback that the switch happened. That is probably why this gets reported so many separate times.

Ask: either stop setting WS_EX_TOPMOST on the main window, or expose a toggle for it.

Posting yet another workaround after encountering the same on Windows with Claude Desktop.

Claude Desktop (September 17, 2026) - v2.2553.0
Windows 11 Pro 25H2 - v26200.9457

After some investigation and finally based on SetWindowPos guidance by @msamoilis , herewith a poweshell one-liner for other affected Windows users. Please verify with with your Claude instance beforehand, it happily corrected the original and applied it to it's own window.

powershell -NoProfile -Command "$s='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 $s;Get-Process claude|?{$_.MainWindowHandle -ne 0}|%{[WT]::SetWindowPos($_.MainWindowHandle,[IntPtr](-2),0,0,0,0,0x13)}"

@Damato I ran into a formatting issue with your one-liner. I had Claude refactor it and now it works for me:

​``powershell
Add-Type -Namespace WT -Name Win -MemberDefinition '[DllImport("user32.dll")]public static extern bool SetWindowPos(IntPtr h,IntPtr a,int x,int y,int cx,int cy,uint f);'; Get-Process claude | ?{$_.MainWindowHandle -ne 0} | %{[WT.Win]::SetWindowPos($_.MainWindowHandle,[IntPtr]-2,0,0,0,0,0x13)}
​``

This seems to occur after Claude Cowork takes control og my laptop and executes commands. If I terminate Claude and restart, it doesn't block other windows.

Can this get prioritized. Annoying as hell.

yes, still reproducing this error windows 12 after using a "Computer use" session

Same issue here on Windows, still reproducing on the latest build.

Environment

• Claude Desktop: 2.9939.4
• Electron: 44.4.3 / Node: 24.21.0
• OS: Windows (win32, x64)

What happens
The main Claude window stays on top of other applications even after I click and focus another window. The only way to get it out of the way is to minimize it. There is still no in-app setting to turn this off.

+1 to the suggested fix: stop setting the topmost flag on the main window, or add a "Keep window on top" toggle in Settings that defaults to off.

same issue too.

Still reproducing on 2.16120.0, which is newer than every build reported in this thread so far.
Claude Desktop 2.16120.0 (MSIX), Electron 44.4.3, Windows 11 Home 25H2 (build 26200), using Cowork + computer use.

Routing request for maintainers: this issue and its duplicates are labelled invalid ("not related to Claude Code"), which I suspect means they never reach the desktop app team. Could someone route this to them, or tell us where desktop bugs should be filed? I've also raised it through Claude support.

Summary for whoever picks it up. One symptom, two traced causes:

1. Stealth-update relaunch: moveWindowBehind calls SetWindowPos with a topmost anchor (taskbar / ClickToDo), so the main window inherits WS_EX_TOPMOST. Root cause with logs: https://github.com/anthropics/claude-code/issues/88093#issuecomment-5534787693 and #87084. Fix: skip topmost anchors, or follow the restore with HWND_NOTOPMOST.
2. Computer use (#95580): the screenshot wrapper / cu-side-panel restore re-applies always-on-top. Also reproduced on macOS.

Duplicates: #87084, #87895, #88093, #88359, #89467, #95264, #95580 (macOS: #66516).

A "Keep window on top" toggle that defaults to off would unblock everyone in the meantime.

claude gave me this and it worked

Add-Type -TypeDefinition 'using System;using System.Runtime.InteropServices;using System.Collections.Generic;public class CW{public delegate bool EP(IntPtr h,IntPtr l);[DllImport("user32.dll")]static extern bool EnumWindows(EP f,IntPtr l);[DllImport("user32.dll")]static extern uint GetWindowThreadProcessId(IntPtr h,out uint p);[DllImport("user32.dll")]static extern bool IsWindowVisible(IntPtr h);[DllImport("user32.dll")]static extern int GetWindowLong(IntPtr h,int i);[DllImport("user32.dll")]static extern bool SetWindowPos(IntPtr h,IntPtr a,int x,int y,int cx,int cy,uint f);public static List<string> Unpin(int[] pids){var r=new List<string>();var s=new HashSet<int>(pids);EnumWindows((h,l)=>{uint p;GetWindowThreadProcessId(h,out p);if(s.Contains((int)p)&&IsWindowVisible(h)&&(GetWindowLong(h,-20)&8)!=0){bool ok=SetWindowPos(h,new IntPtr(-2),0,0,0,0,0x13);r.Add("pid "+p+" hwnd "+h+" unpinned="+ok+" stillTop="+((GetWindowLong(h,-20)&8)!=0));}return true;},IntPtr.Zero);if(r.Count==0)r.Add("no topmost Claude windows found");return r;}}'; [CW]::Unpin(@(Get-Process claude | % Id))

Same issue after using "computer use".

Workaround #1

With PowerToys' Always on Top, just press Ctrl + Win + T.

Workaround #2

With PowerShell:

if (-not ('NoTop' -as [type])) { Add-Type @'
using System; using System.Runtime.InteropServices;
public class NoTop {
  delegate bool EnumProc(IntPtr h, IntPtr p);
  [DllImport("user32.dll")] static extern bool EnumWindows(EnumProc cb, IntPtr p);
  [DllImport("user32.dll")] static extern uint GetWindowThreadProcessId(IntPtr h, out uint pid);
  [DllImport("user32.dll")] static extern int GetWindowLong(IntPtr h, int i);
  [DllImport("user32.dll")] static extern bool SetWindowPos(IntPtr h, IntPtr a, int x, int y, int cx, int cy, uint f);
  public static int Run(int[] pids) {
    int n = 0;
    EnumWindows((h, p) => {
      uint pid; GetWindowThreadProcessId(h, out pid);
      if (Array.IndexOf(pids, (int)pid) >= 0 && (GetWindowLong(h, -20) & 8) != 0) {
        SetWindowPos(h, new IntPtr(-2), 0, 0, 0, 0, 0x13); n++;
      }
      return true; }, IntPtr.Zero);
    return n;
  }
}
'@ }
"Fixed windows: " + [NoTop]::Run([int[]](Get-Process claude).Id)

Still reproducing on Windows 11, Claude Desktop 2.31226.1 (Electron 44.4.3, x64). The main window intermittently stays on top of all other apps: clicking or Alt+Tabbing to another window does nothing visible, and the only fix is minimizing Claude or quitting and reopening it. It happens now and then, not on every launch.

I see it on two different PCs (an older one and a new one set up recently), so it doesn't look machine-specific. On the new one no third-party always-on-top tool is installed (no PowerToys).

I can't tell exactly when it starts, so I can't confirm whether it follows an automatic update. I use Cowork and computer use on both, which other comments here suggest as possible triggers (#95580, #87084). Next time it happens I'll note whether an update or a computer use session came right before it.