URL linkifier hijacks www. inside absolute file paths — renders http:// mid-path, path becomes unclickable and uncopyable

[mrlerch]

Bug

When terminal output contains an absolute POSIX file path whose directory name contains a web domain (a very common layout for web developers: ~/Sites/www.example.com/...), Warp's URL smart-linkifier fires on the www. in the middle of the path. It wins over file-path detection, visually injects http:// into the middle of the rendered text, and splits the path into a useless web link plus fragments.

Repro

1. Have a project under a domain-named folder, e.g. /Users/me/Sites/www.proproductssales.com/html-phpstorm/
2. Run anything that prints a full path in that tree, e.g.:

   echo "Report saved: /Users/me/Sites/www.proproductssales.com/html-phpstorm/docs/report.md"
   

3. Look at the rendered output.

Actual

Rendered as:

Report saved: /Users/me/Sites/http://www.proproductssales.com/html-phpstorm/docs/report.md

• The www.proproductssales.com/html-phpstorm/docs/report.md portion becomes a web link to http://www.proproductssales.com/... (404s — it's a local folder name).
• The leading /Users/me/Sites/ is orphaned plain text.
• Cmd-clicking cannot open the file; selecting/copying the rendered line yields the corrupted http://-injected string, so the path can't even be copy-pasted.
• file:// URIs don't help: file:///Users/me/Sites/www.example.com/... — the linkifier STILL grabs the inner www. and splits the file URI.

Expected

If a token parses as an absolute path (starts with / or ~/, no scheme), path/file linkification should take precedence over bare-www. URL detection for the interior of that token — or at minimum the copied text should be the original bytes, never the linkifier's rewritten form.

Impact

This affects every AI-agent workflow (Warp AI, Claude Code, etc.) where the agent prints file paths for the user to click — any project living in an Apache-style ~/Sites/www.<domain>/ folder produces permanently broken links. Current workaround is creating dot-free symlinks next to every domain-named project folder, which shouldn't be necessary.

Environment

• Warp 0.2026.07.08.17.54.02 (stable)
• macOS 15.7.7 (Intel)

[oz-for-oss]

@mrlerch

Here's what I found while triaging this issue:

Thanks for the detailed repro. This looks actionable from the provided command: Warp appears to be treating the www... directory segment as a bare web URL before file-path detection can claim the full path.

Maintainer details

I concluded that warp appears to prioritize bare-www URL detection over local file-path detection when a domain-like directory appears inside an absolute POSIX path, causing the path to be split into a web link plus plain-text fragments..

Triage summary

This is a terminal output linkification bug. A full POSIX path containing a www.<domain> directory is split so the www... suffix is handled as a web URL instead of preserving/opening the local file path.

Reproducibility

High. The issue includes an exact echo command, observed and expected behavior, Warp stable version, and macOS version. The report is also consistent with the current link-detection ordering in the codebase.

Likely root cause

The terminal hover path in app/src/terminal/view/link_detection.rs calls model.url_at_point first and sets GridHighlightedLink::Url as soon as a URL is found. The grid URL detector in app/src/terminal/model/grid/grid_handler.rs uses UrlLocator, which can recognize bare www. URLs inside a non-whitespace token. Local file-path scanning runs later and is skipped while a URL is already highlighted. Rich-content/agent-output detection in app/src/util/link_detection.rs follows a similar URL-first pattern: URL ranges are inserted first, and detected file paths are skipped if they overlap a URL range.

That ordering likely lets the www.<domain> segment inside /Users/.../Sites/www.example.com/... win over the full path. The file:// variant in the report is consistent with the same class of issue if the file URI is not claimed as a whole before bare-www. URL detection runs.

Duplicate check

I searched all open non-PR issues with pagination, excluding #13619, and checked recently closed issues from the last seven days for www., linkifier/link-detection, file://, URL/path-overlap, and domain-folder signals. I found related link-detection issues, but not two likely duplicates for this exact www.-inside-local-path symptom.

Suggested routing

Route to terminal/link-detection owners. Useful regression coverage would include terminal grid hover/click behavior and rich-content/agent-output link detection for absolute POSIX paths and file:// URIs containing www. directory names.

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

Powered by Oz