Box-drawing characters not recognized as link separators; `tree` output never clickable

[rndjams]

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 (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

Filenames in tree output (and eza --tree, lsd --tree, and similar tree-drawing listers) are never clickable in Warp, even when the file they name exists on disk under the tree's root.

Example row from tree /tmp/repro:

│   └── alpha.md

alpha.md is not recognized as a clickable filename token. Hovering the filename does not highlight it; clicking does nothing.

The cause is in the tokenizer's separator set: FILE_LINK_SEPARATORS in app/src/terminal/model/grid/grid_handler.rs includes ASCII | and space but not the Unicode box-drawing characters │ (U+2502), ├ (U+251C), └ (U+2514), ─ (U+2500), ┬ (U+252C), ┴ (U+2534), ┼ (U+253C) that tree-style commands use to draw their hierarchy. Because these characters are not separators, a row like │ └── alpha.md is tokenized as a single word and alpha.md never appears as a standalone candidate substring for file-path validation.

This is a separate concern from the directory-root resolution bug in #9908: even with listing-aware resolution in place, tree output cannot benefit because the tokenizer doesn't produce the right candidates in the first place.

To reproduce

mkdir -p /tmp/tree-repro/{a,b}
echo hi > /tmp/tree-repro/a/alpha.md
echo hi > /tmp/tree-repro/b/beta.json
cd /tmp/tree-repro
tree

Hover any filename in the output. Observe that nothing is highlighted as a clickable link.

For reference, the output looks like:

.
├── a
│   └── alpha.md
└── b
    └── beta.json

Expected behavior

1. alpha.md, beta.json, and the directory names a, b must be tokenized as standalone filename candidates by the grid tokenizer.
2. Once tokenized, standard file-path validation applies — the filenames must be clickable if they resolve against the appropriate directory root. (With the fix for Clickable filenames in ls DIR/ output resolve against CWD, silently opening wrong files #9908 in place, that resolution uses the tree command's argument directory.)

Proposed fix

Extend FILE_LINK_SEPARATORS in app/src/terminal/model/grid/grid_handler.rs to include the Unicode box-drawing characters that appear in common tree/ASCII-art output:

// Add to the existing set:
'│', '├', '└', '─', '┬', '┴', '┼',
// And the double-line variants for completeness:
'║', '╠', '╚', '═', '╦', '╩', '╬',

Add tests in app/src/util/link_detection_test.rs covering:

• │ └── alpha.md → candidates include alpha.md
• Multi-byte (Unicode) filenames inside tree output: │ └── 音楽.md → candidates include 音楽.md
• Absolute path leaves: │ └── /tmp/foo.md → candidates include /tmp/foo.md

Screenshots, videos, and logs

The repro steps above are minimal and deterministic; happy to record a short screen capture on request.

Operating system (OS)

macOS

Operating system and version

macOS 26.4.1 (Darwin 25.4.0, arm64)

Shell Version

zsh 5.9

Current Warp version

v0.2026.04.27.15.32.stable_03

Regression

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

Recent working Warp date

No response

Additional context

tree version tested: tree v2.2.1 (Homebrew). This issue is a prerequisite for the tree part of the scope in #9908. Fixing one without the other still leaves tree output unclickable.

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@rndjams

Here's what I found while triaging this issue:

This looks actionable and distinct from #9908: #9908 is about choosing the directory root for validation, while this report is about generating filename candidates from tree-style output. The repro is deterministic and includes the relevant Warp version.

Maintainer details

I concluded that tree-style command output is not reliably tokenized into clickable file-path candidates because Unicode box-drawing connector glyphs are not treated as file-link separators..

Triage summary

This is an actionable terminal link-detection bug. The reported symptom is that filenames emitted by tree-style tools are not clickable even when the named files exist.

Code inspection supports the reported failure mode: app/src/terminal/model/grid/grid_handler.rs defines FILE_LINK_SEPARATORS, and that set is used by terminal grid fragment/path candidate generation as well as file-link detection helpers in app/src/util/link_detection.rs. The current separator set includes ASCII separators such as space and |, but does not include Unicode box-drawing connector characters such as │, ├, └, and ─.

Recommended implementation direction is to add the common single-line and double-line box-drawing connector glyphs to FILE_LINK_SEPARATORS, then add focused tests in app/src/util/link_detection_test.rs for tree-output leaves, including multibyte filenames and absolute path leaves. This should be treated as related to, but distinct from, #9908: #9908 covers resolving clickable listing entries against the correct directory root, while this issue covers producing the candidate filename tokens in the first place.

Duplicate check: all open issues were enumerated with pagination. #9908 is closely related but covers a different root-resolution failure, #9091 covers remote SSH .md file clickability, and #1940 covers box-drawing glyph rendering rather than link tokenization, so there are not enough matching duplicate candidates to mark this as a duplicate.

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

Powered by Oz