[BUG] Linux/GNOME Wayland: Desktop app self-focuses its window on Code session completion, hijacking Ctrl+Alt+Arrow workspace switching

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 Ubuntu 26.04 with GNOME Shell 50.1 (Wayland session), the Claude Desktop app's Code tab window raises and refocuses itself -- and drags the user's active GNOME workspace along with it -- every time a Code session finishes a turn. This happens mid-sequence while using Ctrl+Alt+Left/Ctrl+Alt+Right to move between workspaces: as soon as a running Code session completes, the active workspace snaps back to whichever workspace the Claude window lives on, breaking the key sequence and making normal multi-workspace navigation unusable whenever a Code session is active.

The trigger correlates exactly with a [Stop hook] Query completed for session ... line in the app's own ~/.config/Claude/logs/main.log (see Error Messages/Logs below), i.e. it fires on ordinary turn completion, not only on errors or permission prompts.

What Should Happen?

Claude Desktop should not forcibly raise its window or change the user's active GNOME workspace when a Code session finishes. At most it should surface a passive attention indicator (taskbar flash / notification), without an actual window-activation call that pulls compositor focus and the active workspace away from whatever the user is doing.

Error Messages/Logs

From ~/.config/Claude/logs/main.log, timestamp-correlated with the observed workspace snap-back:

2026-09-22 10:02:47 [info] [Stop hook] Query completed for session local_50de1479-3168-4f86-a559-7d26610dd9c7
2026-09-22 10:02:47 [info] [CCD CycleHealth] healthy cycle for local_50de1479-3168-4f86-a559-7d26610dd9c7 (37s, hadFirstResponse=true)
2026-09-22 10:02:47 [info] Mapping internal session local_50de1479-3168-4f86-a559-7d26610dd9c7 to CLI session a8dcee26-2ff4-4460-9d83-f8871be32067

This is the only event in the log that lines up with the moment the window steals focus/workspace. No crash, no error is logged -- it's ordinary turn completion.

Steps to Reproduce

Step 1: On Ubuntu 26.04.1 LTS (GNOME Shell 50.1, Wayland session), open Claude Desktop and start or continue a Code tab session in a project directory.
Step 2: Send Claude a message so it starts working (main.log logs a [keep-awake] code session hold taken (turn, ...) entry at this point).
Step 3: While Claude is working, repeatedly press Ctrl+Alt+Right to move across several GNOME workspaces, away from the workspace Claude Desktop is on.
Step 4: When the turn finishes, main.log logs [Stop hook] Query completed for session .... At that exact moment the active workspace jumps back to whichever workspace holds the Claude Desktop window, interrupting the Ctrl+Alt+Arrow sequence in progress.

This reproduces even with all of the following already applied, none of which changed the behavior. (a) GNOME per-app notification banner disabled: gsettings set org.gnome.desktop.notifications.application:/org/gnome/desktop/notifications/application/com-anthropic-claude/ show-banners false. (b) Mutter focus-stealing prevention set to strict: gsettings set org.gnome.desktop.wm.preferences focus-new-windows 'strict'. (c) In-app Settings -> Claude Code: "Task complete notifications" set to Off, "Draw attention on notifications" already Off.

None of these gate the window-raise itself -- only the notification/banner/taskbar-flash layer.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.275 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Environment: Ubuntu 26.04.1 LTS, GNOME Shell 50.1, native Wayland session (not XWayland). Claude Desktop app version 2.2553.1 (Electron 44.2.0). "Terminal/Shell" above is N/A -- this is the standalone Claude Desktop app's Code tab, not a terminal.

Not actually about a terminal: I picked "Other" for Terminal/Shell above because this bug is about the standalone Desktop app's own window, not a terminal emulator.

This looks like the same bug class as three other open issues, just manifesting as workspace disruption specifically on GNOME/Wayland rather than plain foreground-stealing: issue 62447 (desktop app steals focus on every notification, macOS), issue 94460 (feature request for a setting to stop the app window from stealing focus), and issue 74914 (GNOME Wayland, "Claude is ready" notification tied to focus changes). None of those three describe the specific workspace-switch interruption, and issue 94460's confirms there is currently no setting -- app-side or OS-side -- that gates the underlying window-activation call, only the notification channel around it.

Requested fix: either respect a setting like the stealFocusOnAttentionNeeded: false proposed in issue 94460, or, at minimum on Linux, avoid calling window.show()/focus()/present() on Code-tab turn completion and instead use a passive attention indicator only.