[BUG] Claude Desktop window raises to front on mouse hover (LinuxMint/Cinnamon), unlike other Electron apps
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
On Linux Mint 22.1 (Cinnamon), the Claude Desktop window comes to the front and steals focus whenever the mouse cursor merely touches any part of the window — even without clicking. This happens while another window is active and in front. It does not happen with other applications, including other Electron apps on the same system (VSCode) or non-Electron apps (Firefox).
Environment
- OS: Linux Mint 22.1
- Desktop Environment: Cinnamon (Muffin window manager)
- App: Claude Desktop (latest)
What Should Happen?
Claude Desktop should only gain focus/raise on an explicit user action (click), matching standard window behavior and the behavior of every other app on the system.
Actual Behavior
Claude Desktop raises to the front on mouse-over alone.
Error Messages/Logs
Steps to Reproduce
- Open Claude Desktop and another application (e.g., a terminal or Firefox window).
- Bring the other application to the front so it's the active/focused window.
- Move the mouse cursor so it merely passes over any part of the Claude Desktop window, without clicking.
- Observe Claude Desktop immediately raises to the front and takes focus.
Claude Model
_No response_
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.201 (Claude Code)
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
Troubleshooting Already Done
- Cinnamon focus settings: Checked Menu > Settings > Windows > Focus. Window focus mode and "Automatically raise focused windows" don't explain this, since a WM-level setting would affect all windows equally — but Firefox and VSCode are unaffected under the same settings.
- Always on Top: Confirmed via window titlebar context menu that "Always on Top" is not enabled for the Claude window.
- xprop: Compared _NET_WM_STATE, WM_HINTS, and _NET_WM_WINDOW_TYPE between Claude Desktop and Firefox. The only notable difference found was _NET_WM_BYPASS_COMPOSITOR = 2, which per the EWMH spec only requests that the compositor not disable compositing for the window — unrelated to focus or stacking behavior.
- xev: Watched X11 events on the Claude Desktop window while hovering into it from outside. No EnterNotify or other unusual event appeared that would explain a raise being triggered at the X11 level.
- Other Electron apps: VSCode, also Electron-based, does not exhibit this behavior on the same system, ruling out a generic Electron/Linux windowing issue.
Add'l Notes
Given the above, this appears to be specific to how Claude Desktop's BrowserWindow is configured or how it handles focus/show internally, rather than a system-level or generic Electron issue. There doesn't appear to be an in-app setting to disable this behavior.
Relates to #73627. Note that this is calude-desktop behavior.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
This issue was also raised in a repository that repackages Claude for Linux, predating the first-party Linux release. It has a few more details that may be relevant: aaddrick/claude-desktop-debian #416
I also experience this issue in FVWM with MouseFocus. Any window manager with such a focus policy is probably affected.
Seeing this on GNOME/Mutter as well, so that's a third focus-follows-mouse setup after Cinnamon and FVWM. It really does look WM-independent and just needs a focus-follows-mouse policy to show up.
My setup:
focus-mode=sloppyandauto-raise=falseI think I found what's actually triggering it, which I haven't seen mentioned here yet. Claude's window uses a hidden title bar (client-side decorations), while the apps that behave normally use a regular server-side frame. In the app bundle the main window is created with:
You can see the difference with xprop (the third
_MOTIF_WM_HINTSvalue is the decorations flag):Neither window is
_NET_WM_STATE_ABOVEwhile idle, so it isn't "always on top", it's a raise that happens on focus-in. It's also instant, quicker than Mutter's 500 msauto-raise-delay, so it isn't the WM's own auto-raise firing either. My guess is that a frameless Chromium window on X11 runs its "activate" path when it gets focus, and activate does anXRaiseWindow/_NET_ACTIVE_WINDOW. Under focus-follows-mouse, "gets focus" just means "the pointer touched it", so it raises on hover. A normally framed Chromium window (like Ferdium) doesn't do this. I couldn't find any app-side code raising the window on focus or hover, so it really seems to come from Chromium's activation rather than Claude's own JS.This might be the same underlying issue as #81497 (titleBarOverlay being applied to Linux windows).
For reference, on the same session GNOME Terminal and Ferdium both take focus on hover without raising and only come to the front when I click them, so
auto-raise=falseis being respected for everything except Claude.A possible fix would be to not run the activate/raise path on plain focus-in for the frameless window on X11 (only raise on a real click), or to add an option to turn it off.
(Attaching my environment, the gsettings output, the full xprop comparison, and the window options.)
environment.txt
main-window-options.txt
wm-focus-settings.txt
xprop-window-comparison.txt
Same issue here on Ubuntu Gnome 24.04
I suffer from this exact issue on KDE Plasma / KWin (both X11 and Wayland).
This isn't desktop-environment-specific.
Environment
What I tried (all ineffective)
Likely duplicate, wrongly closed
This looks identical to #73627, which was closed as "not planned"/invalid, but the reporter's KWin config and suspected cause exactly match what's happening here — same as on Cinnamon. I don't think that closure was correct; this is clearly reproducible across at least two independent Linux desktop environments (KWin and Muffin) with matching config.
Root cause (cross-referenced)
This matches a known open Electron/Chromium bug: electron/electron#38184 —
webContents.focus()(called on window focus-in) issues a direct raise/restack to the display server rather than going through the WM's activation protocol, which is why WM-side settings (autoraise, focus stealing prevention, window rules) can't intercept it. Same root cause was independently confirmed by Mattermost Desktop: mattermost/desktop#1827, mattermost/desktop#2797.Given this can't be fixed via window-manager configuration on the user side, the ask is either (a) a fix/workaround on the Electron side of Claude Desktop for this focus-in handling, or (b) an option to use the native system titlebar so standard WM controls (e.g. manual lower) are available as a fallback.