Repository navigation
Description
Summary
On the desktop app's new UI layout with top horizontal session tabs, once enough tabs are open that the tab bar overflows, each tab is compressed down to a ~28px icon-only chip. The tabs become visually unusable and clicking a tab no longer switches to its session — I can click but nothing happens (no accidental closing, no switch). This makes the tab bar unusable the moment it overflows.
This is distinct from the "close button misclick / accidentally closes a tab" complaints (#50196, #52044): here the tab is not being closed, it's just not selecting when clicked.
Environment
- opencode version: 2.2.2 (OpenCode.app / desktop client
ai.opencode.desktop) - OS: macOS 27.2.0 (arm64, Apple Silicon)
- Terminal: N/A (desktop client, not the TUI)
- Shell: /bin/zsh
- Install/channel: Desktop client, latest stable build
- Active plugins: None found in config
Reproduction
- Launch OpenCode Desktop and enable the new UI layout (settings that puts session tabs in the top title-bar tab strip).
- Open / create enough sessions that the top tab bar overflows the window width (roughly 8–10+ tabs).
- The tab bar stops fitting and each remaining tab shrinks to an icon-only chip.
- Click one of the compressed (non-active) tabs to switch to it.
Expected Behavior
Clicking a tab selects/switches to that session. When tabs don't all fit, a browser-like behavior: tabs keep a usable minimum width and the strip scrolls horizontally so every tab stays clickable.
Actual Behavior
- Tabs shrink to ~28px icon-only chips; their titles are hidden (only a 16px project avatar / status dot shows).
- Clicking a compressed tab does not switch to it — the click registers but the active session does not change ("点不动").
- There is no reliable way to reach or select the overflowed tabs: the strip has no horizontal scroll and no wheel-to-scroll-x, so on a standard (non-trackpoint/vertical-scroll) mouse the far tabs can't be reached.
- The close button overlaps the tab's click region (it's centered on very narrow tabs and present-but-transparent on 45–64px tabs), which compounds the "click does nothing useful" feel. (This is a secondary effect, not accidental closing.)
Suspects in the current source (for maintainers)
Working from the dev branch checkout of packages/app:
- Tabs are allowed to shrink to a tiny icon size.
tab-strip.tsx(SessionTabSlot/DraftTabSlot, ~line 75 & 364):class="... w-56 min-w-7 max-w-56 flex-shrink"—min-w-7is 28px, so with overflow each tab collapses to a 28px chip.tab-nav.cssthen hides the title and centers the close button in the@container (44px < width <= 64px)/@container (max-width: 44px)ranges. - No horizontal scrolling of the title-bar strip. The strip is
overflow-x-autowithno-scrollbar(tab-strip.tsx,TitlebarTabStrip), but unlike the side-region strip there is no wheel→scrollLeft handler wired on the title-bar tab strip (cf.runtime/plugin/tab-strip-scroll.ts, which the side panel uses). So an overflowing strip can't be scrolled on a vertical-mouse. - Close button intercepts the click.
tab-nav.css: for<=44pxtabs the close container isdisplay:nonefor inactive tabs but present/centered for the active tab, and for 45–64px it isopacity:0(still hit-testable).tab-nav.tsxnavigates onmousedownof the tab link; when a transparent/centered control overlaps that region, the click doesn't reach the link.
Additional Context
Reproduced on Desktop 2.2.2. Frequency: consistent whenever the top tab bar overflows. Workaround that works: switch to vertical / side tabs (Settings → Appearance → Tabs), or use the "Search sessions" / ⌃⇧⌘T commands, or shrink the tab count.
Related reports (the misclick / close-button framing, not the no-select framing of this one):
- In a view with many projects, it is almost impossible to switch tabs without closing them. #50196 — "In a view with many projects, it is almost impossible to switch tabs without closing them."
- Opencode Desktop's Close button is easily misclicked when trying to switch to another session tab #52044 — "Close button is easily misclicked when trying to switch to another session tab" (closed not_planned; suggested Chrome-like behavior).
- [Bug]: New UI horizontal tab bar unusable on mobile with 4+ sessions — only close button clickable #38974 — same class of symptom on the old UI, closed with v1.
Activity
yushui2022 commentedon Nov 3, 2026
I'll take this on and work on a fix.
Planned approach:
runtime/plugin/tab-strip-scroll.tsused by the side panels).Will target
devand open a PR that references this issue.yushui2022 commentedon Nov 3, 2026
Could a maintainer assign this to @yushui2022? I tried to self-assign, but my account does not have write access to this repository (GitHub requires admin/write to set assignees), so I could only claim it here in the comments. Thanks!
opencodejr commentedon Nov 3, 2026
Thanks for the detailed report, @yushui2022. I couldn't try this here: it happens in the desktop app's top tab strip, and the sandbox I reproduce issues in can't run the desktop app or a browser. A maintainer with the desktop app will need to check it.
From the code, a left-click on a compressed tab is meant to switch sessions as soon as the button is pressed, and the close button is hidden on narrow inactive tabs. So a click that does nothing doesn't look like intended behaviour. Some details that would help whoever picks this up:
The missing horizontal scrolling and the very narrow minimum tab width are already covered by #50196. Related, most likely first:
ryan-noel-2258 commentedon Nov 6, 2026
Looking at this in
tab-nav.tsx— the 45–64px case has the close button atopacity:0but still hit-testable, which is why a click on what looks like the icon actually closes the tab. The narrower case (≤44px) hides the close on inactive tabs, so the "click doesn't switch" there is a separate problem (no horizontal scroll on the strip).Happy to send a narrow PR for just the close-overlap half, Chrome-style: on an inactive tab, clicking the X calls
onNavigateinstead ofonClose. First click activates, second closes. Doesn't touch styling or layout, doesn't change the active-tab behavior, doesn't fix the scroll problem.Any objection to that approach before I write it?