[BUG] Desktop (Windows 10): window stuck maximized for two days, Restore button and Win+Down do nothing; native ShowWindow(SW_RESTORE) fixes it

Status Open
Maintainer reply None cached
Activity 1 comment · opened Oct 11, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Environment

  • Claude Desktop 2.31226.1.0 (MSIX, Claude_pzs8sxrjxfjjc)
  • Windows 10 Pro for Workstations 22H2, build 19045
  • Single monitor 2560x1440, 100% DPI, NVIDIA Quadro P2000, driver 31.0.15.5309

Since 2026-10-09 the main window stayed maximized and could not be unmaximized. The title-bar Restore button shows its tooltip and accepts the click, but nothing happens. Win+Down, Alt+Space > Restore, double-clicking the title bar and dragging the title bar also had no effect. This persisted for two days.

From the OS side the window looked like a normal maximized window: IsZoomed(hwnd) = true, GetWindowRect = (-8, -8, 2568, 1408).

Calling ShowWindow(hwnd, SW_RESTORE) and then MoveWindow(hwnd, 120, 60, 1500, 950) from PowerShell restored it instantly (IsZoomed = false, rect 120, 60, 1620, 1010). The app then rewrote window-state.json with sane values (see logs field). The previous content of window-state.json was overwritten by that, so I cannot quote it. My guess is that the stored normal bounds were invalid, so every restore snapped straight back to maximized.

Steps to reproduce: not deterministic. Observed once, after the app had been running for several days. No monitor or DPI change on this machine.

Workaround for others: PowerShell with user32 ShowWindow/MoveWindow via Add-Type. Find the process named Claude with a MainWindowHandle, call ShowWindow(h, 9) then MoveWindow(h, 120, 60, 1500, 950, true). Sessions are not affected.

What Should Happen?

The app's own Restore button and the OS shortcuts (Win+Down, Alt+Space > Restore, title-bar double-click) should unmaximize the window.

Error Messages/Logs

Before the fix (Win32 view of the Claude main window):
PID 15420 title="Claude" zoomed=True rect=-8,-8,2568,1408

After ShowWindow(h, 9) + MoveWindow(h, 120, 60, 1500, 950, true):
zoomed=False rect=120,60,1620,1010

window-state.json as rewritten by the app right after the fix (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\window-state.json):
{
  "x": 128,
  "y": 60,
  "width": 1484,
  "height": 942,
  "isMaximized": false,
  "isFullScreen": false,
  "displayBounds": { "x": 0, "y": 0, "width": 2560, "height": 1440 }
}

Steps to Reproduce

Not deterministic. Observed once, after the app had been running for several days with the window maximized. No monitor or DPI change on this machine. Once in that state, none of these unmaximize it: Restore button, Win+Down, Alt+Space > Restore, double-click on the title bar, dragging the title bar. ShowWindow(hwnd, SW_RESTORE) from outside the app does.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 2.31226.1.0 (Windows MSIX build; bundled Claude Code, claude --version not available in a plain shell)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Desktop app only, not the CLI. Single user, single monitor, no dock/undock. If it happens again I will save the window-state.json before touching anything and attach it here.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗