Agentic UI: Keep the native window controls inside the frame on Windows and Linux

[bcotrim]

Related issues

• Fixes STU-2211

How AI was used in this PR

Claude mapped the frame/overlay code paths, implemented the change, and measured the resulting geometry and surface colors in the running UI. I reviewed the diff and the reasoning.

Proposed Changes

• On Windows and Linux the minimize/maximize/close controls sat outside the agentic UI's rounded frame, in a mismatched strip jutting past its top and right edges. The controls are painted by Electron at the window's own bounds, but the frame is inset by 12px, so they could never line up. The frame now goes full-bleed when the window-controls overlay is present — the same shape the classic UI has always had — and the controls land inside the frame's own header.
• Trade-off: Windows and Linux lose the frame's inset/rounded look. Shrinking the controls isn't an option (Electron exposes only colour and height, no width) and wouldn't help anyway, since the overhang comes from the anchoring, not the size. Flushing only the top and right edges would leave a lone 12px bottom inset that reads as a mistake.
• macOS is unaffected — it reserves space separately via trafficLightPosition.

macOS	Windows	Settings	Add Site

Testing Instructions

1. Run Studio on Windows or Linux with the agentic UI.
2. Top-right corner: the controls sit inside the frame's header, on a matching background — not in a strip above and right of it.
3. Check with the preview open and closed, in light and dark, and after maximize/restore.

macOS regression check: the frame keeps its 12px inset and rounded corners, and the traffic lights are unchanged.

One thing worth a close look: with the preview closed in dark mode, the surface behind the controls is rgb(30,30,30) while the overlay paints rgb(36,36,36). Expected to be imperceptible; if it reads as a seam, the fix is per-route setTitleBarOverlay() colours.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 1cb6ac1 vs trunk

app-size

Metric	trunk	1cb6ac1	Diff	Change
App Size (Mac)	1406.34 MB	1406.26 MB	0.08 MB	⚪ 0.0%

site-editor

Metric	trunk	1cb6ac1	Diff	Change
load	1075 ms	1009 ms	66 ms	🟢 -6.1%

site-startup

Metric	trunk	1cb6ac1	Diff	Change
siteCreation	7519 ms	7544 ms	+25 ms	⚪ 0.0%
siteStartup	2870 ms	2868 ms	2 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[shaunandrews]

Can we try to align the menu, +, and window controls so they're all vertically centered together in that top space?

--

Eventually I think we could expose a proper windows and linux toolbar with the menu expose to make better use of the space, and isolate it from the rest of the app.

[bcotrim]

@shaunandrews added the fix and updated the images in the PR description!
Thanks for checking

[katinthehatsite]

It looks good on macOS and I did not see any regressions but I have not tested on Windows or Linux.

I think we could merge once we have another set of eyes to test these platforms