cmd+click on wrapped URLs only opens the first wrapped line

Summary

When the CLI prints a long URL that wraps across multiple terminal lines, ⌘ +click on the URL only opens the first wrapped line as the link target, dropping the remainder. Users have to manually select+copy the full URL instead of click-to-open.

Environment

• Claude Code CLI (Opus 4.7, 1M context)
• macOS Darwin 25.3.0 / Terminal.app and iTerm2 (both reproduce)
• Terminal width: 100~140 cols

Repro

1. Have the assistant emit a long URL in a reply, e.g. a Figma deep link with an encoded Korean path segment:

``
https://www.figma.com/design/2OLkZ7WFyuazD9LEoJmXUn/MO-%EC%95%8C%EB%A6%BC%EC%9E%A5?node-id=18399-51235&m=dev
``

1. The URL wraps to two lines in the terminal.
2. ⌘ +click anywhere on the URL.

Actual: Browser opens only the first wrapped line (e.g. https://www.figma.com/design/2OLkZ7WFyuazD9LEoJmXUn/MO-%EC%95%8C%EB%A6%BC%EC%9E%A5?), which is an invalid Figma URL — the node-id parameter is dropped.

Expected: The CLI should recognize the entire wrapped URL as one hyperlink and open the full URL.

Why it matters

External systems (Figma, Confluence, Notion, etc.) often produce deep links with non-ASCII path segments that get percent-encoded into long URLs. Workflows that paste those URLs back into chat (e.g. design QA, doc review) hit this consistently. Shortening the URL by dropping the path segment isn't a viable workaround — Figma node anchoring requires the full path.

Workarounds users currently rely on

• Select+copy the wrapped URL manually then paste into the browser
• Have the assistant emit open "<url>" so the OS opens it instead of the user clicking
• Use a wider terminal so the URL doesn't wrap

Suggested fix direction

Detect URL spans across wrapped lines (or stitch wrapped segments back together before exposing the OSC 8 hyperlink / ⌘ +click hit-test) so the full URL is opened as a single link.