[BUG][Windows] Documented pane-drag feature broken on Windows — panes cannot be repositioned (works on macOS) — request to reopen #48493

TL;DR for triage: Your own docs promise this feature. It works on macOS. It is broken on Windows. Win32-level forensics below pinpoint the likely cause to a -webkit-app-region conflict — plausibly a small CSS/JS fix. Related issue #48493 was closed as "not planned" without a stated reason, which effectively means the documented feature was silently dropped for one platform. Requesting reopen or a docs correction.

1. The contradiction (this is a broken documented feature, not a feature request)

The official Claude Code Desktop documentation states:

"Drag a pane by its header to reposition it, or drag a pane edge to resize it." — https://code.claude.com/docs/en/desktop

On Windows, this does not work. Dragging a pane/panel header either does nothing or moves the entire application window. On macOS, per #48493, panes drag and rearrange as documented.

This makes it a platform-parity regression of a documented feature — Windows users are paying for a capability the docs promise and the product does not deliver.

2. Environment

• OS: Windows 11 Pro, build 10.0.26200
• Claude Desktop (MSIX): 1.25927.0.0 (Claude_1.25927.0.0_x64__pzs8sxrjxfjjc)
• Claude Code runtime: 2.1.221 (auto-updated, under %APPDATA%\Roaming\Claude\claude-code\)
• System locale: he-IL — verified irrelevant, see forensics below

3. Steps to reproduce

1. Open Claude Desktop on Windows.
2. Open a second session so a secondary pane/panel is visible alongside the main view.
3. Click-and-drag the secondary pane by its header.

Expected (per docs): the pane repositions.
Actual: the pane does not move; only the main application window responds to drag.

4. Forensics already done for you (Win32 level)

To save triage time, the following was verified on the affected machine:

a. The app is a single top-level HWND — panes are DOM elements, not OS windows.
EnumWindows over all visible windows of the claude process returns exactly one top-level window:

Proc=claude  Title='Claude'  Class=Chrome_WidgetWin_1  Parent=0
Style=0x15C70000  ExStyle=0x280100

So pane dragging must be implemented in the renderer (JS/CSS), and the failure is in the app's own drag handling — not in the OS window manager.

b. RTL/locale ruled out. System locale is he-IL, but ExStyle 0x280100 & WS_EX_LAYOUTRTL (0x400000) = 0 — no OS-level RTL mirroring is applied to the window. Locale is not a factor.

c. Consistent with #48493's hypothesis: a -webkit-app-region: drag region (used for the frameless window's title bar) is capturing pointer events that the pane-drag handler needs on Windows. If so, the fix is likely on the order of adding -webkit-app-region: no-drag to pane headers plus verifying the mousedown/mousemove drag handler fires on Windows — a small, well-bounded change.

5. Why this matters more than one user's layout preference

Multi-session parallel work is the core power-user workflow of Claude Code Desktop — the exact behavior these open requests describe:

• #30154 — FEATURE: Multi-window support in Claude Code Desktop
• #50963 — Detach session into its own window for multi-monitor workflows
• #60879 — Support multiple windows on Windows for virtual-desktop workflows
• #46178 — "New Window" option removed (regression, closed not-planned)
• #48493 — Pane drag broken on Windows (this bug, closed not-planned)

Since true multi-window is not available, in-app pane dragging is the only remaining way to arrange parallel sessions on Windows — and it is broken. The users hitting this are, almost by definition, the heaviest multi-session users: the highest-usage, highest-spend cohort of the product. (This report comes from a paying subscriber running multiple concurrent sessions daily.)

6. What is being requested (pick one — but silence is the only wrong answer)

1. Reopen #48493 and fix pane-header dragging on Windows (suspected small CSS/JS fix, section 4c), or
2. If pane dragging on Windows is intentionally unsupported, update https://code.claude.com/docs/en/desktop to say so explicitly, so Windows users stop debugging their own machines (this report exists because the docs say the feature should work), and**
3. Ideally: state the plan for Windows multi-session layout (pane drag fix or multi-window support per #30154/#60879) so the demand cluster above has a home.

Happy to test any build or provide additional diagnostics (ETW traces, DevTools inspection of the pane header element) on request.