GNOME/Wayland: workspace switch away from a focused Claude window snaps back

Summary

On GNOME 50 / Wayland, switching workspaces away from a focused Claude desktop window immediately snaps the workspace back to the Claude window. Switching away from an unfocused Claude window works correctly.

Environment

• OS: Ubuntu, Linux 7.0.0-31-generic
• Desktop: GNOME Shell 50.1, Wayland session (XDG_SESSION_TYPE=wayland)
• Claude desktop app version: 1.49585.0

Reproduction

1. Open the Claude desktop app and click into it so the window has keyboard focus.
2. Press <kbd>Ctrl</kbd>+<kbd>Alt</kbd>+<kbd>Left</kbd> / <kbd>Right</kbd> (or any other workspace-switch binding).
3. The workspace switches, then immediately reverts to the workspace containing the Claude window.

Happens most of the time, though not on literally every attempt.

What distinguishes the failing case

The variable is focus, not the keybinding or notifications:

| Case | Result |
|---|---|
| Claude window focused, Ctrl+Alt+Left/Right | Jumps back |
| Claude window focused, Super+Page_Up/Down | Jumps back |
| Claude window focused, Super+Alt+Left/Right | Jumps back |
| Claude window visible but unfocused (clicked another window first), then switch | Works correctly |
| Switch via Activities overview (shell takes focus first) | Works correctly |

So any compositor-level workspace switch away from a focused Claude window is reverted; the same switch from an unfocused window is not.

Things ruled out

• Not focus-stealing prevention. Setting org.gnome.desktop.wm.preferences focus-new-windows to 'strict' has no effect. Expected, since the app holds a fresh, valid xdg-activation token from the keypress that triggered the switch, and mutter honors valid tokens unconditionally.
• Not the keybinding. Three different workspace-switch bindings all reproduce it.
• Not notifications, despite a "Claude is ready"-style notification appearing at the same moment. Disabling them per-app via org.gnome.desktop.notifications.application:.../com-anthropic-claude/ enable false does not stop the jump, and the two working cases above also fire a notification on focus-loss. dbus-monitor confirms the app still issues org.freedesktop.Notifications.Notify (hint desktop-entry = com.anthropic.Claude) regardless.

Expected behavior

Losing keyboard focus due to a workspace switch should not cause the window to request activation.

Likely cause

Something in the app's blur/focus-loss handling re-activates the main window (e.g. a show()/focus() call on browser-window-blur, or an activation request attached to the notification path). Because the activation token is valid at that instant, the compositor honors it and pulls the user back.