[BUG] Windows: pop-out session windows have no min/max/close buttons and cannot be dragged - WS_SYSMENU missing after setTitleBarOverlay fails

Summary

On Windows, a session opened via "open in -> new window" produces a window with:

• no minimize / maximize / close buttons
• no system menu (Alt+Space does nothing)
• a title bar that cannot be grabbed, so the window cannot be moved at all

The window is effectively pinned in place. This is a regression; these windows previously had working chrome.

Environment

| Field | Value |
|---|---|
| Claude Desktop version | 1.26832.0 |
| Install type | MSIX / Store (C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc) |
| OS | Windows 11 Pro, build 26200 |
| Display language | en-US (not an RTL locale) |
| Plan | Max |

Note on locale: this is deliberately called out because of the existing RTL cluster (#53255, #61119, #51213). This report is not that bug. The system language here is en-US and the main window renders its buttons correctly.

Steps to reproduce

1. Open Claude Code desktop on Windows.
2. Pick any session, choose open in -> new window.
3. Observe the resulting window's title bar.

Expected: standard window controls, and a draggable title bar.
Actual: only a pin icon and a ... menu. No window controls. The title bar does not respond to mouse drag.

Root cause

1. The windows are created without WS_SYSMENU

Measured with GetWindowLong(hwnd, GWL_STYLE) over all top-level windows owned by the claude process:

style = 0x14C70000
  WS_MAXIMIZEBOX (0x00010000) = True
  WS_MINIMIZEBOX (0x00020000) = True
  WS_THICKFRAME  (0x00040000) = True
  WS_CAPTION     (0x00C00000) = True
  WS_SYSMENU     (0x00080000) = False   <-- missing

Win32 documents that WS_MINIMIZEBOX and WS_MAXIMIZEBOX require WS_SYSMENU to also be specified. Without the system menu the OS has nowhere to render the caption buttons, and Alt+Space has no menu to open.

2. The main window has the identical style

The main Claude window measures the same 0x14C70000, also without WS_SYSMENU. It looks fine only because the app draws its own buttons in its custom title bar. The pop-out variant does not draw them, and also does not declare a drag region, so it loses both the buttons and the ability to be moved.

This means the defect is in the pop-out window's rendered title bar component, not in the window creation flags, which are identical between the two.

3. setTitleBarOverlay is failing, and the failure is being swallowed

%APPDATA%\Claude\logs\main.log contains:

2026-08-07 11:00:14 [info] Failed to set title bar overlay, this is probably expected

• 1,310 occurrences in the current main.log alone (2026-08-04 through 2026-08-07)
• also present in main1.log through main4.log, going back to at least 2026-06-22
• logged at [info] with the text "this is probably expected", which is why it has gone unnoticed

It correlates directly with pop-out lifecycle. The immediately following line is:

2026-08-07 11:00:31 [info] mainView backgroundThrottling disabled (visible popouts: 1, glow: hidden, cu lock: free)

setTitleBarOverlay() only applies to windows created with titleBarStyle: 'hidden' plus a titleBarOverlay config. When it throws, the window ends up with neither OS-drawn nor overlay-drawn caption buttons. Downgrading a chrome-critical failure to [info] ... probably expected hides exactly this class of regression.

Verified workaround

Adding the missing style bit externally repairs the window at runtime and persists:

0x14C70000 -> 0x14CF0000   (WS_SYSMENU restored)

Confirmed working:

• ShowWindow(hwnd, SW_MAXIMIZE) maximizes the pop-out correctly, so the window was always maximizable; only the affordance was absent
• SetWindowPos repositions it, which substitutes for the broken drag
• after SetWindowLong + SetWindowPos(..., SWP_FRAMECHANGED), the system menu is present again

Each newly opened pop-out is created without the bit, so the repair has to be reapplied per window.

Important limitation: restoring WS_SYSMENU does not bring back a visible title bar. The app strips its own non-client area, so the caption stays invisible regardless of style bits. Only an app-side fix restores the title bar and the drag region.

Suggested fix

1. Include WS_SYSMENU in the window styles for all windows that declare WS_MINIMIZEBOX / WS_MAXIMIZEBOX.
2. Make the pop-out window render the same title bar component as the main window, including its drag region (-webkit-app-region: drag).
3. Stop logging setTitleBarOverlay failure at [info] as "probably expected". If the overlay is the only source of window controls, its failure is a hard error and should surface.