You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Middle-click closing a right panel tab also pastes the primary selection into the composer on Linux #15939
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
On Linux, select some text anywhere so it goes into the primary selection.
Open two or more right panel tabs, such as PR, browser, or Files.
Click into the composer so it has focus.
Without clicking anywhere else, middle-click one of the right panel tabs to close it.
Expected behavior
The tab closes and nothing is pasted into the composer.
Actual behavior
The tab closes, and the primary selection is also pasted into the composer.
This only happens when the composer has focus right before the middle-click. If I first click on an empty area so the composer loses focus, the middle-click only closes the tab. Middle-clicking a tab doesn't move focus, so the paste lands in whatever editable still has it.
This comes up all the time in my daily workflow: I switch back and forth between the composer and the right panel tabs (PR, browser, Files), so the composer almost always has focus when I go to close a tab.
Likely cause:RightPanelTabs.tsx handles middle-click close (added in #3161). It calls preventDefault() on the middle mousedown and in onAuxClick, but never on the middle mouseup. Chromium pastes the primary selection on Linux at mouseup time, before auxclick fires, so the preventDefault() in handleTabAuxClick runs too late to stop it.
The terminal already handles this: surface.ts cancels the middle mouseup on platforms where isMiddleClickPastePlatform() is true (#11018). The tab handler could add a matching onMouseUp that calls preventDefault() when event.button === 1.
Related:#15531 has the same root cause in the chat timeline. A shared fix, such as a document-level capture mouseup guard for middle-clicks that don't land in an editable, would cover both.
Impact
Minor bug or occasional failure
Version or commit
v0.0.46-nightly.20261005.2667
Environment
Linux (Omarchy / Hyprland, Wayland), T3 Code desktop v0.0.46-nightly.20261005.2667
Workaround
Click on an empty area first so the composer loses focus, or close tabs with the × button instead of a middle-click.
Note
This issue was generated by Claude Opus 5.5 (high effort).
Before submitting
Area
apps/web
Steps to reproduce
Expected behavior
The tab closes and nothing is pasted into the composer.
Actual behavior
The tab closes, and the primary selection is also pasted into the composer.
This only happens when the composer has focus right before the middle-click. If I first click on an empty area so the composer loses focus, the middle-click only closes the tab. Middle-clicking a tab doesn't move focus, so the paste lands in whatever editable still has it.
This comes up all the time in my daily workflow: I switch back and forth between the composer and the right panel tabs (PR, browser, Files), so the composer almost always has focus when I go to close a tab.
Likely cause:
RightPanelTabs.tsxhandles middle-click close (added in #3161). It callspreventDefault()on the middlemousedownand inonAuxClick, but never on the middlemouseup. Chromium pastes the primary selection on Linux at mouseup time, beforeauxclickfires, so thepreventDefault()inhandleTabAuxClickruns too late to stop it.The terminal already handles this:
surface.tscancels the middlemouseupon platforms whereisMiddleClickPastePlatform()is true (#11018). The tab handler could add a matchingonMouseUpthat callspreventDefault()whenevent.button === 1.Related: #15531 has the same root cause in the chat timeline. A shared fix, such as a document-level capture
mouseupguard for middle-clicks that don't land in an editable, would cover both.Impact
Minor bug or occasional failure
Version or commit
v0.0.46-nightly.20261005.2667
Environment
Linux (Omarchy / Hyprland, Wayland), T3 Code desktop v0.0.46-nightly.20261005.2667
Workaround
Click on an empty area first so the composer loses focus, or close tabs with the × button instead of a middle-click.
Note
This issue was generated by Claude Opus 5.5 (high effort).