[BUG] Ctrl+click on a hyperlink opens it twice in Windows Terminal (WSL2): Claude Code fires on mouse-down, terminal fires on click completion

Environment

• Claude Code version: 2.1.220
• Terminal: Windows Terminal (WT_SESSION set), default settings
• OS: Windows 11 + WSL2 (Ubuntu 26.04 LTS, kernel 6.18.33.2-microsoft-standard-WSL2)
• TERM=xterm-256color
• Renderer: fullscreen TUI (default)

Summary

When Claude Code prints a markdown link and I Ctrl+click it in Windows Terminal, two browser windows open with the same URL.

The two opens come from two different handlers firing on different phases of the same physical click:

1. Claude Code opens the link when it receives the Ctrl+mouse-down event via SGR mouse reporting.
2. Windows Terminal opens the hyperlink natively when the Ctrl+click completes (press and release on the same link region).

Steps to reproduce

1. In Windows Terminal (WSL2), run claude (fullscreen TUI, mouse reporting enabled).
2. Have Claude output any markdown link, e.g. [label](https://example.com/).
3. Hold Ctrl and click the rendered link.

Expected behavior

The URL opens once (one browser window/tab).

Actual behavior

The URL opens twice (two browser windows with the identical URL).

Evidence for the "two handlers, two phases" diagnosis

I isolated the two handlers by varying the click gesture:

| Gesture | Result | Interpretation |
|---|---|---|
| Plain click on the link (no Ctrl) | Nothing opens | Neither handler triggers without Ctrl: Claude Code's link-open appears to require the Ctrl modifier bit in the mouse event, and Windows Terminal's native hyperlink activation requires Ctrl+click |
| Ctrl+press on the link, release on the link (normal Ctrl+click) | 2 windows | Claude Code fires on mouse-down (1st) + Windows Terminal fires on completed click (2nd) |
| Ctrl+press on the link, move the pointer off the link, then release | 1 window | Claude Code already fired on mouse-down; Windows Terminal cancels its native hyperlink activation because press and release did not complete on the link |

The third row is the key observation: dragging off the link before releasing suppresses exactly one of the two opens, which rules out a duplicated-event explanation (a duplicated mouse-down would still open twice) and shows the second open is the terminal's own click-completion handler.

Difference from existing issues

• #68568 (JetBrains reworked terminal) and warpdotdev/warp#13512 attribute the double-open to the terminal delivering duplicate mouse events for a single click.
• This report is a different mechanism: no duplicate events are needed. Claude Code acts on mouse-down while the host terminal acts on click completion, so any terminal with native Ctrl+click hyperlink handling (here: Windows Terminal) double-opens even with perfectly normal event delivery.

Suggested fixes

Either of these would resolve the Windows Terminal case and likely reduce the impact of the JetBrains/Warp cases too:

1. Open links on mouse-up (click completion) instead of mouse-down, and only when press and release occur on the same link region. This matches platform conventions and makes gesture-level deduplication possible.
2. Alternatively, suppress Claude Code's own Ctrl+click link handling when the host terminal is known to handle Ctrl+click hyperlinks natively (e.g. WT_SESSION present), or make it configurable.

Workarounds found

• Ctrl+press on the link, move the pointer off the link, then release (1 open — relies on Claude Code's mouse-down handler only).
• CLAUDE_CODE_DISABLE_MOUSE=1 (terminal-side open only, but loses in-app scroll-wheel).