Repository navigation
OSC 8 links to local files don't open on Cmd+click (and open twice in mouse-reporting TUIs) #16565
Description
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
In a full-screen TUI with mouse reporting enabled (e.g. Claude Code's fullscreen renderer), Cmd+clicking an OSC 8 hyperlink that points to a local file either does nothing or opens the file twice:
| OSC 8 URI | What happens |
|---|---|
relative path, e.g. docs/guide.md |
nothing |
bare absolute or ~/ path |
nothing |
path with a line suffix, e.g. package.json:3 |
macOS dialog: "There is no application set to open the URL package.json:3" |
file:///abs/path.md |
opens in the system default app and the TUI reveals it in Finder |
https://… |
opens twice (#13512) |
The "Choose an editor to open file links" and "Open Markdown files in Warp's Markdown Viewer" settings have no effect on any of these, while the same settings work for file paths Warp detects in plain command output.
Claude Code emits markdown links to files in its working directory as OSC 8 hyperlinks with a relative URI (and converts absolute paths to file://), so this hits every file link it prints in Warp.
To reproduce
- In Warp on macOS,
cdinto a directory containingdocs/guide.mdand start a fullscreen TUI that emits OSC 8 links, e.g.claudewith"tui": "fullscreen". - Have it print
[docs/guide.md](docs/guide.md). - Cmd+click the link: nothing happens.
- Have it print a link to an absolute path and Cmd+click it: the file opens in the default app and Finder also reveals it.
Expected behavior
- An OSC 8 URI that resolves to an existing local file (relative to the session's working directory,
~/, absolute, orfile://, optionally with:line[:col]) opens like any other file link, honoring the editor settings. - A Cmd+click that Warp handles as a link open is not also reported to the mouse-reporting app, so links open once.
Screenshots, videos, and logs
I added temporary logging to a local build at the click path. One Cmd+click on the relative link produced:
hover OSC 8 hyperlink uri="docs/guide.md"
alt mouse_up modifiers { cmd: true } sgr_mouse=true intercept=false
click_on_grid directly_open=true highlighted=hyperlink "docs/guide.md"
open_hyperlink_uri dropped uri="docs/guide.md" parse_error=relative URL without a base
At that moment the session's local pwd was available (pwd_if_local returned the TUI's working directory), so the path was resolvable.
Operating system (OS)
macOS
Operating system and version
26.6.2
Shell Version
zsh 5.9.2
Current Warp version
v0.2026.10.14.08.27.stable_01 (also reproduced on a local build of master at c1ec372)
Regression
No, this bug or issue has existed throughout my experience using Warp
Recent working Warp date
No response
Additional context
Root cause, from reading the source at c1ec372:
TerminalView::open_hyperlink_uri(app/src/terminal/view.rs) only opens URIs that passurl::Url::parse. Relative and bare absolute paths fail withRelativeUrlWithoutBaseand are silently dropped.package.json:3does parse, as a URL with schemepackage.json, and is handed toopen_url.- OSC 8 links never go through
open_file_path/resolve_file_target, so editor settings are ignored;file://goes toopen_url(system default app). - Because an OSC 8 span takes precedence over path detection, and alt-screen path scanning is skipped while
SGR_MOUSEis set (from_editor == Yes), Warp has no fallback for these links. AltScreenElement::mouse_updispatchesClickOnGrid(which opens the link) and then still forwards the click to the PTY. Warp's SGR mouse reports carry no modifier bits, so the app can't tell it was a Cmd+click; apps that open links on click (Claude Code does on Warp) open it again. This is the cause of Links opened from Claude Code's fullscreen TUI open twice in browser (duplicate click event) #13512 and of the Finder reveal forfile://links.
Related: #13512 (links open twice), warpdotdev/claude-code-warp#80 (file:// links ignore the editor setting), #16440 (file://…:line:col in plain output), #14014 (earlier attempt at Cmd+click under mouse reporting, auto-closed).
I have a fix with unit tests on my fork and can open a PR once this is triaged: resolve OSC 8 URIs to existing local files against the session's local working directory (reusing absolute_path_if_valid and CleanPathResult for :line:col), open them via open_file_path, fall back to the existing URL handling otherwise, and stop forwarding a Cmd+click to the PTY when Warp opens the highlighted link itself. Branch: https://github.com/Im-Victor/warp/commits/victor/osc8-local-file-links
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.
Activity
warp-for-oss commentedon Oct 20, 2026
@Im-Victor
Here's what I found while triaging this issue:
This looks like a Warp terminal hyperlink handling bug rather than a Claude Code-only issue. The provided repro steps and logging are enough to triage it without additional reporter information.
I've flagged this for the factory auto-implement queue.
Maintainer details
I concluded that cmd-clicking OSC 8 local-file hyperlinks in mouse-reporting TUIs is mishandled: local paths are routed as generic URLs or dropped, and the same click can still be forwarded to the TUI..
Triage
This is an actionable Warp terminal bug affecting OSC 8 hyperlinks in mouse-reporting full-screen TUIs on macOS. The report is well specified and includes enough evidence to route without asking the reporter for more information.
Evidence
docs/guide.mdand bare local paths are not opened.file://OSC 8 links bypass Warp's editor-aware file opener and use the system URL opener.Likely root cause
TerminalView::open_hyperlink_uricurrently accepts only strings that parse as URLs and then calls the generic URL opener. That bypasses the path-resolution and editor-target logic used for detected file links. Separately,AltScreenElement::mouse_updispatchesClickOnGridbefore conditionally sendingAltMouseActionto the PTY, so a Warp-handled Cmd-click on a highlighted OSC 8 link can still reach a mouse-reporting TUI.Relevant areas:
app/src/terminal/view.rs,app/src/terminal/alt_screen/alt_screen_element.rs,app/src/terminal/view/link_detection.rs,app/src/util/file.rs, andcrates/warp_util/src/path.rs.Duplicate check
A repository-wide open-issue scan found related hyperlink and duplicate-click reports, including #13512, #6393, #7228, and #3970. I am not marking this as a duplicate because fewer than two existing open issues match the combined OSC 8 local-file resolution plus mouse-reporting forwarding behavior described here.
This is my automated analysis and may be incorrect. A maintainer will verify the details.
Powered by Oz
[-]OSC 8 file links in mouse-reporting TUIs (e.g. Claude Code fullscreen) don't open, or open twice, on Cmd+click[/-][+]OSC 8 links to local files don't open on Cmd+click (and open twice in mouse-reporting TUIs)[/+]Im-Victor commentedon Oct 20, 2026
More data from testing other CLI tools, on a local build of the fix with temporary logging on the click path.
package.json:3→ macOS "no application set to open the URL"The 7 cases were: relative path,
package.json:3,~/path, absolute path,file://URI, a missing file (should do nothing), and anhttps://URL.Two things this adds:
maybe_open_link/open_highlighted_link, so the fix covers both. The issue title is narrower than the actual scope.~/, absolute and:line[:col]paths against the working directory (detect_file_paths→absolute_path_if_valid) and open them through the editor settings. OSC 8 links now go through the same helpers. They also cover links whose visible text differs from the target (e.g.[the docs](docs/guide.md)), which plain-text detection can't see.Not covered here: the latest Codex CLI (0.163.0) renders fullscreen with SGR mouse reporting and prints plain-text paths, not OSC 8, so this fix doesn't apply. That's a separate gap in alt-screen path detection; I've posted details on #16174.