## Summary
- Fix SSH `-L` port-forward arguments to wrap IPv6 addresses in brackets
(e.g. `-L[::1]:8080:[::1]:80`), so SSH can correctly parse them
- Rewrite `parse_port_forward_spec` to support bracket-wrapped IPv6
tokens like `[::1]:8080:[::1]:80`
- Add diagnostic logging for stdin read failures in the remote server to
aid debugging connection issues
Closes#49009
## Test plan
- [x] New unit tests: `test_parse_port_forward_spec_ipv6`,
`test_port_forward_ipv6_formatting`,
`test_build_command_with_ipv6_port_forward`
- [x] Existing tests pass: `cargo test -p remote --lib
transport::ssh::tests` (6/6)
- [ ] Manual verification: connect via SSH to an IPv6 host with port
forwarding configured
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Closes https://github.com/zed-industries/zed/issues/49363
When an existing remote workspace's connection is dead (e.g. the server
died and reconnect failed, leaving the client in `ServerNotRunning`
state), `remote_connection()` returns `None`. Previously this caused an
error dialog, blocking reconnection — the user had to manually switch to
another project and back to recover.
Now the code falls through to establish a fresh connection instead,
matching the previous behavior where clicking "Reconnect" would just
work.
Release Notes:
- Fixed remote reconnect failing with an error when the server is not
running, now establishes a fresh connection instead.
Closes#15196, #46918
- 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.
Replaces a bunch of `impl FnMut` parameters with `&mut dyn FnMut` for
functions where this is the sole generic parameter.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Re-lands https://github.com/zed-industries/zed/pull/48891, which was
reverted due to conflicts with multi-workspace.
Before you mark this PR as ready for review, make sure that you have:
- [X] Added a solid test coverage and/or screenshots from doing manual
testing
- [X] Done a self-review taking into account security and performance
aspects
Release Notes:
- N/A
Here's some backstory:
* on macOS, @cole-miller and I noticed that since roughly Oct 2025, due
to some changes to latest macOS Tahoe, for any spawned child process we
needed to reset Mach exception ports
(https://github.com/zed-industries/zed/issues/36754 +
6e8f2d2ebe)
* the changes in that PR achieve that via `pre_exec` hook on
`std::process::Command` which then abandons `posix_spawn` syscall for
`fork` + `execve` dance on macOS (we tracked it down in Rust's std
implementation)
* as it turns out, `fork` + `execve` is pretty expensive on macOS
(apparently way more so than on other OSes like Linux) and `fork` takes
a process-wide lock on the allocator which is bad
* however, since we wanna reset exception ports on the child, the only
official way supported by Rust's std is to use `pre_exec` hook
* posix_spawn on macOS exposes this tho via a macOS specific extension
to that syscall `posix_spawnattr_setexceptionports_np` but there is no
way to use that via any standard interfaces in `std::process::Command`
* thus, it seemed like a good idea to instead create our own custom
Command wrapper that on non-macOS hosts is a zero-cost wrapper of
`smol::process::Command`, while on macOS we reimplement the minimum to
achieve `smol::process::Command` with `posix_spawn` under-the-hood
Notably, this changeset improves git-blame in very large repos
significantly.
Release Notes:
- Fixed performance spawning child processes on macOS by always forcing
`posix_spawn` no matter what.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Closes#46252
Uses the `remoteUser` property returned from the devcontainer CLI so
that settings are respected. Additionally, checks for a default shell in
`passwd` if `$SHELL` is not set.
Release Notes:
- Fixed remote_user and shell inconsistencies from within dev containers
Closes#46801
When connecting to WSL2 with fish as the default shell, Zed gets stuck
at "Starting proxy". The connection works fine when bash is the default
shell.
In `start_proxy()`, the WSL command was being invoked with:
```rust
let proxy_process = match wsl_command_impl(&self.connection_options, "env", &proxy_args, false)
```
Changing the last argument to true invokes the WSL command with `--exec`
flag which executes the command in the WSL environment without spawning
a new shell.
With above fix I can launch Zed from WSL (Arch) with fish.
## Summary
This PR extends the `always_allow` tool permission patterns to work with
Nushell, Elvish, and Rc shells. Previously, these shells were
incorrectly excluded because they don't use `&&`/`||` operators for
command chaining. However, brush-parser can safely parse their command
syntax since they all use `;` for sequential execution.
## Changes
- Add `ShellKind::Nushell`, `ShellKind::Elvish`, and `ShellKind::Rc` to
`supports_posix_chaining()`
- Split `ShellKind::Unknown` into `ShellKind::UnknownWindows` and
`ShellKind::UnknownUnix` to preserve platform-specific fallback behavior
while still denying `always_allow` patterns for unrecognized shells
- Add comprehensive tests for the new shell support
- Clarify documentation about shell compatibility
## Shell Notes
- **Nushell**: Uses `;` for sequential execution. The `and`/`or`
keywords are boolean operators on values, not command chaining.
- **Elvish**: Uses `;` to separate pipelines. Does not have `&&` or `||`
operators. Its `and`/`or` are special commands operating on values.
- **Rc (Plan 9)**: Uses `;` for sequential execution and `|` for piping.
Does not have `&&`/`||` operators.
## Security
Unknown shells still return `false` from `supports_posix_chaining()`, so
`always_allow` patterns are denied for safety when we can't verify the
shell's syntax.
(No release notes because granular tool permissions are still
feature-flagged.)
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
- Remove the newlines in the unzip command string, which made it not
work.
- Fix spawning the terminal and tasks. Unfortunately, the Windows
OpenSSH server has limitations that require rather ugly workarounds.
Release Notes:
- N/A
When I kill the remote proxy, it seems like `ssh` exits with code -1.
Since that's less than or equal to 0, this means we don't try to restart
the connection. The proxy really shouldn't exit for any reason, so let's
get rid of this check altogether.
Release Notes:
- N/A
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
The client has not yet setup its own side of things so the message will
always error as being unhandled anyways.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Assimilates https://github.com/zed-industries/zed/pull/46856 and adds
support for reveal file manager in the project panel on wsl. Closes
https://github.com/zed-industries/zed/pull/46856
Release Notes:
- Fixed "Reveal in File Manager" not working for WSL remote connections
on Windows.
- Show "Reveal in File Manager" in the project panel context menu on WSL
---------
Co-authored-by: Max Malkin <maxim_malkin@outlook.com>
Follow up to https://github.com/zed-industries/zed/pull/47200, fixing an
edge case where if the heartbeat failure disconnects us we get stuck in
an unconnectable state
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Adds the ability to create a dev container definition from scratch.
Additionally, separates devcontainer logic out into its own crate, since
it was getting sufficiently complex to separate from the
`recent_projects` crate.
A screen recording of the modal experience:
https://github.com/user-attachments/assets/f6cf95e1-eb7b-4ca3-86c7-c1cbc26ca557
Release Notes:
- Added modal to initialize a dev container definition in the project
with `projects: initialize dev container`
- Added podman support for dev container actions with the `use_podman`
setting
- Improved devcontainer error handling
---------
Co-authored-by: Sam Coward <idoru42@gmail.com>
Closes #ISSUE
Moves the settings content definitions into their own crate, so that
they are compiled+cached separately from settings, primarily to avoid
recompiles due to changes in gpui. In that vain many gpui types such as
font weight/features, and `SharedString` were replaced in the content
crate, either with `*Content` types for font/modifier things, or
`String`/`Arc<str>` for `SharedString`. To make the conversions easy a
new trait method in the settings crate named `IntoGpui::into_gpui`
allows for `into()` like conversions to the gpui types in
`from_settings` impls.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Release Notes:
- Opening bundled files, keymap, and local release notes now opens in
remote windows instead of opening a new local zed window
- Opening the settings files, keymap files, task files, debug files and
logs will now open within wsl windows instead of opening a new local zed
window
This pollutes tasks and similar with a `connection closed` message
otherwise.
Release Notes:
- Fixed terminal tool for agents ending with `connection closed` on
remote hosts polluting context
Benchmarks that depend on remote server would not rebuild the remote
server binary outside of dev builds. Let dependants of remote opt into
building the binary even in release builds.
Release Notes:
- N/A
Obviously this doesn't do too much without having an actual windows
server binary for the remote side, but it does at least improve the
error message as right now we will complain about `uname` not being a
valid powershell command.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#33650
Release Notes:
- Added support for remote connections over IPv6
---------
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
Closes#21527
Release Notes:
- Added a setting to specify the ssh connection timeout
---------
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
Partially addresses #11473
MVP of dev containers with the following capabilities:
- If in a project with `.devcontainer/devcontainer.json`, a pop-up
notification will ask if you want to open the project in a dev
container. This can be dismissed:
<img width="1478" height="1191" alt="Screenshot 2025-12-08 at 3 15
23 PM"
src="https://github.com/user-attachments/assets/ec2e20d6-28ec-4495-8f23-4c1d48a9ce78"
/>
- Similarly, if a `devcontainer.json` file is in the project, you can
open a devcontainer (or go the devcontainer.json file for further
editing) via the `open remote` modal:
https://github.com/user-attachments/assets/61f2fdaa-2808-4efc-994c-7b444a92c0b1
*Limitations*
This is a first release, and comes with some limitations:
- Zed extensions are not managed in `devcontainer.json` yet. They will
need to be installed either on host or in the container. Host +
Container sync their extensions, so there is not currently a concept of
what is installed in the container vs what is installed on host: they
come from the same list of manifests
- This implementation uses the [devcontainer
CLI](https://github.com/devcontainers/cli) for its control plane. Hence,
it does not yet support the `forwardPorts` directive. A single port can
be opened with `appPort`. See reference in docs
[here](https://github.com/devcontainers/cli/tree/main/example-usage#how-the-tool-examples-work)
- Editing devcontainer.json does not automatically cause the dev
container to be rebuilt. So if you add features, change images, etc, you
will need to `docker kill` the existing dev container before proceeding.
- Currently takes a hard dependency on `docker` being available in the
user's `PATH`.
Release Notes:
- Added ability to Open a project in a DevContainer, provided a
`.devcontainer/devcontainer.json` is present
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
