[Desktop App / Linux] Dragging a pane header does not reposition the pane (menu commands do)

Summary

On Linux, dragging a pane by its header does nothing — no drag preview, no drop
indicator, no reposition. The documented behaviour
(Arrange your workspace)
is "Drag a pane by its header to reposition it, or drag a pane edge to resize it."
Edge-resize works. Header-drag does not.

This is not the same root cause as #48493 (Windows: header drag moves the whole
window, suspected -webkit-app-region: drag conflict). On Linux the window does not
move — the gesture simply has no effect. See "Ruled out" below.

Environment

• Claude Desktop 1.37937.3, Linux
• Bundled Electron 42.10.0 (resources/version)
• Manjaro Linux, kernel 7.1.9-1-MANJARO
• Compositor: sway (wlroots), Wayland session, Xwayland available
• Displays: 3840x2160 + 3840x2160 + 3456x2160 built-in, all scale factor 1

Reproduced independently on a second machine: Ubuntu, official .deb build,
different desktop environment. So this is not specific to sway/wlroots or to the
repackage below.

Note: this is a community repackage of the official Linux build, not the official
.deb. The repackage does not patch anything in the pane layout / renderer path;
it adds launcher-level flag handling and profile isolation. Flagging it for
completeness in case it matters.

Steps to reproduce

1. Open the Code tab with a session.
2. Open a second pane from the Views menu (terminal, diff, tasks — any).
3. Drag that pane by its header toward another pane's position.

Expected: the pane detaches / a drop target appears / the pane repositions.
Actual: nothing happens. No drag preview, no drop indicator, no layout change.

For contrast, the same reposition performed from that pane's triple-dot (⋮) menu
works correctly — so the target state is reachable, just not by the documented
gesture.

What still works

These narrow the fault considerably:

• Pane edge-drag resize works. So pointer-move drag handlers in the pane layout

are alive; only the reposition gesture is dead.

• Title-bar drag moves the window (default integrated-titlebar mode), so

-webkit-app-region: drag is functional and sway honours xdg_toplevel.move.

• HTML5 drag-and-drop works in the app's own Browser pane. A local probe page

with a draggable element and a drop zone fires dragstart → dragenter →
dragover → drop → dragend normally; a pointer-event reorder list also works.
(Caveat: the Browser pane is a separate webContents from the session panes.)

• The per-pane triple-dot (⋮) menu reorders panes correctly. Every pane

except the leftmost has move commands in that menu, and they work — the panes
reposition as expected. This is the important one: the layout engine's reorder
logic is fully functional, and only the drag gesture is dead. That makes this an
input-binding bug (the header's drag handler never engages), not a layout bug.

Ruled out

| Hypothesis | Test | Result |
|---|---|---|
| Wayland / compositor DnD bug | Ran with --ozone-platform=wayland vs --ozone-platform=x11 (XWayland), two concurrent instances with isolated user-data dirs | Fails identically on both |
| -webkit-app-region: drag overlay eating the pointer (the #48493 diagnosis) | Ran with the integrated overlay titlebar vs frame:true + titleBarStyle:"default" | Fails in both modes |
| Pane header sits inside a window drag region | Drag a pane header on the overlay-titlebar build | Window does not move — so the header is receiving the pointer, not the drag region |
| Chromium/Electron HTML5 DnD broken | Probe page in the Browser pane | drop fires normally |
| Feature gated off by a flag | Checked all 134 GrowthBook flag ids observed being read from the feature store | No pane-layout / drag flag exists |
| Feature not present in this build | Version is far past the v1.2581.0 minimum the docs state for pane layout | Present |

Four-cell matrix, all failing:

| | Native Wayland | XWayland |
|---------------------|----------------|----------|
| Overlay titlebar | fails | fails |
| Native titlebar | fails | fails |

Workaround

Use the move commands in each pane's triple-dot (⋮) header menu. They work
correctly.

This is a partial substitute at best: the documented gesture is drag-by-header, the
shortcut table has no move-pane binding (only the Ctrl+Shift+D / Ctrl+Shift+B /
` Ctrl+ ` toggles and Ctrl+\` to close), and the leftmost pane exposes no move
items at all. It is also undiscoverable for anyone following the documentation.

Note on renderer inspection

I could not inspect the renderer to narrow this further: launching with
--remote-debugging-port is refused (Claude: refusing to start — a debugging or
network-override switch is present on the command line). Happy to run any
diagnostic that doesn't require that switch.