[BUG] Title bar context menu freezes app on GNOME/X11 (infinite _NET_CLIENT_LIST_STACKING loop)

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?

Opening and closing the title bar context menu freezes Claude Desktop on GNOME/X11. Xorg and gnome-shell spike to 100% CPU and stay there. The whole desktop becomes unusable: the taskbar and hot corner stop responding, since the popup retains a pointer/keyboard grab. The Super key still works, because mutter handles it before the grab. Other windows render black when brought to the front.

No menu action is required — mapping and unmapping the popup is enough to trigger it.

What Should Happen?

The menu should close and nothing else should happen.

Error Messages/Logs

No error messages. The symptom is visible in the X11 stacking order. xprop -root -spy _NET_CLIENT_LIST_STACKING shows two windows swapping the top of the stack continuously, in perfect alternation, for over 2 minutes:

_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x4000007, 0x2c00004, 0x3c00004, 0x3e0000a
_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x4000007, 0x2c00004, 0x3e0000a, 0x3c00004
_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x4000007, 0x2c00004, 0x3c00004, 0x3e0000a

0x3c00004 is the Claude Desktop window (WM_CLASS = "com.anthropic.claude"); 0x3e0000a is gnome-terminal.

Steps to Reproduce

1. Open Claude Desktop on GNOME/X11
2. Click the title bar context menu
3. Close it without selecting anything

Recovery: pkill -f claude-desktop from a TTY (Ctrl+Alt+F3).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

Unknown

Claude Code Version

Claude Desktop 1.24012.9 (not Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Setting _NET_WM_STATE_ABOVE externally works correctly — mutter accepts and keeps the state, with no loop and no CPU spike:

wmctrl -i -r <window_id> -b add,above

So the stacking protocol itself is fine; the problem appears specific to the Electron popup window. Side effect worth noting: after setting it externally, Electron's internal state desyncs and the "Always on top" menu item shows as checked but disabled.

Desktop environment: GNOME on X11 (mutter). Ubuntu 24.04.4 LTS. Kernel: 7.0.0-28-generic. GPU: 580.173.02. CUDA: 13.0