[teamleaderleo]

Leo, on the nightly: moving the pointer up and to the left out of a sidebar row, it crossed the gap and the rounded corner of the row above. That row took the hover and showed its "..." and close buttons in his way.

A workspace or tab row in the sidebar now takes the hover only inside its pill: its frame inset by Metrics.space1 top and bottom, with corners rounded Metrics.space1 further in than the drawn ones. The gap between rows, the corners and the margin beside a row never hand the hover (or the workspace hover card) to a new row. The row already hovered keeps it across the gap up to its neighbor's pill, so a sweep down or up the list still never flickers (#20315). Clicks still split the gap between the two rows, as before. Headers, empty sections and blocks keep their whole tile.

• SidebarLayout.hoverRow(at:current:frame:cornerRadius:inset:) is the one rule; SidebarListView.updateHover and the hover card's hoverCardWorkspace(at:) both use it.

Changelog

Fixed: The sidebar's gaps and rounded row corners no longer light the row above and put its buttons under the pointer.

Testing

Red then green, on the fleet (cmux-ci run --class light --script scripts/ci/package-test-lane.sh --arg=suite --arg=Packages/macOS/CmuxNext --arg=SidebarRowHoverInsetTests,SidebarRowHoverGapTests):

• Red at 6d0e296 (test only): RED_RESULT
• Green at 6f74de6: GREEN_RESULT

SidebarRowHoverInsetTests drives the real SidebarListView.updateHover in a window: the gap with nothing hovered hovers nothing; the row above's bottom-left corner doesn't take the hover from the row below; the margin beside a row doesn't hover it; a sweep up the list hovers each row once with no drop. SidebarRowHoverGapTests (the down sweep) now starts from the first row's middle, since a row's pill starts inside its frame.

Observed / Not run

Observed: the fleet runs above. Not run: the full CmuxNext suite (PRs here skip it).

Proof

PROOF_PENDING

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes the cmux NEXT sidebar hover so workspace and tab rows take the hover only inside their rounded pill, not in the gap, corners, or the margin beside them. Moving the pointer up and left out of a row no longer lights the row above and puts its buttons in the way.

• The hovered row keeps the hover across the gap up to its neighbor's pill, so sweeping up or down the list never flickers (CmuxNext: sidebar rows tile so hover moves row to row with no flicker #20315).
• Clicks, the context menu, and middle-clicks act on the hovered row when one is hovered, so they never land on the row above; with nothing hovered, clicks still split the gap between rows.
• Headers, empty sections, and blocks keep hovering over their whole tile, and the hover card follows the same row rule.
• SidebarLayout.hoverRow is the single rule behind the list's hover, the hover card's target, and click targeting, with pill geometry covered by SidebarRowHoverInsetTests.

^{Written for commit a373d68. Summary will update on new commits.}

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review a373d68: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr22294 -f ref=fix/next-vtab-hover-inset -f platform=macos -f backend_mode=local

Not verified: macOS jobs did not run: compile and app tests were skipped on a373d68c85; ci-status is green without them.

CI passes on a373d68c85 (run 39501944308 attempt 1).
macOS jobs did not run: compile and app tests were skipped: Fast static checks skipped (the macos job needs both to succeed). Re-run CI once they pass, before merging.

Written by scripts/ci/classify_failures.py (ci-failure-attribution.yml); signatures are its SIGNATURES table. A machine verdict is the runner's fault, not this PR's; yours means the failing file is one this PR changes, also red on main that main's latest full suite fails the same way, seen on other PRs that it failed on another pull request's run lately.

web and size checks: green

Tour of a373d68c85 (run): no media. The tour job failed before the tour ran (build or setup); the run log has the output. Both apps run cmux-tui from c0d6006 (tree 62ff45b4cc39): the merge base's own tree db9cbc89acb4 was not published yet.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge, with the previously reported near-edge hover flicker remaining as a non-blocking issue.

Findings

1.  Hover drops near row edges ▶

Summary

Sidebar workspace and tab rows now take hover only inside a smaller rounded pill.

• Workspace and tab rows only hover inside their rounded pills.

Review was based on source inspection. Native AppKit tests and visual capture were not run in this Linux environment.

_{Reviews (7) · Last reviewed commit: "Merge remote-tracking branch 'origin/fea..." · Reviewed by Greptile}

[greptile-apps]

Hover drops near row edges

The current row stops keeping hover before the next rounded pill begins near either side. During a downward sweep at frame.minX + 1, reaching the next row's minY + inset fails both checks: the pointer is outside its rounded corner, but the previous row's hold has already ended. The highlight and buttons disappear until the pointer enters the curve.

Keep the current row hovered through the neighbor's rounded corner without giving hover to that neighbor early. Add near-edge sweeps in both directions; the new sweep test only checks the horizontal center.

[teamleaderleo]

Bead cx-q8nc7 created for this PR by the cmux coordinator.

[teamleaderleo]

Correctness review (subagent, head a31588aef117caed8d16cdfa6d9da7e1c67c6e54, base eb82f532d25; agent: leoli-63 lane, Claude). No blocking findings. Resolutions are in 0c762afe2f9b84d708c64d424c8cfcc1da971fcb.

1. Hover and click could target different rows. In a band about 3pt tall (the bottom 2pt of row A plus the top of the gap), row B kept the hover while a click acted on A. Fixed: SidebarListView.clickHit(at:) = hoverHit(at:) ?? displayed.row(at:), used by mouseDown, the mouseUp check, both middle-click sites and the context-menu lookups. Test: aClickActsOnTheHoveredRowNotTheTileUnderThePointer (hover B, click at A.maxY-1, B is selected).
2. The pill's corner maths had no direct test. Fixed: thePillRoundsItsCornersInsideTheInset, aRadiusPastHalfThePillsHeightClampsToACapsule, and a no-hover list probe at (frameAbove.minX+1, frameAbove.maxY-inset-1) returning nil.
3. (Low) Comments implied a drawn inset. Fixed: they now say the hover pill is a hit shape inside the drawn fill; the inset stays (Leo wants the hover region to come in from the drawn corners).
4. (Low) Coverage of grouped rows, .tab rows, the first row's top edge. Partly fixed: added grouped-row gutter and first-row top-edge tests. .tab rows share the same hasHoverPill path and frame(for:) branch as grouped workspaces; no separate test.

Red/green on the fleet (cmux-ci, package-test-lane): red probe 108944bc (a31588a + new tests) and green at 0c762afe; results to follow. A re-review of the new head runs before merge.

[teamleaderleo]

Re-review (subagent, head 0c762afe2f9b84d708c64d424c8cfcc1da971fcb, base eb82f532d25; agent: leoli-63 lane, Claude): pass. Nothing blocks merge, and all four earlier findings are fixed.

Low, kept on purpose: a double-click just below a hovered last row now renames that row instead of creating a workspace in the empty space. This follows the same rule as the fix, that a click acts on the lit row. Once the pointer leaves the row's hover band, a double-click creates a workspace as before.

[teamleaderleo]

Orphaned: no activity for 14 h, and no lane holds a lease on it. The orphan sweep could not merge feat-cmux-next in: conflicts in Packages/macOS/CmuxNext/Sources/CmuxNextSidebar/Views/SidebarListView+ContextMenu.swift. Listed for a lane to resolve.

[teamleaderleo]

cmux-next guards / defaults-snapshot is red on 19 of 19 fresh feat-cmux-next PR heads in the last 2:00:00, so it is most likely a base red, not this PR's. The base-reds lane has it; a base merge picks up the fix once it lands.

[github-actions]

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.3950883020001 (3cc9733dfc)
• cmux NEXT nightly 1.0.0-nightly.3950982952501 (d5829ffea0)