[Bug]: Windows "Open in Zed" opens Zed Nightly instead of stable Zed#1978

openedApr 13, 2026bySsrothgan

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Use T3 Code on Windows with both stable Zed and Zed Nightly installed.
  2. Ensure both zed and zeditor are available on PATH.
  3. Open a project/thread in T3 Code.
  4. Click Open and choose Zed, or use the preferred-editor shortcut when Zed is selected.

Expected behavior

Choosing Zed should open the stable Zed install.

Actual behavior

T3 Code resolves the zed command first and opens Zed Nightly instead of stable Zed.

Impact

Minor bug or occasional failure

Version or commit

main @ 0.017

Environment

Windows, T3 Code, Zed stable and Zed Nightly both installed.

Logs or stack traces

shell
1

Screenshots, recordings, or supporting files

No response

Workaround

Uninstall Zed Nightly, remove its command from PATH, or reorder PATH so the stable command resolves first.

Synced from GitHub

I’d like to take this one.

From the code, this looks like an apps/server problem in shell.openInEditor / editor command resolution, not a web UI issue. Right now the Zed integration prefers command names like zed and zeditor, but on Windows that can resolve to the wrong installed variant depending on how the local PATH is set up. In my case, choosing Zed opens Zed Nightly instead of stable Zed.

My current thinking for a fix is:

  • resolve candidate commands to absolute executable paths first instead of only checking whether a command name exists
  • on Windows, use the resolved path to distinguish stable vs Nightly when the install location makes that clear
  • avoid hardcoding zeditor as always meaning stable Zed
  • avoid silently guessing if the resolved paths are ambiguous

If that direction sounds good, I can work on a targeted fix and add tests around Windows Zed command resolution.

Synced from GitHub

I got the fix locally working and could make a PR. However, I dont know if the same bug exists on MacOs and I can not test it there

The command-selection symptom still reproduces against main 82f64cd8, tested September 5, 2026 UTC. I exercised the production ExternalLauncher with its Windows platform service and real disposable executable files. With zeditor.EXE in the first PATH directory and zed.EXE in the second, it chooses zed. With only the first directory, it chooses zeditor. Reordering PATH alone cannot override the preference between these two different command names.

This is a Linux-hosted platform fixture, not a native Windows launch of the installed stable and Nightly applications. I cannot establish which aliases each current installation exposes here. A fix still needs that native evidence and a decision about how the generic Zed entry should select a channel when both exist. #2066 was closed unmerged and has not been reopened or copied into a replacement.

GPT 6 Astra via Codex in T3 Code.