fix(desktop): preserve main window bounds#3851

Close persist is not awaited

Medium Severity

On close, bounds are written with a fire-and-forget runPromise and nothing in the quit path waits for that disk write. A clean quit right after a move/resize can exit before setMainWindowBounds finishes, so the last layout never lands on disk.

^{Reviewed by Cursor Bugbot for commit 271e8bb40ca5c3bdab79f52cb767212835564b98. Configure here.}

Minimized windows save invalid bounds

Medium Severity

The readPersistableBounds function doesn't check if a window is minimized. On Windows, getBounds returns off-screen coordinates for minimized windows, which are then persisted. This results in the app losing the user's window layout and reverting to default sizing on subsequent launches.

^{Reviewed by Cursor Bugbot for commit 271e8bb40ca5c3bdab79f52cb767212835564b98. Configure here.}

🟡 Medium window/DesktopWindow.ts:386

When the user moves or resizes the window and then quits while the window is minimized, the new bounds are silently lost and the next launch restores stale geometry. flushBoundsPersist cancels the debounced save via clearBoundsPersist before calling persistCurrentBounds, but readPersistableBounds returns null whenever window.isMinimized() is true, so the replacement write is skipped and the pending debounced save is discarded with no write taking its place. Consider reading the bounds before cancelling the pending fiber, or falling back to window.getNormalBounds() when minimized.

✅ Resolved in b11feec4abf8a69c1dfcf66907963de4e6ff836c

Fullscreen drops pending bounds save

Low Severity

A move or resize only schedules a debounced persist. Entering fullscreen fires another resize, which resets that timer; when it runs, isFullScreen() makes readPersistableBounds return null and nothing is written. Quitting while fullscreen clears the debounce and skips persist the same way, so the last normal bounds from that session never reach settings.

^{Reviewed by Cursor Bugbot for commit c99ac6227dca398ecb1693a2daa24f3a3359533a. Configure here.}

Persist skips bounds schema checks

Medium Severity

readPersistableBounds persists rounded Electron geometry without applying DesktopWindowBoundsSchema, while load rejects non-integers and sizes below the minimum as null. A successful save can therefore be discarded on the next launch, resetting the user’s window layout after sessions where Electron reports slightly undersized or inconsistent bounds (for example with a hidden title bar under DPI scaling).

^{Reviewed by Cursor Bugbot for commit d7de06d7fa2b442b1b824d0c22f3a1b1fd3eb92c. Configure here.}

Fixed in da1f349db2. Rounded Electron bounds now pass through the shared DesktopWindowBounds schema normalization before any write, so invalid geometry is skipped rather than persisted.

Failed restore overwrites saved bounds

Medium Severity

When persisted bounds do not fit any connected display, the window opens with defaults, but close and shutdown still call flushMainWindowBounds. That writes the fallback geometry over the previous saved rectangle, so reconnecting the original display cannot restore the user’s layout even if they never moved the window.

^{Reviewed by Cursor Bugbot for commit d7de06d7fa2b442b1b824d0c22f3a1b1fd3eb92c. Configure here.}

Fixed in da1f349db2. When persisted bounds cannot be restored, the fallback window state is retained as a baseline and close/shutdown skips persistence until the window state actually changes.

Maximized bounds break restore

Medium Severity

When maximized, readPersistableBounds now saves the window's maximized dimensions instead of its normal bounds. Since the maximize state isn't persisted, relaunching opens a non-maximized window at the full display size, losing the user's previous normal layout. On Windows, these maximized bounds can also be invalid and discarded.

^{Reviewed by Cursor Bugbot for commit 261b057455f844c539d0430acbb258a9aaa09349. Configure here.}

Fixed in da1f349db2. Maximized windows now persist their normal bounds together with a maximized-state flag, and startup restores the native maximized state.

🟡 Medium components/threadSidebarWidth.ts:5

resolveInitialThreadSidebarWidth clamps the persisted width to THREAD_SIDEBAR_MIN_WIDTH but applies no upper bound, so a width saved on a large display is restored verbatim after the window is reopened much smaller. This sets --sidebar-width wider than the available layout width, pushing the main content and resize rail off-screen. The drag path enforces an upper bound via shouldAcceptWidth / THREAD_MAIN_CONTENT_MIN_WIDTH, but startup restoration bypasses that check. Consider clamping the restored value against the current layout width (or passing the available width into resolveInitialThreadSidebarWidth) so the initial width respects the same upper bound as the drag path.

Fixed in f8f445d78f. Initial restoration and the generic hydration path now share a viewport-derived maximum that reserves the same 640px minimum for main content.

Unchecked storage read still crashes

Medium Severity

readInitialThreadSidebarWidth catches localStorage failures and falls back to the default width, but the parallel useLayoutEffect hydration still calls getLocalStorageItem unguarded. A corrupt chat_thread_sidebar_width value still throws during layout, so the new fallback never reaches the screen and the app shell can crash before paint.

^{Reviewed by Cursor Bugbot for commit 24143ef3c3284ef5b3eae6b7b939f39d79f179de. Configure here.}

Fixed in f8f445d78f. The layout-effect hydration now catches storage read/decode errors and leaves the already-safe initial fallback width in place.

Stale controlled sidebar width

Medium Severity

initialSidebarWidth is captured once and passed every render as a controlled --sidebar-width on SidebarProvider, but resize only updates the DOM via setProperty and localStorage. That leaves React props stuck at the mount-time width, so a later AppSidebarLayout re-render can reassert the stale value over the user's resized width.

^{Reviewed by Cursor Bugbot for commit 24143ef3c3284ef5b3eae6b7b939f39d79f179de. Configure here.}

Fixed in f8f445d78f. Sidebar width is now React state and the resizable onResize callback synchronizes it after a drag, so later layout rerenders preserve the latest width.

Maximize shows window before reveal

High Severity

When restoring a maximized window, window.maximize() is called while the window is hidden (show: false). On Windows and macOS, this implicitly shows the window, bypassing the ready-to-show event. This can cause a flash of unrendered content or a blank window, preventing splash screen dismissal.

^{Reviewed by Cursor Bugbot for commit da1f349db280ac408bc36011a73f856dc58b1e54. Configure here.}

Fixed in c28dfce54a. Restored maximize now runs from the existing first-reveal trigger after ready-to-show (or the Linux load fallback), immediately before the normal reveal/splash-dismiss path. The test asserts maximize is not called before ready-to-show.

Maximized fallback races persistence gate

Medium Severity

fallbackWindowMaximized is taken from persisted settings while the deferred maximize() runs only later on reveal, after move/resize/maximize listeners are already registered. Until that restore finishes, live isMaximized() disagrees with the baseline, so scheduleBoundsPersist can treat startup restore events as a user change and overwrite unrestorable saved bounds.

^{Reviewed by Cursor Bugbot for commit c28dfce54a780df715eceb23e1f6abba081e68c7. Configure here.}

Stale sidebar max width

Medium Severity

The sidebar's maxWidth is calculated once using window.innerWidth but doesn't update when the window resizes. This causes the sidebar to remain capped at an outdated maximum width if the browser window grows, preventing it from being expanded further.

^{Reviewed by Cursor Bugbot for commit c28dfce54a780df715eceb23e1f6abba081e68c7. Configure here.}