## Context
Closes#11473
In-house Zed implementation of devcontainers. Replaces the dependency on
the [reference implementation](https://github.com/devcontainers/cli) via
Node.
This enables additional features with this implementation:
1. Zed extensions can be specified in the `customizations` block, via
this syntax in `devcontainer.json:
```
...
"customizations": {
"zed": {
"extensions": ["vue", "ruby"],
},
},
```
2.
[forwardPorts](https://containers.dev/implementors/json_reference/#general-properties)
are supported for multiple ports proxied to the host
## How to Review
<!-- Help reviewers focus their attention:
- For small PRs: note what to focus on (e.g., "error handling in
foo.rs")
- For large PRs (>400 LOC): provide a guided tour — numbered list of
files/commits to read in order. (The `large-pr` label is applied
automatically.)
- See the review process guidelines for comment conventions -->
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Improved devcontainer implementation by moving initialization and
creation in-house
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 +
https://github.com/RemiKalbe/zed/commit/6e8f2d2ebe5a93753625a3026aeb996de8cb436b)
* 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#48683
Per the devcontainer spec, `.devcontainer.json` in the project root is
a valid config location. It is only used when no configurations are
found inside `.devcontainer/`.
Extract `find_configs_in_snapshot` for testability and add tests.
Release Notes:
- Added support for `.devcontainer.json` in project root
It's happeningggggg
Release Notes:
- Changed the Agent Panel so that the Active Thread is restored on
restart.
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Anthony Eid <anthony@zed.dev>
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
Co-authored-by: Richard Feldman <richard@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Closes#46947
When installed with `npm install -g`, devcontainer gets created as
`devcontainer.cmd`. However, when invoked as a script from node, it's
still `devcontainer.js`. This addresses that difference so that we don't
accidentally invoke `devcontainer.cmd.js`.
Release Notes:
- Fixed devcontainer operation on Windows for when the devcontainer cli
is not installed globally
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#46852
The devcontainer CLI which ships with VS Code can be added to the user's
`PATH` with the VS Code command `Dev Containers: Install devcontainer
CLI`. This version of the CLI is older than what Zed was developed with,
and as a result, it doesn't separate its json-formatted output and its
plaintext metadata into distinct output streams. This broke parsing in
the CLI adapter in Zed. This fix accounts for that, and if parsing
fails, attempts to find a relevant JSON object in plaintext and tries to
parse that.
Tested with VSCode's version of the devcontainer CLI (`0.80.1`) as well
as the up-to-date version (`0.81.1`)
Release Notes:
- Improved parsing of devcontainer CLI output when using earlier
versions
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>
KyleBarton