[only21mil]

Problem

On Windows with stable Zed and Zed Nightly or Zed Preview installed side by side, choosing "Zed" opens whichever install comes first on PATH. Each channel installs its own zed CLI in its own folder (Programs\Zed\bin, Programs\Zed Preview\bin), and editor resolution takes the first zed it finds. The workaround is reordering PATH or uninstalling Nightly.

Fixes https://git.cafe/pingdotgg/t3code/issues/1978.

Change

• editor.ts: on Windows, generic Zed now lists every PATH match for zed and zeditor and picks the first one whose install folder does not name a prerelease channel. The install folder is the nearest folder above the CLI that names Zed (Zed, Zed Preview, Zed Nightly), so a user or parent folder further up, such as zedpreview, does not mark stable Zed as prerelease.
• When that pick is the first PATH match, it launches by name as before. Only a stable install behind a prerelease one launches by absolute path. With one install, PATH already in the right order, or only prerelease installs, nothing changes.
• shell.ts: the PATH walk inside resolveCommandPath moves into a helper that stops at the first match or returns all of them. resolveCommandPath keeps its cache and behavior. The new resolveCommandPaths uses the same walk and directory listing cache, and caches no results.
• macOS and Linux are untouched. macOS already prefers the Zed.app bundle over PATH, and the issue is Windows-only.
• The spawn environment is untouched. Review bots flagged https://git.cafe/pingdotgg/t3code/pulls/2066 for replacing it.

Scope and approval

This needs maintainer approval of the selection rule before it can merge. Julius's triage on https://git.cafe/pingdotgg/t3code/issues/1978 reproduced the bug on main and left open how the generic Zed entry should pick a channel when several are installed. https://git.cafe/pingdotgg/t3code/pulls/9501 made this same fix and was closed for missing that decision, not on its merits.

This PR implements one answer: generic "Zed" means stable, so a stable install beats a Nightly or Preview one earlier on PATH. Other options are keeping PATH order (closing the issue as intended) or separate "Zed Nightly" and "Zed Preview" entries. I'm opening it so the rule can be decided against working code, and will rework or close it if you pick another.

Open https://git.cafe/pingdotgg/t3code/pulls/23416 edits the same block in editor.ts for Linux. Neither PR changes the other's platform, so whichever merges second needs a small rebase.

Verification

• New case in externalLauncher.test.ts for Zed Nightly and Zed Preview, through the real ExternalLauncher with the Windows platform service and real files under a user folder named zedpreview. With the prerelease bin first on PATH, stable must launch by absolute path; with stable removed, the prerelease install must still open by name. On the base commit both cases fail: the launcher spawns zed, the prerelease install.

Test run on the base commit with the new tests.

Test run on this branch.

• vp test run src/process/externalLauncher.test.ts: 22 passed. vp test run src/shell.test.ts in packages/shared: 40 passed, 2 skipped.
• vp lint and vp fmt --check on the three changed files, and vp run --filter @t3tools/shared --filter t3 typecheck: pass.
• Windows 11 (26H2), Zed 1.25.3 and Zed Preview 1.26.2 from their own installers, Preview's bin first on PATH: I built the Windows CLI archive (t3.exe plus the web client) from this branch, and t3.exe from the base commit; this PR changes no client code. For each, I ran t3 serve, added a folder as a project in Edge, and clicked Open in Zed. The base commit opened the folder in Zed Preview; this branch opened it in stable Zed. Each capture shows the click and the About dialog of the Zed that opened.

Windows 11, T3 Code server built from the base commit.

Windows 11, T3 Code server built from this branch.

• On the same machine, a script bundled from externalLauncher.ts ran ExternalLauncher.launchEditor({ editor: "zed" }) with Node's real spawner and logged each spawn: Programs\Zed Preview\bin\zed.EXE on the base commit, Programs\Zed\bin\zed.EXE on this branch.

Not checked:

• Zed Nightly on Windows. Zed's Windows Nightly download returned 404 when I ran this, so the native run used Preview. Nightly is covered by the test only.
• Whether Zed Nightly on Windows also installs a zeditor alias. The rule covers both names either way.
• When neither folder names a channel, zed still wins over an earlier zeditor, the shape Julius's fixture on https://git.cafe/pingdotgg/t3code/issues/1978 showed. Nothing in those paths says which install is stable, so this PR leaves that order alone.
• A stable install that is not on PATH at all still loses to a prerelease one on PATH. The install-folder fallback only runs when no zed is on PATH, as before.
• Nothing on screen changes. The fix only changes which executable the server starts.

Prior PRs

• https://git.cafe/pingdotgg/t3code/pulls/9501 by EzraBuild made this fix with native Windows evidence and the same selection rule. This PR rebuilds that rule on current main, shares the PATH walk with resolveCommandPath instead of copying it, and keeps one test in the existing launcher test file.
• https://git.cafe/pingdotgg/t3code/pulls/2066 by srothgan, the issue's reporter, first fixed this. It was closed in backlog cleanup.

Generated with Claude Opus 5.5 in T3 Code Nightly

Fixes #1978

[macroscopeapp]

Approvability

Verdict: Approved at 076fc4f

Macroscope's review found this PR approvable — This is a narrowly scoped Windows Zed resolution fix that selects stable Zed when a prerelease executable appears first on PATH, while preserving existing behavior for other editors and single-install cases. The shared PATH refactor retains the prior first-match semantics and is covered by targeted tests.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The change adds an API to collect ordered PATH matches and updates Windows Zed resolution to prefer a stable install over Nightly or Preview. A parameterized launch test covers stable selection and fallback when the stable executable is removed.

Changes: Windows Zed selection

Layer / File(s)	Summary
Collect ordered PATH matches packages/shared/src/shell.ts	A shared scanner collects executable paths in PATH order. The existing single-match resolver uses this scanner, and the new resolveCommandPaths API returns all matches without caching the scan.
Prefer stable Zed on Windows packages/shared/src/editor.ts, apps/server/src/process/externalLauncher.test.ts	Windows Zed resolution prefers the first non-prerelease path and falls back to the first match. Tests cover Nightly and Preview directory names, including fallback to the command name when the stable executable is removed.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Low

Suggested labels: bugfix, size:M

Suggested reviewers: maria-rcks

Merge Risk: Minimal · up to 076fc

The Windows stable-Zed selection is ready to merge after normal checks.

Pre-merge checks: 3 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Description check		The description covers the problem, change, scope, and verification. However, the required maintainer approval of the stable-first selection rule is not provided; the author states that the decision r…	Add a link to a maintainer comment that explicitly approves the stable-first selection rule and the PR scope. If approval has not been given, obtain it before treating this requirement as complete.

Passed checks: 3 passed

Check name	Status	Explanation
Title check		The title clearly describes the primary change: opening stable Zed when a prerelease installation appears first on Windows PATH.
Linked Issues check		[#1978] The issue requires that choosing generic Zed on Windows open stable Zed when stable and a prerelease build are both on PATH. The change in packages/shared/src/editor.ts adds a win32-only branc…
Out of Scope Changes check		All source changes relate to the Windows Zed selection objective of #1978. editor.ts: the new isPrereleaseZedPath helper and the win32 zed branch in resolveEditorCommand. The other editors and macOS k…

Full details: Linked Issues check

Explanation

[#1978] The issue requires that choosing generic Zed on Windows open stable Zed when stable and a prerelease build are both on PATH. The change in packages/shared/src/editor.ts adds a win32-only branch for editor id zed. It collects every PATH match for each configured command (zed, zeditor) through resolveCommandPaths. It then picks the first match whose nearest Zed-named install folder does not contain 'nightly' or 'preview'. If the stable pick is the first match, the launcher uses the command name. If it is a later match, the launcher uses the absolute path. This covers the issue's steps, where both zed and zeditor are on PATH and Nightly is listed first. The launcher test named in the PR description covers Nightly-first and Preview-first PATH orders. Those test results come from the PR description and images. The test file diff could not be read, so the test content is not verified from source. The issue does not require tests, so this does not change the verdict. The macOS and Linux paths are unchanged. Stable Zed absent from PATH is not in the issue scope, because the issue requires both installs on PATH.

Full details: Out of Scope Changes check

Explanation

All source changes relate to the Windows Zed selection objective of #1978. editor.ts: the new isPrereleaseZedPath helper and the win32 zed branch in resolveEditorCommand. The other editors and macOS keep the existing isCommandAvailable flow. shell.ts: the PATH walk moves into findOnPath. resolveCommandPathForPlatform calls it with limit 1 and keeps its cache and null-caching behavior. The new exported resolveCommandPaths reuses the same walk with an unlimited match count and does not cache. This refactor supports the new selection logic and does not change existing resolveCommandPath results. The launcher test file change supports the objective. The PR description states that the spawn environment, macOS, and Linux are not changed. The diff for editor.ts and shell.ts shows no edits to those areas. The test file diff could not be read, so its exact contents are not verified from source. No unrelated change was found in the readable diffs.

Full details: Description check

Explanation

The description covers the problem, change, scope, and verification. However, the required maintainer approval of the stable-first selection rule is not provided; the author states that the decision remains open.

Resolution

Add a link to a maintainer comment that explicitly approves the stable-first selection rule and the PR scope. If approval has not been given, obtain it before treating this requirement as complete.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: eabcfa2
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 2fb49c54-6559-44fe-9a9c-bb58d6eb43ca

Commits

Reviewing files that changed from the base of the PR and between eabcfa2 and 076fc4f.

Files selected for processing: 3

• apps/server/src/process/externalLauncher.test.ts
• packages/shared/src/editor.ts
• packages/shared/src/shell.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

updated the original branch at 03a458db1ca74ca93fa91a0830d94b847fe01058. thanks @only21mil for the focused fix and regression cases.

• preserved both contributor commits and merged github/main (cc0b86ddf12a), resolving the shell comment conflict while retaining main's changes.
• kept the original selection rule and shared path scanner. shortened comments and added stable-first coverage to the existing regression test. no new test files or client changes.
• confirmed main's editor resolver fails both preview/nightly regression cases: it returns zed where the stable executable's absolute path is required. the candidate passes both, plus stable-first and prerelease-only fallback.
• blacksmith verification passed: 22 launcher tests; 40 shell tests, with 2 existing skips; vp run check:changed including format, lint, knip, graphql, affected typechecks, and nearby tests.
• all 27 ci checks are green, with no merge conflict. two independent reviews of this exact head found no issues.

unverified: native windows launch and browser-to-windows integration on this linux vm. the original windows evidence remains in the description; i have not reproduced it here. coderabbit's automatic update hit its review limit, so its earlier approval does not cover this head.

the remaining maintainer decision is unchanged: should generic "zed" prefer stable when preview or nightly comes first on path? this branch implements stable-first. it preserves command-name launch when the preferred install is already first, and falls back to prerelease when stable is absent.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

checked github/main at 9bc4138923481dcada7f90d97ecaf0c42184bd4f, then the exact pr head 03a458db1ca74ca93fa91a0830d94b847fe01058 on this linux boat vm. installed dependencies with vp i on each. ran the dev servers sequentially, using separate data directories. drove the real web clients with the repo's playwright dependency and /usr/bin/google-chrome.

• added /home/user/t3code, a real git repository, through the app's local-folder flow. created a thread and completed a real codex gpt-6.1-sol turn on each revision. both read package.json and returned @t3tools/monorepo and node engine 26.12.1. no replay provider, seeded conversations, or mocked runtime.
• installed real linux zed 1.25.3. main's "open in zed" started it, and zed's log recorded opening /home/user/t3code/.git and rendering its first frame. the pr still discovered zed; its launch button and ctrl+o path returned "opened in zed". captured the real websocket request and successful response below. this is linux regression coverage, not proof of windows channel selection.
• the pr's integrated terminal executed git rev-parse --short HEAD && node --version, returning 03a458db1c and v24.22.1.
• blacksmith ran the existing launcher and shell tests: 62 passed, two existing skips. these include simulated windows channel cases; they do not replace native verification. the pr currently reports 29 successful ci contexts and no failing or pending contexts. no source changes or pushes were needed.

short runtime transcript:

web client -> running pr server:
{"_tag":"Request","id":108,"tag":"shell.openInEditor","payload":{"cwd":"/home/user/t3code","editor":"zed"}}
server -> web client:
{"_tag":"Exit","requestId":108,"exit":{"_tag":"Success","value":null}}

zed 1.25.3, launched from main:
[workspace] Rendered first frame
[git::repository] opening git repository at "/home/user/t3code/.git"

blacksmith:
vp test run apps/server/src/process/externalLauncher.test.ts packages/shared/src/shell.test.ts
2 files passed; 62 tests passed; 2 skipped

pr linux editor picker and shortcut interaction, seven seconds. playback and seeking checked after upload:

real codex response and terminal output on the exact pr head:

Not verified

the changed behavior is windows-only. this vm cannot reproduce main opening windows preview/nightly ahead of stable or prove the pr selects stable on windows. stable-first, prerelease-only fallback, native windows process creation, and windows paths containing spaces remain unverified through a native client/server flow. the original contributor's windows captures were not reproduced here. macos, electron, and native ios/android were not exercised.

linux zed opened the project but displayed first-run keyring and software-gpu dialogs. i left the keyring untouched, so full editor usability is unverified. this screenshot records that limit:

the first pr startup briefly selected the root checkout's shared home; i stopped it when the startup log revealed that and restarted with explicit --home-dir /home/user/t3code/.t3. the reported pr interactions used the isolated server.

result: unverifiable for the windows fix on this linux vm. the exercised linux paths passed. no claim that passing tests or ci proves the fix works on windows.

media limitation: git.cafe renders these external media embeds as text links. i opened the uploaded files directly and verified both images and video playback/seeking. its native attachment upload returned http 409 (stale-operation, request 59a604c889ff522f0ae5e98def0c6cc4), so inline media rendering in the pr comment remains unverified.

[only21mil]

Note

🤖 Opus 5.5 replying on behalf of Victor.

@maria-rcks, main now conflicts with this branch in packages/shared/src/editor.ts. I merged current main into your head 03a458db1c as one merge commit, 87cdaa270e. It fast-forwards your head, and I didn't push it here.

• Fork branch: fix/i1978-windows-open-in-zed-opens-zed-nightly-in-offer on only21mil/t3code
• To take it: git fetch https://github.com/only21mil/t3code fix/i1978-windows-open-in-zed-opens-zed-nightly-in-offer && git merge --ff-only FETCH_HEAD

What it changes:

• Main's Linux zeditor preference (fix(shared): Open in Zed prefers zeditor over the ZFS zed on Linux #23416) now sits beside the Windows Zed branch. The resolution line is } else if (!preferBundle && !preferZeditor) {. Windows takes the stable-first path, and Linux still skips the bare zed lookup and tries zeditor first.
• shell.ts and the launcher test merged cleanly. The extracted PATH walk still matches main's current loop.
• Nothing was dropped, since main doesn't cover the Windows case.

Verification on 87cdaa270e:

• externalLauncher.test.ts: 28 passed. shell.test.ts: 68 passed, 2 skipped. vp run check:changed passed.
• With main's editor.ts and shell.ts and this test, both Windows cases fail (expected 'zed' to equal '…/Programs/Zed/bin/zed.EXE'). With the merge, they pass.

What it doesn't settle: whether generic "zed" should prefer stable, which is still your call. I didn't re-run the native Windows check, and nothing on screen changes.

Happy to push it to this PR's branch if you'd like.