Path detection: CJK / full-width punctuation not treated as word boundary, paths become un-clickable

[Jokairui]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID
• I have technical issue and have included the logs

Describe the bug

Warp's clickable-path detection fails when a file path is immediately preceded by a CJK / full-width punctuation character with no ASCII whitespace in between. The same path with a leading ASCII space (or preceded by ASCII punctuation) is recognized correctly.

This is common when terminal output is generated by AI CLIs or Chinese/Japanese developer tooling that prints file paths inline in prose, e.g. 路径：<path> or 出力先：<path>. Today those paths are un-clickable in Warp, while iTerm2 (Cmd+Click) and VS Code's integrated terminal handle them fine.

Concrete example:

路径：/Users/me/project/plan.md          ← NOT clickable (fullwidth ：touching /)
路径: /Users/me/project/plan.md          ← clickable  (ASCII : + space)
/Users/me/project/plan.md                ← clickable  (bare)

The only difference between line 1 and line 2 is ： (FULLWIDTH COLON, U+FF1A) directly touching /, vs : (ASCII colon + space). The path itself is identical and exists on disk in all three cases.

To reproduce

1. Create any file, e.g. touch /tmp/warp-repro.md
2. In Warp, run:

   printf '路径：/tmp/warp-repro.md\n路径: /tmp/warp-repro.md\n/tmp/warp-repro.md\n'

3. Hover each line and try Cmd+Click:
   • Line 1 (full-width ： touching path): not recognized, no hover underline, Cmd+Click does nothing
   • Line 2 (ASCII : + space): recognized, opens in configured editor
   • Line 3 (bare path): recognized, opens in configured editor

Expected behavior

The path should be recognized in all three cases. The path-detection logic should treat Unicode punctuation and CJK characters as word boundaries, not just ASCII whitespace / punctuation.

The most common offenders are:

Char	Codepoint	Name
：	U+FF1A	FULLWIDTH COLON
，	U+FF0C	FULLWIDTH COMMA
。	U+3002	IDEOGRAPHIC FULL STOP
「/」	U+300C / U+300D	CJK corner brackets
『/』	U+300E / U+300F	CJK white corner brackets
（/）	U+FF08 / U+FF09	FULLWIDTH PARENTHESES

A pragmatic fix: in the left/right boundary check, accept any character whose Unicode General Category is P* (punctuation / Z* separator / Lo CJK ideograph) as a boundary, rather than only ASCII whitespace + specific ASCII punctuation.

Screenshots, videos, and logs

No response

Operating system (OS)

macOS

Operating system and version

26.4.1 (Tahoe)

Shell Version

zsh 5.9

Current Warp version

v0.2026.04.29.08.57.01

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

Impact: LLM-backed CLIs (Claude Code, etc.) and Chinese/Japanese developer tooling routinely print file paths inline in CJK prose. Today every such path requires selecting + right-click → Open File, which defeats the purpose of Cmd+Click.

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes — iTerm2 Cmd+Click and VS Code integrated terminal both recognize the same paths.

[oz-for-oss]

@Jokairui

Here's what I found while triaging this issue:

Thanks for the clear repro. This looks actionable: Warp appears to miss existing paths when they are directly adjacent to full-width/CJK punctuation, while the same path separated by ASCII punctuation/space is detected.

Maintainer details

I concluded that warp does not recognize existing file paths for Cmd+Click when the path is directly preceded by full-width/CJK punctuation such as U+FF1A FULLWIDTH COLON..

Triage summary

This is a well-specified terminal file-link detection bug. Existing paths become un-clickable when directly preceded by full-width/CJK punctuation, while the same path is detected when separated by ASCII punctuation/whitespace.

Reproducibility

High. The issue includes a minimal printf repro, clear expected/actual behavior, OS, shell, Warp version, and a comparison against other terminals. The current code path also supports the report: terminal file-link candidate generation splits text using a fixed separator list that includes ASCII : and , but not full-width/CJK punctuation such as ：.

Likely root cause

Warp's terminal hover file-link scanner gets possible file paths from grid fragments split by FILE_LINK_SEPARATORS in app/src/terminal/model/grid/grid_handler.rs. Because ： is not in that separator set, text like 路径：/tmp/warp-repro.md stays in one fragment and is validated as a whole string instead of considering /tmp/warp-repro.md as a candidate. The rich-content helper in app/src/util/link_detection.rs uses similar separator-driven candidate generation, so the same class of issue may exist outside the terminal grid hover path.

Relevant files for maintainers:

• app/src/terminal/model/grid/grid_handler.rs
• app/src/terminal/view/link_detection.rs
• app/src/util/link_detection.rs
• crates/warpui_core/src/text/words.rs
• crates/warp_core/src/semantic_selection/mod.rs

Duplicate check

I checked open issues and recent closed issues. There are related file/link detection issues such as #9908, #9193, and #6393, but I did not find two existing issues with the same full-width/CJK punctuation boundary symptom, so this should not be marked as a duplicate at this point.

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

Powered by Oz