Cmd+click on multi-line wrapped URL only opens partial URL (first line portion)

[weppyk]

Description

When a long URL wraps across two or more lines in the terminal, Cmd+clicking on it only opens the first-line portion of the URL in the browser. The second (and any subsequent) line segments are ignored, resulting in a broken/incomplete URL being opened.

Steps to reproduce

1. Make the terminal window narrow enough that a long URL wraps to a second line
2. Output or paste a long URL (e.g. one with many query parameters)
3. Cmd+click on the URL

Expected behavior

The full URL (spanning both lines) opens in the browser.

Actual behavior

Only the portion of the URL on the first visual line is opened — the URL is split at the line wrap boundary.

Environment

• OS: macOS
• Shell: zsh

[oz-for-oss]

@Manoj7ar

Here's what I found while triaging this issue:

Thanks for narrowing this to Claude Code-rendered output. This appears to be in Warp's rich CLI-agent rendering/link handling rather than regular terminal soft-wrapped URLs; OSC 8 hyperlinks from Claude Code would help upstream, but Warp should still handle newline-split URL text defensively.

Maintainer details

I concluded that cmd+click opens only the first fragment of a newline-split URL in Claude Code/CLI-agent rich output, likely because rich-text link detection runs per formatted line instead of across the logical block..

Triage summary

This looks like a Warp bug in the CLI-agent/rich-text output path rather than the regular terminal grid link path. The reporter's key observations are that regular terminal soft-wrapped URLs work, the same Claude Code session works in iTerm2, and the failure appears when Claude Code renders a long URL across hard line breaks in its TUI output.

Reproducibility

Medium. The report includes macOS Stable version 0.2026.04.27.15.32.02, shell zsh, screenshots, a concrete Claude Code CLI scenario, and an iTerm2 comparison. I did not independently reproduce the Claude Code TUI output here, and the behavior depends on whether the URL is emitted as hard-newline-split text versus terminal soft wrap.

Likely root cause

The code supports the triggering comment's hypothesis: app/src/util/link_detection.rs collects rich formatted output with formatted_lines.lines().iter().enumerate() and pushes each rendered line as its own TextLocation::Output { section_index, line_index }. detect_all_links then runs URL detection independently for each (text, location) pair and stores the resulting URL string under that line-specific location. Rendering in app/src/ai/blocklist/block/view_impl/common.rs also registers link handlers per rich-text line, and AIBlock::open_link in app/src/ai/blocklist/block.rs opens the stored DetectedLinkType::Url for that exact range/location.

If Claude Code emits a long URL with real newlines in the rich CLI-agent output, the first line fragment can be recognized/opened independently while the continuation line is not reconstructed into the same logical URL. A defensive Warp fix would likely need to reconstruct URL-safe line continuations before detection, then map the detected logical URL ranges back to the original per-line ranges used for hit-testing/highlighting. OSC 8 hyperlinks from Claude Code would also avoid this class of problem upstream, but Warp can still improve the rich-output fallback.

Duplicate check

No likely duplicate found in the provided recent/open issues or focused GitHub searches for wrapped URL / Claude Code partial-link behavior.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[weppyk]

https://www.huntingshop.eu/404

[weppyk]

[weppyk]

this is from claude session

[weppyk]

I see that problem is only inside claude session, but with iterm2 I dont have this problem inside claude session...

[weppyk]

To answer the triage questions:

Warp version: 0.2026.04.27.15.32.02 (Stable)
Shell: zsh

Minimal reproduction:

The broken URL is output by the Claude Code CLI (not Warp AI — this is the claude terminal CLI by Anthropic). When Claude Code renders a long URL in its TUI response, the URL gets split. Cmd+clicking opens only the first-line fragment.

Example of what gets copied vs what gets opened:

• Full URL: https://example.com/some/very/long/path?param1=value1&param2=value2&param3=value3
• What Cmd+click opens: https://example.com/some/very/long/path?param1=value1&param

Key finding: This works correctly in iTerm2 with the exact same Claude Code session. The difference is likely that Claude Code's TUI emits hard newlines (real \n) rather than soft-wrapping, and Warp's Claude/CLI-agent rich-text rendering path detects URLs per logical/formatted line — which matches Oz's analysis pointing to link_detection.rs in the AI/CLI-agent path.

Potential upstream fix: If Claude Code wrapped URLs in OSC 8 hyperlink sequences (\e]8;;<url>\e\\ display text \e]8;;\e\\), the full URL would be metadata-attached to the link regardless of visual wrapping, and terminals including Warp would open it correctly. That would be a Claude Code fix — but Warp's CLI-agent link detection could also be made more robust by joining wrapped segments before URL hit-testing.