[BUG] Ctrl+click on a file-path link opens the file twice on Linux: terminal opens it in the editor, Claude Code also opens the containing folder via FileManager1.ShowItems

Environment

• Claude Code version: 2.1.220 (native Linux binary, auto-updated)
• OS: Ubuntu 24.04 (GNOME desktop)
• Terminal: gnome-terminal 3.52 / VTE 0.76 (VTE_VERSION set)
• File manager providing org.freedesktop.FileManager1: Thunar (running as daemon)
• xdg default for the clicked file types: VSCodium
• Renderer: default TUI, mouse reporting enabled

Symptom

Ctrl+clicking a file path printed in a tool header (Read/Write/Edit) opens the file in the xdg default editor (VSCodium) and opens the file's parent directory in the file manager (Thunar) — two windows for one click.

• Plain click (no Ctrl) does nothing.
• Started with the ~2.1.216-era builds (this machine updated to 2.1.217 on 2026-07-22; no relevant system packages — gnome-terminal, vte, glib, xdg-utils, codium — changed in that window).

Diagnosis: two handlers fire on one ctrl+click

From inspecting the installed binary:

1. Terminal side (desired): Claude Code wraps file paths in OSC 8 hyperlinks with a plain file:// URI:

``js
function fX(e){if(!mk())return e;return\x1B]8;;${wyp.pathToFileURL(e).href}\x07${e}\x1B]8;;\x07}
`
gnome-terminal activates the hyperlink on ctrl+click → gtk_show_uri` → default app for the mime type → the file opens in VSCodium. This is the open the user wants.

1. Claude Code side (the duplicate): the TUI's own mouse handling also receives the ctrl+click (qe.onHyperlinkClick=(Er)=>{VXr(...)}), and the internal dispatcher special-cases file: URIs by calling org.freedesktop.FileManager1.ShowItems over D-Bus — i.e. "reveal in file manager":

``js
async function oay(e){try{let{code:r}=await an("dbus-send",["--session","--print-reply",
"--dest=org.freedesktop.FileManager1","--type=method_call","/org/freedesktop/FileManager1",
"org.freedesktop.FileManager1.ShowItems",
array:string:${Emo.pathToFileURL(e).href.replaceAll(",","%2C")},"string:"]);return r===0}catch(t){return!1}}
`
On this system Thunar provides FileManager1`, so a Thunar window opens showing the parent folder with the file selected.

Replaying that exact dbus-send call by hand reproduces the Thunar window precisely — identical to what appears on ctrl+click.

The "plain click does nothing" observation matches #81905's finding that the internal handler requires the Ctrl modifier bit in the mouse event — so both handlers are bound to the same gesture and always collide.

Related issues (same root cause, different environments/symptoms)

• #81905 — same double-dispatch (Claude Code on mouse-down, terminal on click completion), URL × Windows Terminal/WSL2.
• #73968 — URLs open twice on WSL; second open proven (via an xdg-open shim) to be spawned by Claude Code itself.
• #72998 — duplicate tabs in Konsole; also verifies that FORCE_HYPERLINK=0 is ignored, so there is currently no user-side workaround for any of these.

What none of them covers is this report's Linux file-path case, where the two handlers do different things (editor + file manager), which makes the double dispatch especially visible.

Expected behavior

One ctrl+click on a file path triggers exactly one action.

Suggested fix

Any of:

• Don't dispatch hyperlink clicks internally when the terminal is detected as hyperlink-capable (Claude Code already gates OSC 8 emission on exactly that detection — mk()), letting the terminal own the activation; or
• debounce/dedupe the two phases as suggested in #81905; or
• make the internal file-link action ("reveal in file manager") configurable, including off.

Provenance

This issue was diagnosed and filed autonomously by Claude Fable 5 (running in Claude Code) on behalf of, and with the review and approval of, the account owner. The diagnosis steps — binary string extraction, D-Bus reproduction, and issue-tracker search — were performed by the model on the affected machine.