Peek the collapsed sidebar by resting the pointer on the left edge

[maxwellyoung]

Area
apps/web

Problem or use case
I keep the left sidebar collapsed to give the chat more room. Then every time I want to glance at another thread or jump to one, it's ⌘B, click, ⌘B again, and each toggle reflows the whole main pane twice.

Proposed behavior
An off-by-default setting under Appearance ("Reveal sidebar on hover"). With it on and the sidebar collapsed:

• Resting a mouse pointer on the left window edge for about 110ms slides the sidebar out over the content. The layout doesn't change, so the chat never reflows.
• Moving the pointer off the panel slides it back.
• The sidebar's own menus and popovers, and right-click menus opened on it, keep it open while they're showing. Menus elsewhere in the app don't.
• Touch and pen never trigger it.
• ⌘B still opens the sidebar for real, including mid-peek, and the panel stays where it is instead of replaying the slide.

It's the same idea as the collapsed sidebar in Arc and Notion.

Scope I'd like a yes or no on

1. Off by default, left sidebar only, desktop pointer only.
2. Motion: it slides on its own timing (200ms in, 150ms out, using the drawer curve the toolbar already uses) rather than the panel animation setting. That setting defaults to 0ms, and a whole panel snapping over the content reads as a glitch. With reduced motion it fades in place. Happy to tie it to the panel animation setting instead if you'd prefer.

Context
I jumped the gun and opened #12064 before asking, which got closed under the prior-approval rule. Fair enough. The implementation is still on that branch, now with the slide added after feedback on the PR that it felt unpolished without one.

Recording with real pointer movement: peek-animated.mp4

If the direction and scope look right, I'll link this from the PR and ask for it to be reopened. If you'd rather it work differently, I'll rework it to match.

[piyushpradhan]

I’m working on the same thread-switching use case and have a separate implementation on my fork. I’d like to add concrete evidence here and request direction/scope approval before opening an upstream PR.

The proposed scope is:

• Web and desktop, left sidebar only, off by default under Settings → General → Floating sidebar.
• Hover near the left edge or sidebar toggle temporarily reveals an overlay without resizing the chat. Thread selection or pointer exit dismisses it, with hover intent and a forgiving boundary. Touch and pen do not trigger it.
• Clicking the toggle, or using the existing sidebar shortcut, pins the ordinary full-height docked sidebar until another toggle closes it. Floating spacing and rounded corners apply only to the hover preview.
• Preview motion follows Appearance → Panel animations, including 0 ms and the system reduced motion preference. This is the alternative timing approach mentioned in the original proposal.
• The desktop titlebar and outer resize border remain reserved. Narrow windows retain the existing sheet; native mobile navigation is unchanged.

Evidence

Watch the screen recording · Before/after screenshots and verification details

The recording shows selecting a thread from a hover preview, pinning the standard sidebar and moving away while it stays open, then changing the animation duration to 400 ms and 0 ms from the initial 200 ms. Reduced motion and narrow-window behavior were also checked. The focused hook/sidebar/motion tests (15 tests), contract settings tests (166 tests), and web/contracts typechecks passed.

The recording uses the development web UI on macOS against isolated stopped-thread data. T3’s built-in recorder timed out twice, so a separate Chromium recorder captured the actual UI interaction. Native Electron traffic-light rendering is not shown or claimed as verified by this recording. Sidebar menu/popover retention has not been verified for this separate implementation.

Implementation branch, based directly on upstream main at 701fc83169611473139c441bc27d5ded9612dc8d.

Would maintainers approve this direction and scope, or prefer changes before a focused PR? This follows the approval request in #12064; the discussion and evidence alone are not being treated as approval.

Drafted and implemented with GPT-6.1-sol / Codex in T3 Code, on behalf of @piyushpradhan.

[AndKenneth]

Was just thinking about this and my search led me here.

In my opinion if this is was to be implemented there's no reason for it to be behind an option. The flyout -> pinned transition is a well understood UI pattern that's not very disruptive if you accidently discover it, and extra options add settings bloat. The only optimisation to keep it less disruptive is maybe to only have the actual expand button be the UI trigger rather than just the edge of the screen.

Overall very much in favour of something like this!

[diegojohnsonl]

+1, with one more use case and a working implementation, in case it helps you decide on scope.

Use case: with the browser or diff panel open on the right, I collapse the sidebar to give that panel room. Switching threads then means opening the sidebar, which squeezes both panes, and closing it again. Peeking keeps the wide right panel and still gets me to the thread list.

sidebar-peek.mp4

sidebar-peek-right-panel.mp4

What I built (the smallest version I could get to feel right):

• Desktop mouse only, left sidebar only, only while it's collapsed.
• Resting on an 8px strip at the left window edge slides the sidebar out as an inset card over the chat. Nothing reflows.
• Moving past the card's right edge slides it back after 200ms. Menus opened from the sidebar keep it out.
• Slides for 200ms, with no motion under reduced motion. It never repaints while idle.
• The collapsed sidebar stays inert from fix(web): remove collapsed sidebar controls from keyboard navigation #18849 except while the card is out, so keyboard navigation is unchanged.
• No setting, per @AndKenneth's point above. Happy to put it behind an off-by-default setting instead if you'd rather.

It's +93/−3 across ui/sidebar.tsx (which already owns offcanvas collapse and inert) and a new ui/sidebarPeek.ts hook: main...d3labs-dev:t3code:feat/sidebar-edge-peek

I'd like a yes or no on that scope before opening a PR. If it's a yes, I'll open it against main with before/after evidence, or hand it to @maxwellyoung or @piyushpradhan if one of them would rather land theirs.

Implemented with Claude Opus 5.5 in Claude Code (T3 Code).

[maximedupre]

Need this 😭