[Bug]: Open in Zed fails for Windows remote projects on non-system drives (macOS client)

Before submitting

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

Area

packages/contracts or packages/shared

Steps to reproduce

Use T3 Code Nightly on macOS connected to a Windows environment with a project on the E: drive, e.g. E:\src\example-project.
Configure working SSH access from the Mac to Windows. Zed can authenticate and start its Windows remote server.
Choose Open in Zed for that remote project in T3.

Expected behavior

Zed opens the project on the correct Windows drive over SSH.

Actual behavior

The project does not open. Zed's remote server rejects /E:/src/example-project. Repeated opening also displayed “Waiting for existing connection attempt…”. The path rejection is confirmed; its relationship to the later waiting state has not been established separately.

SSH authentication and remote-server startup succeeded before the path error.

Code investigation

This appears to be the non-system-drive case left unresolved by #11044, related to #8938.

In buildRemoteOpenUrl, backslashes become slashes and a leading slash is added. The Zed branch strips the drive prefix only for C: paths; its comment explicitly leaves other drives untested. An E: path consequently produces:

zed://ssh/<ssh-host>/E%3A/src/example-project

Zed's SSH URL parser passes url.path() into parse_file_path, which URL-decodes and stores the path without removing the leading slash. This agrees with the installed Zed's logs. This is source inspection of current upstream code, not a build of either repository.

Please investigate a supported non-system-drive handoff, potentially in coordination with Zed. Simply dropping E: would lose the intended drive and is not a verified solution.

Searched existing T3 issues and PRs for Zed + Windows; found #8938 and merged #11044, but no matching dedicated report in that search.

Impact

Major degradation or frequent failure

Version or commit

Installed T3 Nightly: 0.0.43-nightly.20260925.2237; source inspected: 1c12706

Environment

macOS 27.0 client; Zed 1.21.0 (20260923.151803); Windows x86_64 remote, OS 10.0.26200 per Zed logs; OpenSSH_for_Windows_9.5.

Logs or stack traces

# Project directory name anonymized below; error text otherwise unchanged.
server:error handling message. type:AddWorktree, error:DevServerProjectPathDoesNotExist path=/E:/src/example-project
Failed to open project: RPC request AddWorktree failed: DevServerProjectPathDoesNotExist path=/E:/src/example-project

Screenshots, recordings, or supporting files

No response

Workaround

Verified: cancel the failed attempt, use Zed's Remote Projects picker, connect to the same SSH host, and enter E:\src\example-project directly. The project opens and the remote file tree is visible.

Confirmed on 1c127066 (current main). Nightly 0.0.43 already contains the C: handling from #11044, so this is the non-system-drive case that PR left open, not a stale install and not a duplicate of #8938 or #11044.

buildRemoteOpenUrl only strips a drive letter for C: / c:. An E:\src\example-project path stays rooted and is encoded as zed://ssh/<host>/E%3A/src/example-project:

t3code/packages/contracts/src/editor.ts

Lines 125 to 132 in 1c12706

    
           if (input.editor === "zed") { 
        
             // Zed's remote server resolves a rooted path on the system drive, so a 
        
             // Windows `C:\Users\x` must become `/Users/x` (verified in #8938). Other 
        
             // drives are untested and kept as is rather than silently remapped, and a 
        
             // POSIX path that happens to start with `/C:` is left alone. 
        
             const zedPath = /^[Cc]:[\\/]/.test(input.absolutePath) ? rootedPath.slice(3) : rootedPath; 
        
             const encodedZedPath = zedPath.split("/").map(encodeURIComponent).join("/"); 
        
             return `${scheme}://ssh/${encodedHost}${encodedZedPath}`;

That matches the log. Zed turns zed://ssh into an ssh:// URL and stores url.path() after one decode, without removing a leading slash:

https://github.com/zed-industries/zed/blob/f8adffe9d145dc1d5ea693723a8e74959cc64684/crates/zed/src/zed/open_listener.rs#L168-L170
https://github.com/zed-industries/zed/blob/f8adffe9d145dc1d5ea693723a8e74959cc64684/crates/zed/src/zed/open_listener.rs#L317-L319

The Windows remote server then canonicalizes /E:/src/example-project and returns DevServerProjectPathDoesNotExist. The path that works from Zed's own Remote Projects picker is E:\src\example-project, with no leading slash. zed://ssh/<host>/<path> cannot produce that string: the parser always takes url.path(), which starts with /.

Stripping E: the way C: is stripped would open C:\src\example-project, not the project on E:. VS Code's /E:/... form is a different link shape and is not what Zed's remote server accepts. The desktop allowlist is not involved: %3A is not a raw colon, so zed://ssh/<host>/E%3A/... is handed to the OS handler. SSH auth succeeding before the path error matches that.

"Waiting for existing connection attempt…" is Zed reusing an in-flight SSH connect for the same host (ConnectionPool in remote_client.rs). It shows up on a second open while the failed attempt is still connecting. It is not a separate T3 path bug.

#13636 touches this builder for Tailscale SSH logins and does not change drive-letter handling.

A T3-only rewrite of the URL does not have a verified target until Zed treats /X:/... as X:\... (or otherwise accepts a drive-qualified path that url.path() can express). After that, the URL T3 already emits for non-C: drives should be the right handoff, and the C: special case can be revisited. The picker workaround in the report is the right one until then.

Navigation Menu

Repository navigation

[Bug]: Open in Zed fails for Windows remote projects on non-system drives (macOS client) #13637

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Code investigation

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	if (input.editor === "zed") {
	// Zed's remote server resolves a rooted path on the system drive, so a
	// Windows `C:\Users\x` must become `/Users/x` (verified in #8938). Other
	// drives are untested and kept as is rather than silently remapped, and a
	// POSIX path that happens to start with `/C:` is left alone.
	const zedPath = /^[Cc]:[\\/]/.test(input.absolutePath) ? rootedPath.slice(3) : rootedPath;
	const encodedZedPath = zedPath.split("/").map(encodeURIComponent).join("/");
	return `${scheme}://ssh/${encodedHost}${encodedZedPath}`;

[Bug]: Open in Zed fails for Windows remote projects on non-system drives (macOS client) #13637

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Code investigation

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Activity

juliusmarminge commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions