Closes#50536
## Summary
Addresses https://github.com/zed-industries/zed/issues/50536
- On macOS, `posix_spawnp` resolves programs against the parent
process's `cwd` and `environ` (via `getcwd` and `getenv("PATH")`),
ignoring the child's `current_dir` and `envp`. This causes two classes
of failures when Zed spawns external commands via the custom
`posix_spawnp`-based `Command`:
- **Bare names** (e.g. `"black"`): resolved via the parent's `PATH`, not
the child's — binaries only available in a project-specific PATH
(Nix/direnv) are not found.
- **Relative paths** (e.g. `"./script.sh"`, `"bin/test.sh"`): resolved
against the parent's `cwd`, not `current_dir` — only works when Zed's
cwd happens to match the project root.
- Added program resolution in `spawn_posix_spawn`
(`crates/util/src/command/darwin.rs`): before calling `posix_spawnp`,
resolve the program to an absolute path — bare names via
`which::which_in` against the child's PATH, relative paths via
`Path::join(current_dir)`. Falls back to the original program if
resolution fails.
## Root Cause
Apple's Libc implementation of `posix_spawnp` resolves the program path
using the parent process's context — `getcwd()` for relative paths and
`getenv("PATH")` for bare names — rather than the `current_dir` (set via
`posix_spawn_file_actions_addchdir_np`) or `envp` argument. The child's
working directory and environment only take effect **after** the binary
has already been located. This is a well-documented macOS behavior that
Rust's own `std::process::Command` works around by bypassing
`posix_spawn` when PATH is modified (see
[rust-lang/rust#48624](https://github.com/rust-lang/rust/pull/48624)).
The regression was introduced when PR #49090 switched macOS from
`std::process::Command` (which uses fork+execvp, correctly using the
child's cwd and PATH) to a custom posix_spawnp-based implementation
(which does not).
## Testing
- `test_bare_program_resolved_via_custom_path` — bare name resolves via
child's custom PATH
- `test_bare_program_with_custom_path_falls_back_when_not_found` —
non-existent binary still errors
- `test_bare_program_with_custom_env_no_path_key` — custom env without
PATH key falls back gracefully
- `test_relative_path_skips_resolution` — relative path resolves against
`current_dir` instead of parent's cwd
Note: The fix and tests are in `darwin.rs` which is macOS-only. The
Linux path uses `smol::process::Command` (via fork+execve) and is
unaffected.
Self-Review Checklist:
- [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:
- Fixed external formatters and language servers failing to launch on
macOS when specified as a bare binary name or relative path and only
available in the project's PATH (e.g. Nix, direnv)
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
I asked Claude Fable 5 to review our macOS process spawning layer, and
it found two notable bugs:
- We didn't mark stdio descriptors as inherited when the `Inherit`
option was passed. This means they would be closed in the child due to
`POSIX_SPAWN_DEFAULT_CLOEXEC`. Now we correctly mark them as inherited.
- Child processes were inheriting Rust's default `SIG_IGN` disposition
for `SIGPIPE`. `std::process::Command` resets the disposition to
`SIG_DFL` for children, and this PR makes us do that too, with a
regression test.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Wrap the fds returned by `create_pipe` and `open_dev_null` in
`std::fs::File` earlier, so that they are closed if we return early due
to an error. Includes a regression test.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed a file descriptor leak on macOS.
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
When restarting Zed, I hit a bug where all Git operations were hung. I
realized that there was a hanging git process running `git cat-file
--batch-check=%(objectname)`. The process was waiting on stdin. This was
surprising, because [the
code](https://github.com/zed-industries/zed/blob/e2bbdb19b6da2ee157ca1d36100acde2134a1663/crates/git/src/repository.rs#L1665-L1709)
that spawns this process explicitly closes the pipe that is attached to
the process's stdin after writing a list of ref names.
Using Claude, I found that this could be caused by that pipe file
descriptor being cloned due to file descriptor inheritance when another
child process is `exec`'d while that stdin pipe is open. The fix is to
enhance our Darwin process spawning layer to set the close-on-exec flag
for the pipe file descriptors, so that they are not inherited by child
processes spawned using code paths that don't set
`POSIX_SPAWN_CLOEXEC_DEFAULT`.
Release Notes:
- Fixed a bug on macOS where Git operations could be blocked depending
on the timing of spawning child processes.
## 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>
