anthropics / anthropics/claude-code

[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)

Open
#88,744 0 comments 0 reactions 0 assignees View on GitHub
area:desktop area:ui bug has repro platform:macos
Dominant language
Python
Stars
145k
Forks
23.1k
PR merge metrics
PR metrics pending

Description

### 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

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by locating the Desktop Code tab's pane-header drag handling and the Electron window drag-region configuration, then reproduce the issue on macOS using the Files and Browser panes. Done means the full pane header, excluding its buttons, shows a drop-target highlight and rearranges the pane without moving the application window.

Written by the indexing model from the issue text.

Assessment

Tech stack
electron
Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.