repl: Add WSL and SSH remote kernel support by MostlyKIGuess · Pull Request #47891 · zed-industries/zed

MostlyKIGuess · 2026-01-28T18:30:22Z

fix: notebook_ui, use buffer so that notebooks open in remote/WSL settings.
fix: add musl in nix for cross-compilation, without this remote server doesn't build inside NixOS

Release Notes:

Implement WSL and SSH remote kernels (crates/repl/src/kernels/*) and wire up spawn/kill kernel proto messages and client requests.

- Implement WSL and SSH remote kernels (crates/repl/src/kernels/*) and wire up spawn/kill kernel proto messages and client requests. - fix: notebook_ui, use buffer so that notebooks open in remote/WSL settings. - fix: add musl in nix for cross-compilation, without this remote server doesn't build inside NixOS

- remove unused worktree_store - change smol timer to cx.background_executor - on_action listeners using _: &ActionType instead of &ActionType which was being interpreted as variable binding - removed useless Entity::from() in sessions.rs

rgbkrk · 2026-01-28T20:08:39Z

crates/project/src/toolchain_store.rs

                })
-                .await
-                .log_err()?;
+                .await;


This could all be

.await .inspect_err(|e| { log::warn!( "RemoteToolchainStore::list_toolchains: RPC failed for language {}: {:?}", language_name, e ); }) .ok()?;

rgbkrk · 2026-01-28T20:11:36Z

crates/remote_server/src/headless_project.rs

+            Some(envelope.payload.working_directory)
+        };
+
+        // Spawn kernel (Assuming python for now, or we'd need to parse kernelspec logic here or pass the command)


True, we're probably going to have to provide the listing based on what's available on the remote as well as be able to launch using those as well.

I was hesitant to wire up full remote kernel discovery for now, felt like it might bloat this PR too much.
Do you think we should block this until we have proper spec listing, or is the python3 fallback okay for an initial merge?

Note that python3 won't work on windows by default as its just python there

rgbkrk · 2026-01-28T20:13:55Z

crates/repl/src/kernels/mod.rs

            .map(|toolchain| {
                background_executor.spawn(async move {
+                    // For remote projects, we assume python is available assuming toolchain is reported.
+                    // We can skip the `ipykernel` check or run it remotely.


We probably do still need to do some kind of ipykernel check. I think in some cases people want the same flow as VS Code where they can install ipykernel. That doesn't always work in every env (oddly even in my uv sync created venvs it has trouble).

Should we add a prompt to install ipykernel if the selected kernel is missing it? that sort of reflects the notification workflow from VSCode.. I would want to investigate why it's not working on uv venv..

I'm sorry I meant that VS Code runs into a problem with a fresh uv sync'ed repo and is unable to install into it. Maybe VS Code has to detect that it's a uv backed repo that needs to use uv pip install ipykernel (or uv add if intended to be kept).

rgbkrk · 2026-01-28T20:15:44Z

crates/repl/src/kernels/ssh_kernel.rs

+                    }
+                }
+            })
+            .detach();


This again reminds me we need .split() on zmq.rs so we don't have to create so many background processes and can send while receiving on all the channels.

Yeah, had to fight socket ownership here, once zmq adds split this would allow us to drop multiple spawners

I started on that here: zeromq/zmq.rs#194

Probably easier to maintain in runtimed, zmq.rs, and even Zed to just use the Tokio setup that Zed now has inside (my work predates that).

.split() is now supported in here as of #48823 so this should nicely clean up.

Veykril

This does not seem to support docker and also I don't quite understand why we have to special case between different remote types here. Ideally all the specifics of ssh and wsl should be hidden away behind our RemoteConnectionOptions and such. (I have only skimmed over the ssh/wsl modules here for now, so do tell the reasons for the split here)

I am also confused by the fact that we now have a Remote variant but also an ssh and wsl remote variant each

Veykril · 2026-01-29T08:36:07Z

crates/project/src/toolchain_store.rs

-                .log_err()?;
+                .inspect_err(|e| {
+                    log::warn!(
+                        "RemoteToolchainStore::list_toolchains: RPC failed for language {}: {:?}",
+                        language_name,
+                        e
+                    );
+                })
+                .ok()?;


This should remain a log_err imo

Veykril · 2026-01-29T08:37:47Z

crates/remote_server/src/headless_project.rs

+            Some(envelope.payload.working_directory)
+        };
+
+        // Spawn kernel (Assuming python for now, or we'd need to parse kernelspec logic here or pass the command)


Note that python3 won't work on windows by default as its just python there

Veykril · 2026-01-29T08:39:37Z

crates/remote_server/src/headless_project.rs

+        let child = this.update(&mut cx, |this, _| this.kernels.remove(&kernel_id));
+        if let Some(mut child) = child {
+            child.kill().log_err();
+            let _ = child.status().await; // Perhaps kill should be enough, should we wait?


kill should suffice, no need to wait since we don't make any use of the return value here

Alright, I will remove this

Handled the python3 by having both python and python3 and removed this

Veykril · 2026-01-29T08:40:06Z

crates/repl/src/components/kernel_options.rs

+            KernelSpecification::SshRemote(_) => (kernelspec.name(), "SSH Remote", None),
+            KernelSpecification::WslRemote(_) => (kernelspec.name(), "WSL Remote", None),


Why are these separate from Remote?

MostlyKIGuess · 2026-01-29T09:41:20Z

This does not seem to support docker and also I don't quite understand why we have to special case between different remote types here. Ideally all the specifics of ssh and wsl should be hidden away behind our RemoteConnectionOptions and such. (I have only skimmed over the ssh/wsl modules here for now, so do tell the reasons for the split here)

I am also confused by the fact that we now have a Remote variant but also an ssh and wsl remote variant each

Yeah, the naming is a bit overloaded right now.

The simpler mental model I have right now is:

KernelSpecification::Remote - This refers to a Jupyter Server which will be HTTP/WebSocket connection, further used to connect to an existing local/remote JupyterLab instance. We can probably rename it to JupyterServer to avoid confusion with Zed's "Remote Projects"
SSH vs WSL: SshRunningKernel mostly holds a network client while WslRunningKernel holds the execution logic which acts as a process wrapper. I experimented a bit with this in the feature/repl-ssh branch of mine before making this PR..this allows us to directly make use of WSL2's localhost forwarding rather than SSH tunnels.

While we can do this under the same RemoteConnectionOptions because the underlying implementation paths are distinct enough, ( RPC vs Command::new('wsl')), I thought the separation variation would be cleaner.

For the docker support, I was planning for a follow=up PR to keep this one focused to the issues on getting WSL stable first. Implementation for docker should mirror the WSL approach.

I can change the KernelSpecification::Remote to JupyterServer for a clearer distinction.

And to answer the
#47891 (comment)

Why are these separate from Remote?

This ties back to the above discussion where because SshRemote and WslRemote are managed processes, they don't have a URL to show the user. Essentially the Remote here would mean to connect a "Jupyter Server via HTTP/WebSocket" which is why it also has the URL. But Ssh and Wsl Remote refer to the kernels managed by Zed ( via SSH RPC or WSL Process ).

Renaming Remote to JupyterServer would make this more clear..

MostlyKIGuess · 2026-01-29T09:50:51Z

Also one more question.. when you say docker you mean the new Dev Containers support right?
Related Blog: https://zed.dev/blog/dev-containers

Veykril · 2026-01-29T09:58:51Z

Yea lets rename that variant then, and yes i the dev-containers. Absolutely fine to keep that out of this PR for now though

MostlyKIGuess · 2026-01-29T17:21:42Z

Changed the original body to not reflect the NixOS dev build fix and Jupyter View additions as they are dev and behind feature flag respectively.

rgbkrk · 2026-01-29T19:48:04Z

KernelSpecification::Remote - This refers to a Jupyter Server which will be HTTP/WebSocket connection, further used to connect to an existing local/remote JupyterLab instance. We can probably rename it to JupyterServer to avoid confusion with Zed's "Remote Projects"

Let's incorporate JupyterHTTPServer into the naming so it's clear what it's connecting to, since they can be doing it locally or in the cloud. That way remote refers to the Zed concept of it.

Replace manual starts_with/slicing with strip_prefix when detecting \\wsl$ and \\wsl.localhost UNC prefixes

MostlyKIGuess · 2026-01-30T08:30:42Z

Not sure why the remote.workspace error was present, we do need it when using repl over ssh.

- Instead of relying on python and python3, using toolchain path to get the proper envrionment - update with the new repl menu in remote as well

Veykril

one more thing but other lgtm

Veykril · 2026-02-20T07:33:06Z

crates/remote/src/transport/ssh.rs

+                "-o".to_string(),
+                "BatchMode=yes".to_string(),
+                "-o".to_string(),
+                "ConnectTimeout=10".to_string(),


I worry about this change, we haven't needed this until now for anything else in the ssh layer so I fear this may cause unexpected issues. Do we need this?

hmm, I kept this as my connection was unstable, not sure if we need it. Anyhow, if the kernel hangs, we can handle timeouts at the SshRunningKernel level later. I was able to make it work without it anyways

Veykril · 2026-02-20T07:36:54Z

crates/zed/src/zed/quick_action_bar/repl_menu.rs

-            .map(|workspace| workspace.read(cx).project().read(cx).is_local())
+            .map(|workspace| {
+                let project = workspace.read(cx).project().read(cx);
+                project.is_local() || project.is_remote()


This is always true as is_remote is just !is_local, I think you want !project.is_via_collab() (the methods here need some better documentation ....)

Yeah, thank you for this! Merged laxly when repl menu was added to upstream, didn't realize this was A or not A by making this.

will make the same changes on repl session UI as well

previous check on menu logic was A or not A, allow changing for when not via collab revert back SSH args, if kernel suffers hangs, will handle this in SshRunningKernel

Veykril

Thanks!

MostlyKIGuess · 2026-02-27T10:35:19Z

btw @Veykril, I was going through the remoting 1.0 notes and dev-containers notes before actually starting on Dev Containers implementation. A lot of what I'll have to do will need to answer some of the open questions in those notes on how to go about this, would you be free to discuss an approach?

Port handling is the core piece here and from the notes it looks like it could be some effort just to break the DevContainer CLI dependency before we can even get to the forwarding itself. I'd rather have team consensus on that before implementing anything. Could also just break it down into smaller PRs targeting the noted issues you have first and later on bring the Python kernel once the ground is solid.

cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Jan 28, 2026

MrSubidubi changed the title ~~repl: add WSL and SSH remote kernel support~~ repl: Add WSL and SSH remote kernel support Jan 28, 2026

MrSubidubi assigned rgbkrk Jan 28, 2026

MostlyKIGuess marked this pull request as draft January 28, 2026 18:37

Fix Clippy warnings

b521d85

- remove unused worktree_store - change smol timer to cx.background_executor - on_action listeners using _: &ActionType instead of &ActionType which was being interpreted as variable binding - removed useless Entity::from() in sessions.rs

MostlyKIGuess marked this pull request as ready for review January 28, 2026 19:01

rgbkrk mentioned this pull request Jan 28, 2026

repl: Add quality of life changes in Jupyter view #47533

Merged

rgbkrk reviewed Jan 28, 2026

View reviewed changes

use inspect_err

05981a6

Veykril reviewed Jan 29, 2026

View reviewed changes

MostlyKIGuess added 4 commits January 29, 2026 15:38

revert to log_err()

2a0c3d3

try python3 then python when spawning kernel

368363f

Rename KernelSpecification::Remote to JupyterServer

c105776

Merge remote-tracking branch 'upstream/main' into feature/clean-repl-ssh

e9d6f27

Handle WSL paths with strip_prefix

aa4f15c

Replace manual starts_with/slicing with strip_prefix when detecting \\wsl$ and \\wsl.localhost UNC prefixes

MostlyKIGuess added 5 commits January 31, 2026 01:02

add cargo-machete to ignore remote

f3a93c4

Merge remote-tracking branch 'upstream/main' into feature/clean-repl-ssh

29ce0bf

Merge remote-tracking branch 'upstream/main' into feature/clean-repl-ssh

1b5f6e4

Remove unnecessary kernel status await

7d1df1b

Remove remote being ignored..

f5f8c80

MostlyKIGuess added 4 commits February 13, 2026 14:02

Merge upstream handle remote repl with precision

dde8521

- Instead of relying on python and python3, using toolchain path to get the proper envrionment - update with the new repl menu in remote as well

Merge upstream and add peer identity to ssh,wsl

e877f2c

style

f44d340

unnecessary indent

a513d95

MostlyKIGuess force-pushed the feature/clean-repl-ssh branch 2 times, most recently from e0114fd to 022816b Compare February 13, 2026 10:12

indent fixes

5da69e6

MostlyKIGuess force-pushed the feature/clean-repl-ssh branch from 022816b to 5da69e6 Compare February 13, 2026 10:13

MostlyKIGuess marked this pull request as ready for review February 13, 2026 12:23

merge upstream

79c8194

MostlyKIGuess marked this pull request as draft February 14, 2026 20:21

MostlyKIGuess added 5 commits February 15, 2026 02:20

Merge remote-tracking branch 'upstream/main' into feature/clean-repl-ssh

697c004

chore: misplaced current max

add1ca8

typo

8a2174d

ensure correct python path

9a2d661

style

b5ee08e

MostlyKIGuess marked this pull request as ready for review February 14, 2026 21:48

Merge remote-tracking branch 'upstream/main' into feature/clean-repl-ssh

1de16ef

Veykril self-assigned this Feb 20, 2026

Veykril reviewed Feb 20, 2026

View reviewed changes

adjust SSH args and REPL menu logic

6d31c2d

previous check on menu logic was A or not A, allow changing for when not via collab revert back SSH args, if kernel suffers hangs, will handle this in SshRunningKernel

Veykril enabled auto-merge (squash) February 20, 2026 08:16

Veykril approved these changes Feb 20, 2026

View reviewed changes

MostlyKIGuess added 2 commits February 20, 2026 13:53

repl sessions ui only for non collab

6c482d7

use updated new_command

0a0cb6d

auto-merge was automatically disabled February 20, 2026 08:42
Head branch was pushed to by a user without write access

Veykril enabled auto-merge (squash) February 20, 2026 09:24

Veykril merged commit ae9bb6a into zed-industries:main Feb 20, 2026
27 checks passed

XanderChen0530 mentioned this pull request Mar 2, 2026

REPL: R/ark kernel crashes in WSL remote mode (env treated as args + SIGABRT) #50459

Closed

		KernelSpecification::SshRemote(_) => (kernelspec.name(), "SSH Remote", None),
		KernelSpecification::WslRemote(_) => (kernelspec.name(), "WSL Remote", None),

Uh oh!

Conversation

MostlyKIGuess commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Veykril left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MostlyKIGuess commented Jan 29, 2026

Uh oh!

MostlyKIGuess commented Jan 29, 2026

Uh oh!

Veykril commented Jan 29, 2026

Uh oh!

MostlyKIGuess commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rgbkrk commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MostlyKIGuess commented Jan 30, 2026

Uh oh!

Veykril left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Veykril left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MostlyKIGuess commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

MostlyKIGuess commented Jan 28, 2026 •

edited

Loading

MostlyKIGuess commented Jan 29, 2026 •

edited

Loading

rgbkrk commented Jan 29, 2026 •

edited

Loading