fix(web): make terminal links appear clickable only when clickable - #7488
UI Consistency: No issues found
All clear
Details
Note
Your check run agent prompt is: .macroscope/check-run-agents/ui-consistency.md
More information about how Check Run Agents work can be found in our Help Center.
🔍 Agent activity — 5 tool calls
💭 Both previously flagged issues seem resolved now—the stale test was removed and the activation path uses isTerminalUrl. I'm checking whether any UI consistency issues remain, particularly around the behavioral change where hover now unconditionally requires linkModifierActive, compared to the prior logic that showed on hover unless mouseTracking was active without the modifier. I want to verify the activation path is consistent with the modifier requirement and check surface.ts for cursor/pointer styling consistency, plus confirm there's test coverage for the new behavior.
1. git_tools — linkModifierActive
2. git_tools — isTerminalLinkActivation|isTerminalLinkPointerGesture
💭 I'm double-checking whether the URL pattern's global flag could cause statefulness issues if used with
.test()elsewhere, and confirming thatisTerminalUrlbelongs in the terminal-links file. Also, removing the hover test changes coverage — now activation and hover both require the modifier key, which seems intentional per the PR, but the privaterefreshHoveredLinkfunction makes this hard to test directly. I want to verify the test file still compiles cleanly after the removal and check thecollectMatcheslogic in terminal-links.ts to confirm nothing else references the old behavior.
3. browse_code — apps/web/src/terminal-links.ts
4. git_tools — shouldShowTerminalLinkHover
💭 With prior fixes in place, I'm now looking at the remaining change: removing the hover gate tied to mouse tracking. Previously, when mouse tracking wasn't active, hovering a link would show the underline and pointer cursor even without holding cmd, which was misleading since actual activation still required the modifier key — that mismatch between visual feedback and actual clickability seems to be the bug this change addresses. Now I want to check if that fix introduces a regression: does pressing Cmd while hovering (without moving the mouse) still trigger the hover state? Since pointermove sets linkModifierActive from the event, moving the cursor while holding Cmd should still work fine, so this seems like a reasonable tradeoff. I want to trace where updateLinkModifier gets called to confirm this behavior.
5. git_tools — updateLinkModifier|hoveredLink|clearHoveredLink
💭 Everything checks out coherently now. I notice some minor duplication between
isTerminalUrland the markdown-links external scheme pattern, but that's not a UI consistency concern, and the test placement inside the describe block is just a small organizational nit, not worth reporting. Thinking about the hover behavior change under mouse tracking: since coarse pointers don't hover anyway, that's fine. ThehoverPointerflag being set in the mouse-tracking branch even when hover is suppressed looks pre-existing. Tracing through the logic, removing the mouse-tracking check doesn't actually change behavior — before and after, hover still requires the modifier key when tracking is active but not any-event tracking, so the outcome is equivalent. Since I've confirmed there's no actual behavior regression here, I don't have any findings to report.
Agent Credits: 0 credits
No billable model usage was recorded for this run.