Quick Entry feature does not work properly

[gianluca-peri]

The Problem

On Fedora 43, with desktop environment: Gnome 49.5, the Quick Entry feature (that can be set under Settings -> General -> Quick Entry keyboard shortcut) does not work properly (i.e. most of the times it doesn't work at all). I suspect this to be a general issue, at least under the Gnome desktop environment.

Issues

The keyboard shortcut only works if the claude-desktop app window is in focus, if instead another window is in focus, or the user is active on another Gnome desktop, the shortcut does nothing. This is clearly not intended behavior since the feature description is "Quickly open Claude from everywhere".

Steps to reproduce

On Fedora 43 (Gnome), download the current version of claude-desktop via dnf, following the provided repo instructions, and then try opening the Quick Entry chat bar when the claude-desktop app window is not in focus. Nothing will happen, and this is the anomalous behavior.

[github-actions]

The launcher already defaults to --ozone-platform=x11 on Wayland sessions to run Electron through XWayland and preserve globalShortcut. That path should handle this case. First thing worth checking is whether it's actually taking effect:

cat ~/.cache/claude-desktop-debian/launcher.log

You should see Using X11 backend via XWayland (for global hotkey support). If it shows Using native Wayland backend instead, the detection logic isn't picking up your session as Wayland.

If the log confirms XWayland mode is active and the shortcut still doesn't fire, that's a different problem. GNOME has tightened X11 key-grab policies under XWayland in recent releases, and Fedora 43 ships a late enough GNOME that XWayland grabs may not work anymore. The upstream app uses a raw globalShortcut.register() call with no portal fallback, so the fix has to live in the launcher. The right approach is adding --enable-features=GlobalShortcutsPortal to the native Wayland path, which routes through XDG Desktop Portal instead of X11 key grabs. That flag isn't wired up yet — see also #370, which hit a similar layer of Wayland/Electron friction on KDE.

---

This is an automated triage comment. A maintainer will review this issue and may provide further guidance.

Written by Claude Sonnet via Claude Code

[boommasterxd]

Same problem for me.

[aaddrick]

Hey! I'm consolidating the three open quick-window issues over on #393 since they all overlap on Wayland/compositor behavior and affect shared environments. This one stays open because it's a distinct problem, but the overall plan and VM bisect work is posted there. Follow #393 for status updates.

[aaddrick]

Quick status: #406 just merged a temporary KDE gate on the quick-window patch — if the issue you're hitting was caused by #390 regressing GNOME, next main build should fix it. If the shortcut still doesn't fire at all after that, it's the separate XWayland key-grab problem and I'll work on the --enable-features=GlobalShortcutsPortal launcher change once I have Fedora 43 GNOME reproducing it in a VM. Please retest once a fresh build is available and let me know.

[gianluca-peri]

Quick status: #406 just merged a temporary KDE gate on the quick-window patch — if the issue you're hitting was caused by #390 regressing GNOME, next main build should fix it. If the shortcut still doesn't fire at all after that, it's the separate XWayland key-grab problem and I'll work on the --enable-features=GlobalShortcutsPortal launcher change once I have Fedora 43 GNOME reproducing it in a VM. Please retest once a fresh build is available and let me know.

Hello, quick update, I really don't know why, but yesterday for a brief period of time the shortcut control + alt + space was working fine without the Claude Desktop App in focus, and also from all desktop (I am referring to my Fedora setup, described at the start of this thread). Today however it ceased working.. really mysterious behavior. I have kept updated the claude-desktop via dnf update.

[gianluca-peri]

Quick diagnostic update from my Fedora 43 / GNOME setup, in case it helps narrow things down.

Environment:

• Fedora 43
• GNOME Shell 49.5 (Wayland session: XDG_SESSION_TYPE=wayland, XDG_CURRENT_DESKTOP=GNOME)
• claude-desktop-1.2278.0-1.3.30.fc42.x86_64

Launcher log (~/.cache/claude-desktop-debian/launcher.log) consistently shows:

Using X11 backend via XWayland (for global hotkey support)

So the XWayland path is being selected correctly — this doesn't look like the #390/#406 GNOME regression.

Live test with tail -f on the launcher log while pressing Ctrl+Alt+Space:

• With another window focused: nothing happens, and no new log lines appear.
• With Claude Desktop focused: shortcut fires, and I see [Frame Fix] Popup detected, keeping frameless / [Frame Fix] Linux patches applied in the log.

No conflicting GNOME binding either — gsettings list-recursively | grep -i "<Control><Alt>space" returns nothing.

This matches the XWayland key-grab hypothesis from the triage comment: mutter on recent GNOME isn't honoring the XWayland-side grab, so globalShortcut.register() only receives the key when the XWayland client already has focus. I also briefly saw it working "globally" for a short period yesterday before it stopped again, which is consistent with transient compositor state rather than a code-level fix.