fix(shared): Open in Zed ignores the OpenZFS zed daemon on Linux#33479

Problem

On Linux, editor discovery accepts any executable named zed. When the only one on PATH is the OpenZFS Event Daemon (no Zed editor installed), T3 lists Zed as available, shows "Open in Zed" as the default editor, and clicking it runs the ZFS daemon. Reproduced on main with the genuine zed from Ubuntu's zfs-zed 2.2.2 package as the only zed on the dev server's PATH: the thread header showed "Open in Zed", and clicking it ran the daemon, which printed "Must be run as root".

Change

In resolveEditorCommand (packages/shared/src/editor.ts), on Linux a candidate named zed counts as the Zed editor only if <path> --version exits 0 and its output starts with Zed (the Zed CLI prints Zed 1.27.0 … – …). The OpenZFS daemon only takes short options, so --version makes it print usage and exit 1 without starting. The probe reads only the first chunk of output, has a 2 s timeout, and treats any failure (timeout, spawn error, crash) as "not Zed". A rejected path is skipped and discovery moves on to later candidates. zeditor still comes first and is never probed, and macOS and Windows are unchanged. The resolver now needs a ChildProcessSpawner. The server and desktop production layers already provide one, so only the desktop test layer needed a mock.

resolveEditorLaunch (apps/server/src/process/externalLauncher.ts) no longer falls back to the bare command when the resolver finds nothing. It fails with the existing "Editor command not found" error. For every other editor that fallback already ended in the same error, because the resolver had checked the same command names; the rejected zed is the only input that reached it, so a stale client or a direct shellOpenInEditor request can no longer start the daemon.

Scope and approval

Fixes pingdotgg/t3code#33443

Triaged via the automated issue flow. This is the case where Zed is not installed at all; the both-installed case was pingdotgg/t3code#23375, fixed by pingdotgg/t3code#23416.

Verification

• Tests in apps/server/src/process/externalLauncher.test.ts, 28/28 pass, and vp run check:changed passes:
  • does not offer the OpenZFS zed daemon as Zed on Linux. On main it fails with expected Some({ command: "zed" }) to deeply equal None. With the fix it passes, and the same test then finds a real Zed in ~/.local/bin after rejecting the daemon.
  • does not open Zed with the OpenZFS zed daemon on Linux. Without the launcher change it fails (launchEditor succeeds and spawns zed <cwd>). With it, the launch fails with ExternalLauncherCommandNotFoundError and only the --version probe is spawned.
• Launcher runtime transcript at the head, through the production ExternalLauncher layer with the real process spawner, the genuine OpenZFS zed 2.2.2 from Ubuntu's zfs-zed package (run with its own libzfs), and stubs for a zed that never exits, one that floods stdout, and the Zed CLI. The driver let --version probes run for real and blocked the editor launch itself. Before = 6ba1c3c2f0 (resolver fix only), after = d40748c158:

• Resolver runtime transcript with the genuine ZFS daemon. On main: only ZFS zed → Some(zed), ZFS zed + zeditor → zeditor, neither → None. With the fix: None, zeditor, None. Files: resolve-transcript.txt, driver.ts. Reviewers also checked against the official Zed 1.27.0 Linux tarball (~/.local/bin/zed → zed.app/bin/zed), which is still detected. A zed that hangs is dropped after the timeout, and the hung process is killed.
• Web app, fresh databases (T3CODE_DEV_SEED=0), before = 7b248349bd, after = 58adedf070. These captures predate the launcher change in d40748c158, which adds no render path (a stale launch now ends in the existing error toast) and leaves discovery's result for these fixtures unchanged, as the transcript shows. E0 = only the ZFS daemon, E1 = ZFS daemon + VS Code (stub code), E2 = genuine Zed 1.27.0 + VS Code stub.

Before: the ZFS daemon is offered as Zed. After: no installed editors found.

Comparison sheets, all viewports (1440 and 390 wide) and themes: E0, E1, E2. Every pair, recording, diff and seed/driver script: evidence report, gallery, reproduction steps.

What else changed: E0, the Open-in control becomes the disabled "Open in editor" with "No installed editors found", and the file-tree "Open with › Zed" entry disappears. E1, the default falls back to VS Code and Ctrl+O moves to it. E2, nothing changed at zero threshold.

Not checked: the native Electron desktop window and its remote-editor IPC (same shared resolver; the client side was rendered in a labelled harness), SSH editor links, opening the real Zed GUI (headless VM), and captures of the other consumers of the editor list (Markdown file-link menu, Settings › Keybindings, the keybindings warning, terminal path links, diff actions), which read the same list as the captured picker.

AI-assisted; verified with the tests and tools listed above.