[BUG] Claude Desktop (Windows) does not restore window positions/sizes after lock/unlock

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?

On Windows, when the workstation is locked and then unlocked, all open Claude Desktop windows are moved and/or resized and do not return to their prior positions — every window has to be manually re-arranged.

This is a regression: it did not happen roughly 2–5 desktop-app versions ago. Chrome and Obsidian on the same machine are unaffected — their windows stay put across the identical lock/unlock — so the hardware/OS is capable of surviving the event; the difference is how Claude handles it. The only other app that misbehaves the same way is Power BI Desktop (a long-standing, well-known Windows complaint of this class).

Likely mechanism (with on-disk evidence): on lock, the single 4K DisplayPort monitor drops its link (sleep / signal loss). Windows/NVIDIA momentarily renegotiates to a smaller fallback resolution and fires a display-change (WM_DISPLAYCHANGE) event. Chrome/Obsidian restore their per-window bounds when the display returns to 4K; Claude appears to clamp windows to the transient smaller work area and not restore them on unlock.

Claude persists window geometry in %APPDATA%\Claude\window-state.json (Electron electron-window-state). Observed contents on the affected machine: {"width":1084,"height":1031,"x":1150,"y":1078,"displayBounds":{"x":0,"y":0,"width":3840,"height":2160},"isMaximized":false,"isFullScreen":false}

Two issues are visible here: (1) only ONE window's state is stored (a single global object) — with multiple windows open there is no per-window geometry to restore, so windows collapse toward one saved position; and (2) it records displayBounds (the standard signal for detecting a display change), yet the window is evidently re-clamped to the shrunken display and never re-expanded when the display returns to 3840x2160.

Requested fix: (1) restore each window's position/size after a display-change / lock-unlock event, matching Chrome/Obsidian; (2) persist per-window geometry keyed by window/session, not a single global window-state.json; (3) treat a transient resolution drop as recoverable — when the display returns to its prior bounds, move windows back rather than leaving them clamped to the transient work area.

Related: #84562 (Windows: Claude Desktop does not persist window size/position between launches) is the same root cause (weak window-state persistence) but a different trigger — #84562 is close-app-then-relaunch resetting to default, whereas this is lock/unlock repositioning of windows that are still running, plus the multi-window collapse and display-change angle. Also #60879 (restore each window's position/screen on Windows, same getBounds pattern) and #23637 (blank/black window on restore, Windows, related restore path).

What Should Happen?

After unlocking the workstation, every Claude Desktop window should return to the exact position and size it had before the lock — the same way Chrome and Obsidian windows do on the identical hardware. A transient resolution drop during lock should be treated as recoverable: when the display returns to its prior bounds, windows should move back rather than staying clamped to the temporary work area.

Error Messages/Logs

Steps to Reproduce

1. On Windows with a single 4K DisplayPort monitor, open several Claude Desktop windows and arrange them on the display.
2. 2. Lock the workstation (Win+L) and leave it locked long enough for the monitor to drop signal / sleep.
3. 3. Unlock the workstation.

Result: the Claude windows have been moved and/or resized and stay wrong. Chrome and Obsidian windows on the same machine are unaffected by the same lock/unlock.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop app 1.32885.1.0 (Windows MSIX package); Claude Code engine 2.1.234

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Hardware / display environment:

• OS: Windows 11 Pro, build 26200
• - Display: single monitor, 3840x2160 (4K), DisplayPort, primary at (0,0)
• - - GPU: NVIDIA Quadro P620, driver 32.0.15.5639 (2024-09-09)
• - - - Multiple Claude Desktop windows open at once (one per project/session)

Note on the "Terminal/Shell" and "Platform" fields above: this bug is about the Claude Desktop application window management on Windows, not a terminal or API-platform behavior; PowerShell / Anthropic API were selected only because the form requires a choice.

Machine-side workaround that helps (but the app should handle this itself): the open-source PersistentWindows tool auto-restores the window layout after unlock. Chrome and Obsidian on the identical hardware already survive the same lock/unlock without any helper, which is why this looks like an app-side regression in how Claude handles the display-change event.