fix(web): keep remote icon visible on hover - #8132

💭 Checking whether previously flagged issues were resolved, I see the icon now uses "invisible" instead of unmounting, which keeps the box in place and avoids the reflow issue raised earlier. That confirms one prior concern is addressed, so now I want to check the other flagged visibility issue from the earlier run. I want to verify the layout details in the file—whether gap-1 was added to the container and min-w-12 is present.

1. browse_code — apps/web/src/components/LegacySidebar.tsx

💭 I recall the icon previously sat inside the threadMetaClassName span alongside the jumpLabel and time, so I want to check that span's definition and the pre-PR structure around lines 840-880 to confirm the move doesn't break anything.

2. git_tools — 5f1147c:apps/web/src/components/LegacySidebar.tsx

💭 I'm checking whether moving the cloud icon out of the hover-hidden container and adding the gap-1 spacing could cause layout shifts or duplicate visibility issues elsewhere. Previously the cloud icon was nested inside the min-w-12 meta span; now it's a sibling but still within the same container width, so nothing changes structurally. The invisible class on confirm preserves layout without visual bleed, and I'm checking whether the absolutely-positioned archive button might overlap the newly-visible cloud icon during hover, since the archive button sits at right-0.5 relative to the row while the cloud icon occupies the right side of the meta container. I'm working out the exact spacing: that trailing cluster also includes ports icon, worktree indicator, and terminal icon before the timestamp container, with the archive button absolutely positioned 2px from the row's right edge. Estimating the row's horizontal padding, I'm calculating whether the cloud icon and timestamp actually fit within that ~48px container without colliding with the archive button's footprint. Even with jump labels shown, that stays under the 48px container width. Since the archive button and timestamp region only overlap by a tight margin (about 4px), and the timestamp fades on hover anyway, I don't think there's a real collision here — though a wider timestamp label could push things closer to touching. I should still verify the actual padding for SidebarMenuSubButton at small size, and confirm the mobile breakpoint (min-w-24 with pr-6) gives enough room too.

3. git_tools — SidebarMenuSubButton — rejected: repo.url: required parameter is missing or empty;repo: required parameter is missing or empty

4. git_tools — function SidebarMenuSubButton

💭 I'm checking the spacing between the cloud icon and archive button to confirm they clear each other by a few pixels, and verifying the truncate selector doesn't apply since the row uses div children rather than direct spans. I'm also double-checking the flex container classes stay consistent between remote and non-remote cases before considering accessibility for the cloud icon. The invisible state during archive confirmation correctly removes the tooltip trigger from the accessibility tree and disables pointer events, so nothing conflicts there. I'm confirming the mobile layout still works too: the padded meta span pushes content left to avoid the always-visible archive button, and since the cloud icon now sits outside that span, it stays clear of overlap. The bigger realization is that moving the cloud icon out of the pointer-events-none meta group actually fixes a bug — previously its tooltip couldn't have triggered on hover, but now it can, which seems like a genuine improvement rather than a regression. I check that this doesn't interfere with row-level click navigation since clicks still bubble normally, matching how the terminal status indicator behaves. Now I'm looking at whether the items-center alignment changes vertical positioning compared to before. I'm checking that the container's minimum width comfortably fits the icon, gap, and timestamp or jump-label combinations without overflow. Then I realize the archive-confirm chip, positioned absolutely near the right edge, actually overlaps the same area as the cloud icon within the container, which is why it needs to stay invisible rather than hidden when not active. Working through the edge case with a short timestamp like "1m" — the archive button's invisible hit box could overlap the cloud icon's trigger area by about 2px, though the visible glyphs themselves don't touch. Since the button sits later in the DOM and above in z-order, this minor overlap likely doesn't cause a practical issue. I'm checking whether the always-visible cloud icon interferes with the jump-to-label pill when hints appear, but it's positioned in normal flow with proper spacing, so no conflict there. The tooltip logic for the environment label is unchanged and still properly guarded for non-remote threads. Comparing this to the existing project header pattern, I notice the header's environment badge uses an opacity crossfade on hover to swap with the new-thread button. The PR intentionally diverges from that pattern by keeping the thread-row cloud icon visible on hover instead of fading it, which seems like a deliberate product choice rather than a bug worth flagging. I'm also confirming the invisible state only applies during archive confirmation, with no other case where the meta area disappears but the cloud icon should follow suit. One more thing to check is the icon's new DOM position to the left of the timestamp, since it moved outside the meta span. The visual order stays consistent with before, and since it's still a flex item inside the min-width container, the icon doesn't shift when the timestamp fades on hover. So the previously flagged issues look resolved. Now I'm checking whether adding gap-1 to the container introduces any new issue, particularly around how spacing behaves in the non-confirming, non-running branch when the archive-confirm setting is off. Since the archive wrapper and confirm button are both absolutely positioned, they don't contribute to the gap, so it only applies between the cloud icon and meta text — that holds across the running, confirming, and idle states. Using invisible instead of opacity-0 shouldn't cause transition problems since the confirm swap happens instantly anyway, though I note a minor accessibility difference since invisible removes the cloud from the a11y tree while opacity-0 kept it there, which isn't really a regression worth flagging. Let me check if there's a test that checks for the cloud icon's aria-label within the sidebar, so I should search the sidebar tests for a "Remote" aria-label reference.

5. git_tools — Remote|CloudIcon|cloud

💭 No component test exists for this row, but that's fine since it's a tiny visual-only migration with no tests required. I'm confirming the current version resolves prior findings, and checking spacing math confirms the archive button and cloud icon fit comfortably within the mobile width without overlap. I also verify the meta span's opacity transitions still work correctly on hover and that the truncate styling on the row's children isn't affected by the new icon placement. The choice to keep the icon invisible but preserve its box during confirm state addresses both prior concerns, so everything checks out — I'll mark this as clear with no outstanding findings.