[BUG] Desktop Code tab: pane-header drag target for rearranging panes is ~1px tall, making custom layouts effectively unachievable (NOT the app window drag region)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 22, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

This is not the window-drag bug

Please do not close this as a duplicate of #50601, #51140, or #48493. Those three are all about moving the application window around the screen. This report is about a different control: the drag handle on a pane header used to rearrange panes inside the Code tab's layout, documented at https://code.claude.com/docs/en/desktop under "Arrange your workspace" ("Drag a pane by its header to reposition it").

This still reproduces on 1.34493.1, built 2026-08-21 — roughly three months after #50601 was closed for inactivity and two months after #48493 was closed as not planned. The behaviour has not been fixed in the interim; the reports were simply timed out.

There are currently zero open issues covering pane rearrangement. #51140 was auto-closed by the duplicate bot 3 days after filing and rolled into #50601, which was then closed "not planned" by the stale bot despite a confirmed third-party repro. All three are locked. Per those bots' own closing messages, this is filed as a new issue referencing them.

What's Wrong?

In the Code tab, panes (Browser, Files, file editor, diff, terminal) are documented as rearrangeable by dragging a pane by its header. In practice the region of the header that actually initiates a pane drag is a sliver — on the order of a single pixel of vertical travel. Pressing and dragging anywhere else on the header does one of two things:

  • nothing at all — no drop-target highlight appears, and releasing leaves the layout unchanged; or
  • moves the entire application window, because the press lands in the Electron window drag region instead.

The result is that the documented layout feature is not usable. Across extended use I have succeeded in repositioning a pane exactly once, and could not reproduce the successful grab afterwards.

What Should Happen?

The full height and width of a pane header (excluding its buttons) should be a valid drag handle for repositioning that pane, with the window drag region not overlapping it. A press-and-drag anywhere on the header should show the drop-target highlight and complete the reposition on release.

Steps to Reproduce

  1. Open a Code tab session on macOS.
  2. Open the Browser pane (Cmd+Shift+B) and the Files pane (Views menu).
  3. Press and hold on the Files pane header — on its title text, mid-header — and drag toward the lower half of the Browser pane.
  4. Observe: no drop-target highlight appears and the layout is unchanged on release. Repeat with the press origin moved 1–2px at a time vertically within the header; at most one narrow band initiates a drag, and a band near the top moves the whole app window instead.

Target layout (as a concrete example of what is currently unachievable)

Chat column on the right. To its left: Browser pane spanning the full width of that region at the top, and beneath it two side-by-side panes — Files and the open file editor.

Environment

  • Platform: macOS (darwin 25.x / Tahoe)
  • Claude Desktop version: 1.34493.1 (255293) 2026-08-21T02:05:20.000Z
  • Surface: Claude Code Desktop, Code tab

View original on GitHub ↗