[BUG] Windows: floating/pinned conversation windows cannot be moved or closed with the mouse — no window controls, setTitleBarOverlay always fails

Environment

• App: Claude Desktop for Windows, version 1.25927.0 (auto-updated 2026-08-04; no newer build staged by Squirrel)
• OS: Windows 11 Home 10.0.26200, ARM64
• Display scaling: 100% (so this is not the DPI/hit-testing variant)
• Claude Code desktop backend also installed (2.1.221), running windowless inside the app

What happens

Opening a conversation in a new window (pin/pop-out) creates a floating window that the user effectively cannot manage with the mouse:

1. No window controls. The floating window's top bar renders only the conversation title, a pin icon, and a three-dot menu. There are no minimize / maximize / close buttons (the main window does render app-drawn caption buttons).
2. Cannot drag. Clicking and dragging the top bar does not move the window. This is intermittent at best — moving via keyboard (Alt+Space → Move) worked once, then mouse dragging kept failing.
3. Cannot close with the mouse. With no close button and no reliable drag, the user cannot dismiss or arrange these windows at all without external tools.

Diagnostics already done (Win32-level)

• EnumWindows/GetWindowRect confirm the floating windows are real top-level windows of the claude.exe (AnthropicClaude) process.
• GetWindowLongPtr(GWL_STYLE) shows the floating windows carry the same style as the main window (0x14C70000: WS_CAPTION | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX, no WS_SYSMENU) — so the missing buttons are the app's own chrome not being rendered for these windows, not a Win32 style difference.
• Forcing WS_SYSMENU + SWP_FRAMECHANGED from outside does not make any native frame appear (app suppresses non-client area), but it does restore working Alt+Space / Alt+F4 — suggesting the app creates these windows without a system menu, which also breaks standard keyboard close.
• Programmatic SetWindowPos moves the windows fine — the windows are movable; only the app's drag region / chrome is broken.

App log evidence (%APPDATA%\Claude\logs\main.log)

• Failed to set title bar overlay, this is probably expected — logged continuously, in groups matching the number of open windows: 1,927 occurrences in the log starting 2026-07-16, 2,186 in the log starting 2026-07-24, 166 today alone. The app repeatedly calls setTitleBarOverlay (the Electron API that provides native min/max/close on frameless windows), it always fails on Windows, and the error is swallowed — so no window ever gets native caption controls; the main window survives only because its web-rendered chrome includes buttons, while the claude.ai/epitaxy/... pop-out windows' chrome does not.
• Aggravating case: after a sleep/wake cycle ([event-loop-stall] main process blocked for 276030ms [likely sleep: power_event]), a pop-out window's content failed to load entirely — Failed to load URL: https://claude.ai/epitaxy { errorCode: -105, errorDescription: 'ERR_NAME_NOT_RESOLVED' } — leaving a completely inert frameless window: no chrome, no drag, no close, and no native controls to fall back on because of the overlay failure above.

Expected

Floating conversation windows should be draggable by their title bar with the mouse and should expose close (and ideally minimize/maximize) controls, like the main window.

Impact

Users cannot organize or dismiss popped-out conversations without resorting to external Win32 scripting. Currently worked around locally with a PowerShell tool that tiles/closes the windows via SetWindowPos/WM_CLOSE.

---
Likely related: #68364 — same swallowed Failed to set title bar overlay error on Windows 11, manifesting there as a blank main window on a Store/MSIX install. Both point at the same failing overlay path.