[Bug]: Sidebar toggle overlaps macOS window controls after zooming in

[coygeek]

Before submitting

• I searched existing issues and did not find a duplicate matching this sidebar-open state.
• I included enough detail to reproduce or investigate the problem.

Summary

After repeatedly zooming in with Command + until the main sidebar is hidden by default in T3 Code on macOS, the “Toggle main sidebar” control appears in a floating rounded outline beneath the red and yellow window controls when the main sidebar is open. In the supplied closed-sidebar screenshot, the toggle is positioned separately to the right of the red, yellow, and green controls. The open-sidebar state causes the sidebar toggle and native window controls to visually overlap.

Steps to reproduce

1. Open a conversation in the T3 Code desktop app on macOS.
2. Press Command + several times to zoom in until the main sidebar is no longer visible by default. Reaching this zoomed layout is a required precondition reported by the user.
3. With the sidebar closed, observe the “Toggle main sidebar” control positioned to the right of the native red, yellow, and green window controls.
4. Click “Toggle main sidebar” to open the sidebar while keeping the same zoom level.
5. Observe the toggle icon and its surrounding rounded outline overlapping the native window controls at the top left.

The zoom prerequisite is user-reported and the two resulting sidebar states are supported by screenshots. These steps have not been independently replayed. The exact zoom percentage, number of Command + presses, window dimensions, and reproduction frequency are not recorded; the observable setup criterion is that zooming causes the sidebar to be hidden by default.

Expected behavior

The main sidebar toggle remains visibly distinct from the macOS close, minimize, and zoom controls in both sidebar states, including after zooming enough to hide the sidebar by default. Its icon, surrounding outline, and interactive area should not occupy the native window-control area.

Actual behavior

With the sidebar open, the toggle icon and its rounded outline occupy the same top-left region as the red and yellow window controls. The controls are drawn over the toggle, making it look detached from its normal position. With the sidebar closed, the toggle is separately positioned to the right of all three window controls.

Area

apps/desktop — T3 Code desktop window chrome and the main sidebar toggle on macOS.

Runtime or environment

• Platform: macOS desktop application; exact OS version at capture time is unknown.
• Locally installed product: T3 Code (Nightly), version and build 0.0.41-nightly.20260916.1795, read from the installed application metadata while preparing this report.
• The exact build used for the screenshots has not been independently confirmed; the installed version above is context, not a confirmed affected-version range.
• Required UI condition: repeated Command + zoom-in until the main sidebar is hidden by default; exact zoom percentage and window dimensions are not recorded.
• The supplied images show a dark appearance. Dependence on appearance or display scale has not been established.

Evidence

The following crops are taken from the two user-supplied screenshots at their original pixel scale. They preserve the relevant controls while excluding project identifiers, conversation titles, and conversation text. No identifying metadata is intentionally retained.

Sidebar closed: toggle positioned separately to the right of the window controls.

Sidebar open: toggle and rounded outline overlap the red and yellow window controls.

Impact

Cosmetic issue.

The overlap obscures the sidebar toggle and makes the top-left controls visually ambiguous. The screenshots establish a layout defect; they do not establish whether clicks are intercepted, any control becomes unusable, or unintended window actions occur.

Additional context

Regression closure: zoom in with Command + until the main sidebar is hidden by default, then open and close it without changing zoom. The sidebar toggle must remain usable and opening and closing the main sidebar must leave the toggle icon and its outline separate from the native window controls. Verify both sidebar states visually and confirm that the sidebar toggle and native controls retain distinct, usable click targets. The report remains failing while the overlap shown in the open-sidebar evidence persists.

No implementation cause has been verified. The report covers one visual layout defect and has no known issue dependencies or supported security impact.

Related historical report: #1577 (closed) describes header overlap with the sidebar collapsed after resizing in version 0.0.15. This report specifically concerns the sidebar toggle overlapping native controls when the sidebar is opened after zooming in until it is hidden by default; a shared cause has not been established.

[juliusmarminge]

Triage

Confirmed on current main (6ee03240b) and on shipping 0.0.42 / the reported 0.0.41-nightly.20260916.1795. All three already contain #11906. This is a real macOS desktop layout bug, not a wash of #11906 / #1577 / #420. The two crops are two different buttons.

Command+ zooms Chromium. Native traffic lights stay 14pt. After enough zoom the CSS viewport falls under md (768px) and the left sidebar becomes the mobile Sheet, closed by default. That is the “sidebar hidden by default” precondition. Default window is 1100px (DEFAULT_MAIN_WINDOW_SIZE); about five +0.5 zoom steps (1.2^2.5 ≈ 1.58 → ~698 CSS px) get there. At minWidth 840, one step is enough.

Closed: the user clicks the fixed SidebarControl. It sits at left: var(--workspace-controls-left). On macOS that token is --desktop-window-controls-inset = 90 / zoomFactor CSS px, i.e. a constant 90 native points. That is why the closed crop is clean — toggle to the right of red / yellow / green.

Open: the Sheet portals at z-50 and covers that control. The button in the open crop is SidebarChromeHeader’s md:hidden SidebarTrigger — relative in a header with px-3 (12 CSS px). Phone inset. It does not read --workspace-controls-left. At zoom 1.58 that is ~19 native points, on top of the red button (x: 16). The 1.75rem chrome scales with zoom and lands on red + yellow; green stays outside. That is the open crop.

Cosmetic only. The screenshots do not prove click-through onto close / minimize; they do prove the outline occupies the native-control cluster.

What the code does

Two triggers, one layout token that only one of them uses.

Floating control (AppSidebarLayout.tsx), always mounted, uses left-[var(--workspace-controls-left)]. macOS desktop (not fullscreen) sets that to --desktop-window-controls-inset. Preload keeps the reserve in native points (the #11906 fix): 90 / webFrame.getZoomFactor() CSS px, synced on DOMContentLoaded and resize only.

zoomMain recenters the native buttons on Y and leaves X at 16.

useIsMobile() is max-md. Under that, Sidebar renders the left Sheet (z-50). openMobile defaults to false.

The open-state button is in SidebarChrome.tsx (md:hidden SidebarTrigger inside SidebarHeader with px-3). Brand uses ml-[var(--workspace-titlebar-content-left)] on md+ only, so it never runs here. Header px-3 is the only left inset the open-state toggle gets.

#11906 fixed (1) brand cap-height, (2) traffic-light Y on zoom / fullscreen, (3) the floating control’s X reserve. Its validation was “collapse/reopen at reduced zoom,” not Command+ until the Sheet path. The md:hidden trigger was not part of that change. Still true on main.

Related, not duplicates

Issue / PR	Why it does not close this
Merged #11906	Same chrome, opposite zoom / opposite control. Shipped in this nightly. Closed-state crop is the post-#11906 floating button. Open-state crop is the Sheet header trigger #11906 never inset.
Closed #1577 / merged #3497	0.0.15: header text under traffic lights after resize/zoom collapsed the sidebar. Not this open-Sheet overlap.
Closed #420 / merged #586	Collapsed-sidebar clearance and brand alignment on md+. Desktop header, not the md:hidden trigger.
Merged #4019	Fullscreen spacing. This report is windowed.
Closed #11686	Compact-rail vs traffic lights. Different mode.
Open #8893	Diff-toolbar tooltip vs native controls. Collision padding, not this button.

No open or merged PR insets SidebarChromeHeader’s md:hidden trigger, or lifts SidebarControl above the Sheet.

Suggested fix

Keep this as a small layout bugfix on the zoom-to-Sheet header path. Do not invent a second 90px constant.

1. Give the md:hidden trigger the same left edge as the floating control. --workspace-controls-left is already 90 native points on macOS, default 0.75rem elsewhere, and unset in fullscreen. Cancel the header px-3 with something like ml-[calc(var(--workspace-controls-left)-0.75rem)] when isElectron. On Windows/Linux the calc is ~0. On macOS the open-state icon lines up with the closed-state one. Settings and legacy share this header.
2. Do not hide the in-header trigger and only raise SidebarControl to z-60 unless you also hide the duplicate. The Sheet is meant to own the open-state control on the mobile path. Insetting that control is the smaller change. Mobile web (isElectron === false) stays at px-3.
3. Optional hardening: call the preload inset sync on zoom, not only resize / DOMContentLoaded, so the token cannot go stale if Chromium skips a resize. Not the open-state bug; the closed crop is already correct.
4. Tests: render SidebarChromeHeader under the mobile sidebar state with --workspace-controls-left: 90px and isElectron and assert the trigger gets the extra margin. With isElectron={false}, assert no extra ml-.
5. Visual close: Command+ until the sidebar hides, open it, confirm the outline sits to the right of green, same as the closed crop. Repeat at default zoom, after Cmd+0, and in fullscreen (no extra inset).

Workaround

Cmd+0 (or View → Actual Size) so CSS width stays ≥ 768px. The desktop sidebar returns and this header trigger stays md:hidden. No in-app toggle for “keep desktop sidebar while zoomed.”

Classification: bug · accepted · cosmetic (macOS desktop; zoom-to-max-md Sheet header trigger ignores traffic-light inset)
Labels: add bug, accepted, via-triage
Discord tags: macOS, ui