Cmd+click on file links in iTerm2 fails with "The application can't be opened. -50" — OSC 8 URI lacks file:// scheme

Summary

Cmd+clicking a file link in Claude Code's output inside iTerm2 shows a macOS error dialog — "The application can't be opened. -50" — instead of opening the file. The OSC 8 hyperlink Claude Code emits for file paths uses the bare filesystem path as the URI, with no file:// scheme. iTerm2 (like other terminals that handle hyperlink clicks natively) passes the URI to NSWorkspace openURL:, and Launch Services rejects a scheme-less URL with paramErr (-50).

Environment

• Claude Code 2.1.205 (Homebrew cask claude-code@latest)
• macOS 26.5 (25F71)
• iTerm2 3.6.10
• tmux 3.6b (tmux is not the cause — see below)

Repro

1. Run claude in iTerm2 (with or without tmux).
2. Have Claude write a file so its output contains a clickable file path (e.g. Wrote .claude/brainstorm/foo.md).
3. Cmd+click the path.
4. macOS alert: "The application can't be opened. -50".

Evidence

Raw OSC 8 bytes captured from the pane (tmux capture-pane -e) show the emitted URI is a bare path:

\e]8;;/Users/eugenechan/dev/personal/lfg/.claude/brainstorm/multihost-first-rearchitecture.md\e\

(tmux is exonerated: injecting a file:///... OSC 8 link into the same pane survives round-trip with the scheme intact, and cmd+clicking it opens the file correctly.)

iTerm2 debug log of the click shows iTerm2 treating it as a URL action and dispatching the scheme-less URI:

iTermURLActionFactory.m:366 Found hypertext url /Users/…/multihost-first-rearchitecture.md
URLAction actionType=OpenURL string=/Users/…/multihost-first-rearchitecture.md
NSWorkspace+iTerm.m:211 it_openIfNonWebURL: Non-web scheme

Direct replication of the failure with a scheme-less URL:

NSWorkspace.shared.open(URL(string: "/Users/me/file.md")!, configuration: .init()) { _, err in print(err) }
// Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr" (_LSOpenStuffCallLocal, LSOpenCore.mm)

Why iTerm2 never forwards the click to Claude Code

The 2.1.196 feature ("clickable file attachments in chat — Cmd/Ctrl-click reveals the file in Finder/Explorer") appears to expect Claude Code's own mouse handling to receive the cmd+click. iTerm2 deliberately does not report clicks on hyperlink ranges to the application (debug log: "In underlined range so don't report / Mouse reporting disallowed") — it opens the link itself. So on iTerm2 the emitted URI is what macOS receives, and it must be a valid URL.

Regression window

Worked before upgrading (pre-2.1.196 emitted file paths as plain text, so iTerm2's Semantic History opened them with the default app). Broken after upgrading to 2.1.205.

Suggested fix

Emit the hyperlink URI as a proper RFC 8089 file URL — pathToFileURL(path).href — as some other link emission in the codebase already does (there is an existing helper that does exactly ` \x1B]8;;${pathToFileURL(e).href}\x07… `). Terminals that open hyperlinks natively (iTerm2) then open the file with the user's default app, and Claude Code's internal cmd+click handling can continue to work on terminals that forward the click.