What happens?

The Mac app dashboard window hosts five native AppKit buttons (sidebar toggle, search, new session, back, forward) in an NSTitlebarAccessoryViewController floating over the embedded Control UI WKWebView. This split ownership causes recurring paper cuts:

• Hover/highlight state never matches the web UI's buttons (AppKit accessoryBarAction vs Control UI CSS), so the titlebar cluster looks foreign next to the sidebar chrome it sits on.
• Z-index/stacking is uncoordinated: the native accessory and native drag regions float over web content unconditionally, so web overlays (menus, cards, palette) can render underneath native chrome, and the web side compensates with hardcoded clearance offsets (padding-left: 90px/204px, min-width: 398/512px in ui/src/styles/chat/split-view.css) that drift whenever the native layout changes.
• Toolbar layout is duplicated across two codebases: the accessory width tracks the web sidebar via a nav-state bridge message plus magic numbers (78pt traffic lights, 116/128pt accessory widths), which has already needed several follow-up fixes (fix(macos): host the dashboard sidebar toggle beside back/forward in the titlebar #104380, fix(macos): dashboard titlebar buttons sit too close together #104572, fix(macos): remove duplicate sidebar toggle buttons in the Mac app dashboard #104694, feat(mac): swap dashboard titlebar buttons with sidebar state #105175).

Proposed fix

Render the buttons in the web UI itself. The app keeps the traffic lights, thin top drag strips, and a small bridge (capability flag at document start, history canGoBack/canGoForward state events); the web owns the toolbar row, hover state, and z-index in ordinary CSS. Shipped app builds keep working through the existing openclaw-native-nav compat path.