[sergio-u]

When connecting to a Windows host over SSH, the proxy fails to start the daemon and the user sees "failed to spawn server."

Root cause

spawn_server_windows invokes the daemon via shell_execute_from_explorer, which goes through COM ShellWindows / IShellDispatch2::ShellExecute. That path requires both:

• explorer.exe running in the caller's session, and
• an interactive desktop / window station.

Neither is available when zed-remote-server proxy is launched by sshd: sshd-spawned processes live in a non-interactive window station with no Explorer. The COM call fails, the run daemon never starts, the proxy's 10s socket-existence poll times out, and the connection fails.

A commenter on #48966 reports the connection succeeds after first logging in via RDP, which is consistent with this diagnosis: RDP login populates the session with explorer.exe and an interactive window station.

Fix

Replace the COM path with a direct Command::spawn, matching the non-Windows branch. Use DETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP creation flags so the daemon has no inherited console and is not killed by Ctrl+C/Break broadcast to the parent's group when the proxy exits.

Bypass util::new_command because it presets CREATE_NO_WINDOW, which Win32 disallows combining with DETACHED_PROCESS. Drop one layer to smol::process::Command directly to keep the disallowed-methods lint happy.

Also drop the now-unused shell_execute_from_explorer module and the windows crate dependency it pulled in.

No automated test is included: exercising this path requires a headless OpenSSH-Server-on-Windows host with a non-interactive window station, which CI doesn't currently provide. Verified manually that macOS client -> Windows host over SSH establishes the connection successfully where it previously timed out.

Closes #48966

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content is consistent with the UI/UX checklist
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Release Notes:

• Fixed remote server failing to start when connecting to a Windows host over SSH

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @sergio-u on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[sergio-u]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[kevinsanchh]

Just confirming this fix is still needed and very much wanted. On the current stable (Zed v1.15.0, macOS client → Windows host), the old COM/shell_execute_from_explorer spawn path still fails over a fresh SSH session: failed to spawn server, no socket/log files in $LOCALAPPDATA/Zed/. The only workaround remains establishing an interactive logon (RDP) session first — exactly the problem this PR addresses.

This blocks macOS/Linux → Windows remote development entirely until merged. Any chance of getting this reviewed and in? Happy to test a preview build with this change. 👍

[iakovmarkov]

I'm running into this bug on my new development setup as well. Establishing an RDP session first works around it, but it's not exactly ideal...

I'd love to see this PR merged. @reflectronic, is there anything I can do to help move it forward?

I checked the merge conflicts locally, and it looks like Cargo.lock is the only conflicting file. Happy to help resolve that or test the changes on fresh Windows 11 box.

[reflectronic]

Thank you!

[iakovmarkov]

Hell yes, super stoked to see this merged. I'm running a patched build of Zed server on my Windows boxes and it works really well.

Thanks everyone for your work on Zed!

[sergio-u]

Awesome! Thank you for getting this merged