Terminal links open twice in the browser — a second opener fires outside the app (Linux/Wayland)

[ymajoros]

Summary

Clicking a link in a session terminal opens it in the browser twice (two tabs) on Linux/Wayland. After a long trace it turns out the app's own openExternal is only one of the two opens — a second opener fires on the same click from outside the app's code paths, and it leaves no process / D-Bus / exec trace. Filing as a data point + to ask whether anyone can reproduce; I couldn't pin the second opener, and the app-side workaround I'm using is environment-specific.

Environment

• Ubuntu, GNOME on Wayland
• Electron 41.0.3, launched --no-sandbox --disable-features=Vulkan
• Default browser: google-chrome-stable
• Other apps (non-Electron) open links once; manual xdg-open <url> and google-chrome-stable <url> from a terminal open one tab.

What the trace showed

1. Exactly one openExternal per click. Logging the open-external IPC shows one [open-external] ipc line per click. Only one xterm link provider fires (OSC 8 linkHandler or WebLinksAddon, not both), so an OSC8/WebLinks "double" is out.
2. Stub the app's opener to a no-op → the link STILL opens once. Pointed the opener at a wrapper that logs and opens nothing; one tab still appeared. So a second opener exists that is not: the xterm link handlers, setWindowOpenHandler/will-navigate, or the window.open shim (all route through the no-op'd openExternal). App opener active → 2 tabs; no-op'd → 1 tab. So: app opener + mystery opener.
3. The second opener leaves no trace:
   • no new process (tight /proc poll during the click),
   • no session-bus org.freedesktop.portal.OpenURI / org.freedesktop.Application.Open / Chrome NameOwnerChanged (dbus-monitor --session),
   • no exec of chrome/xdg-open/gio (execsnoop-bpfcc).
     So it hands the URL to the already-running browser over a channel that isn't a fresh process or the session bus (Chrome singleton socket / native-messaging / an extension?).

Repro

1. Linux/Wayland, Chrome as default browser.
2. In a session terminal, click an http(s) link.
3. Two tabs open.

Workaround I'm using (NOT proposed as a fix)

Make the terminal link handlers (linkHandler.activate + WebLinksAddon) not call openExternal for http(s) (keep file://→panel). Yields one tab because my environment already opens the link — but where nothing else opens it, this leaves terminal links not opening at all, so it isn't a general fix.

Ask

• Can anyone reproduce on Linux/Wayland + Chrome?
• Any idea what the second, traceless opener is (a GNOME/Chrome extension, native-messaging host, clipboard manager, Chromium content-layer handoff)? Happy to run more probes.