[Bug]: Linux Open in Zed selects the ZFS Event Daemon instead of zeditor#23375

Before submitting

• I searched existing issues and did not find a duplicate of this Linux ZFS/Zed collision.
• I included enough detail to reproduce or investigate the problem.

Area

packages/contracts or packages/shared

Steps to reproduce

1. On Arch Linux, have both the zed editor package and zfs-utils installed.
2. Ensure both /usr/bin/zed and /usr/bin/zeditor are available through T3's command lookup environment.
3. Start T3 Code and open a local project.
4. Select Open in Zed.

The two executable names belong to different applications:

zed is the ZFS Event Daemon. zeditor is the Zed editor CLI.

Expected behavior

T3 should open the requested project in the installed Zed editor. Finding an executable with the name zed should not count as finding the editor when that executable belongs to ZFS. Discovery should continue to a valid editor candidate, such as zeditor.

Actual behavior

Open in Zed does not open the editor. T3's Linux command resolution selects the ZFS zed executable before considering the working zeditor command.

The installed application bundle was inspected, including the server process's executable lookup environment. It contains the same first-available-command behavior described below, and that environment resolves both executable names.

Impact

Minor bug or occasional failure

The Open in Zed action fails consistently with this package combination. Opening the project manually remains possible.

Version or commit

Observed in a local preview build: 0.1.1-preview.20261019.1, embedded source commit 9ef027f5ff0a.

This is a locally built preview containing an unrelated ACP-controls change, not a claim that an unmodified official release was retested. The same relevant resolver and command ordering are still present in upstream main at 3b95e7831b11b17627dff16843bc087bfca397ec, inspected separately. That current upstream revision was not installed for another GUI retest.

Environment

• Arch Linux, x86_64, kernel 7.2.11-arch1-1.
• T3 Code desktop application, opening a local project.
• zed package: 1.25.2-1 at report time. The failure was originally investigated with 1.24.3-1, which used the same zeditor executable name.
• zfs-utils: 2.4.4-1.
• Provider/model is unrelated to this editor-launch action.

Logs or stack traces

The relevant evidence is the executable ownership above and the upstream selection logic:

• Zed's command candidates are ordered as commands: ["zed", "zeditor"].
• The shared resolver returns the first available command. Its existing Zed/ZFS collision handling prefers the application bundle only on macOS (platform === "darwin"), leaving Linux on the ambiguous PATH-first route.

A controlled local launcher regression also reproduced the selection failure with harmless executable fixtures: the selected command was zed when the expected editor candidate was zeditor. The real ZFS daemon was not deliberately run as a diagnostic probe.

Screenshots, recordings, or supporting files

No screenshot is needed to distinguish these two executables; package ownership and the linked resolver show the collision directly.

Related, but not the same reported failure: #5078 concerns editor identity/discovery on macOS; #1978 concerns stable Zed versus Nightly on Windows. This report concerns Linux selecting a non-editor executable.

Workaround

Open the project directly with the real editor CLI, for example:

Do not replace the system zed executable with a symlink: it belongs to zfs-utils.

Possible fix direction

Validate that a candidate actually identifies the requested editor, and continue discovery when it does not. Linux desktop-application registration may offer an identity-based route, but this report does not depend on accepting a particular implementation or a broader editor-discovery redesign.