Disambiguate project names in the sidebar (and project picker) so that
we don't show e.g. `zed, zed` but rather `foo/zed, bar/zed` if the last
path component is the same but they are different absolute paths.
Release Notes:
- N/A
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
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
Implements a basic web platform for the wasm32-unknown-unknown target
for gpui
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: John Tur <john-tur@outlook.com>
Add `agent_worktree_directory` to `GitSettings` for configuring where
agent worktrees are stored (default: Zed data dir). Remove `Copy` derive
from `GitSettings`/`GitContentSettings` (incompatible with String field)
and fix downstream `.as_ref().unwrap()` call sites.
Define `AgentGitWorktreeInfo` (branch, worktree_path, base_ref) and add
it to `DbThread` + `DbThreadMetadata` for persistence and session list
display.
Closes AI-33
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 +
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>
## 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>
Closes#46365
The behavior I'm trying to handle here is documented in
https://man7.org/linux/man-pages/man5/proc_pid_exe.5.html.
[@merlinz01
](https://github.com/zed-industries/zed/issues/46365#issuecomment-3723996684)
points to some other alternatives but they don't seem necessary or
justified here.
# Testing
I've manually replaced the binary of a process running this build, to
simulate an update, and then opened a new tree and I don't see the error
message.
I don't know if there's a reasonable way to unit-test this? Let me know.
It seems like it would require using something like rusty-fork to spawn
a specific binary for the test, which I don't think I see already in the
Zed tree and perhaps it would be overkill to add just for this?
Release Notes:
- Fixed "Failed to load environment variables" after applying an update
Fixes#33958
## Problem
PR #44835 attempted to fix SHLVL starting at 2 by removing it from the
`env` HashMap passed to alacritty. However, that HashMap is only an
**overlay** — alacritty uses the parent process environment as a base
and applies the overlay on top. Since alacritty never calls
`env_remove("SHLVL")`, the terminal shell still inherits `SHLVL` from
Zed's process environment.
## Root Cause
The real issue is in `load_login_shell_environment()`:
1. `shell_env::capture()` spawns a login shell to capture environment
variables
2. That login shell increments `SHLVL` (from 0→1 or n→n+1)
3. The captured env (including the incremented `SHLVL`) is written to
Zed's **process environment** via `env::set_var`
4. When you open a terminal, the shell inherits Zed's `SHLVL` and
increments it again → starts at 2
5. On reload, `shell_env::capture()` runs again with the
already-elevated `SHLVL`, incrementing it further → +2 per reload
## Fix
Skip `SHLVL` when setting Zed's process environment in
`load_login_shell_environment()`. This prevents the login-shell capture
from polluting Zed's env, so terminals start fresh with the correct
`SHLVL`.
Closes#45211
This ensures that all sub-processes that were launched by the ACP server
are terminated. One scenario where this is easily reproducible:
- Start a new Claude Code ACP session
- Submit a prompt
- While Claude-code is still responding, start a new session
- The `claude-code` subprocess is leaked from the previous session (The
Claude-code SDK runs the Claude-code binary in a sub process)
This PR fixes this by using process groups on Unix.
It does not fix the process leaks on Windows yet (will follow up with
another PR)
Release Notes:
- Fixed an issue where subprocesses of ACP servers could be leaked after
starting a new session
## Summary
Follow-up to #40716. This applies the same `reset_exception_ports()` fix
to `set_pre_exec_to_start_new_session()`, which is used by shell
environment capture, terminal spawning, and DAP transport.
### Root Cause
After more debugging, I finally figured out what was causing the issue
on my machine. Here's what was happening:
1. Zed spawns a login shell (zsh) to capture environment variables
2. A pipe is created: reader in Zed, writer mapped to fd 0 in zsh
3. zsh sources `.zshrc` → loads oh-my-zsh → runs poetry plugin
4. Poetry plugin runs `poetry completions zsh &|` in background
5. Poetry inherits fd 0 (the pipe's write end) from zsh
6. zsh finishes `zed --printenv` and exits
7. Poetry still holds fd 0 open
8. Zed's `reader.read_to_end()` blocks waiting for all writers to close
9. Poetry hangs (likely due to inherited crash handler exception ports
interfering with its normal operation)
10. Pipe stays open → Zed stuck → no more processes spawn (including
LSPs)
I confirmed this by killing the hanging `poetry` process, which
immediately unblocked Zed and allowed LSPs to start. However, this
workaround was needed every time I started Zed.
While poetry was the culprit in my case, this can affect any shell
configuration that spawns background processes during initialization
(oh-my-zsh plugins, direnv, asdf, nvm, etc.).
Fixes#36754
## Test plan
- [x] Build with `ZED_GENERATE_MINIDUMPS=true` to force crash handler
initialization
- [x] Verify crash handler logs appear ("spawning crash handler
process", "crash handler registered")
- [x] Confirm LSPs start correctly with shell plugins that spawn
background processes
Release Notes:
- Fixed an issue on macOS where LSPs could fail to start when shell
plugins spawn background processes during environment capture.
Using `shlex` unconditionally is dangerous as it assumes the underlying
shell is POSIX which is not the case for PowerShell, CMD, or Nushell.
Therefore, whenever we want to quote the args we should utilise our
helper `util::shell::ShellKind::try_quote` which takes into account
which shell is being used to actually exec/spawn the invocation.
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
This is a refactoring PR to simplify our environment loading code by:
- Getting rid of `EnvironmentErrorMessage` in favor of using
`anyhow::Result` everywhere, with a separate `mpsc` channel to
communicate statuses that will be shown in the activity indicator
- Inlining some functions that were only called once to reduce
indirection
- Removing the separate `direnv` module
Release Notes:
- N/A
Fix issue where Zed would unconditionally override user's custom shell
with system default from passwd entry.
Closes https://github.com/zed-industries/zed/issues/40171
Release Notes:
- Fix issue where Zed would unconditionally override user's custom shell
with system default from passwd entry.
---------
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
This moves some of the changes made in
https://github.com/zed-industries/zed/pull/39543 to the `publish_gpui`
script.
This PR also updates that script to use `gpui_` instead of `zed-` (where
possible)
Release Notes:
- N/A
Prior we only logged the crate in `log_err`, which is not too helpful.
We now assemble the module path from the file system path.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#39469Closes#39438Closes#39458
I'm not able to test it, i would appreciate if somebody could do it. I
think this bug was present also for SSH remote projects
Release Notes:
- Fixed an issue where zed bin was not found in remote servers for
askpass
---------
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
When sourcing the project environment for the terminal tool, we will now
do so by spawning the shell specified by the users `terminal.shell`
setting (or as usual fall back to the login shell).
Closes#37687
Release Notes:
- N/A
Closes#34393
Currently, we’re using `zed.exe --askpass` kind of like an `nc`
substitute, it prints out the SSH password to stdout with something like
`println!("user-pwd")`. `ssh.exe` then reads the password from stdout so
it can establish the connection.
The problem is that in release builds we set `subsystem=windows` to
avoid Windows spawning a black console window by default. The side
effect is that `zed.exe` no longer has a stdout, so `ssh.exe` can’t read
the password.
Through testing, I confirmed that neither allocating a new console for
`zed.exe` nor attaching it to the parent process’s stdout resolves the
issue. As a result, this PR updates the implementation to use `cli.exe
--askpass` instead.
TODO:
- [ ] Check that the `cli` path is correct on macOS
- [ ] Check that the `cli` path is correct on Linux
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
std commands can block for an arbitrary duration and so runs risk of
blocking tasks for too long. This replaces all such uses where sensible
with async processes.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes https://github.com/zed-industries/zed/issues/38690Closes#37353
### Background
On Windows, paths are normally separated by `\`, unlike mac and linux
where they are separated by `/`. When editing code in a project that
uses a different path style than your local system (e.g. remoting from
Windows to Linux, using WSL, and collaboration between windows and unix
users), the correct separator for a path may differ from the "native"
separator.
Previously, to work around this, Zed converted paths' separators in
numerous places. This was applied to both absolute and relative paths,
leading to incorrect conversions in some cases.
### Solution
Many code paths in Zed use paths that are *relative* to either a
worktree root or a git repository. This PR introduces a dedicated type
for these paths called `RelPath`, which stores the path in the same way
regardless of host platform, and offers `Path`-like manipulation APIs.
RelPath supports *displaying* the path using either separator, so that
we can display paths in a style that is determined at runtime based on
the current project.
The representation of absolute paths is left untouched, for now.
Absolute paths are different from relative paths because (except in
contexts where we know that the path refers to the local filesystem)
they should generally be treated as opaque strings. Currently we use a
mix of types for these paths (std::path::Path, String, SanitizedPath).
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
When we refactored settings to not pass JSON blobs around, we ended up
needing
to write *a lot* of code that just merged things (like json merge used
to do).
Use a derive macro to prevent typos in this logic.
Release Notes:
- N/A
Co-Authored-By: Ben K <ben@zed.dev>
Co-Authored-By: Anthony <anthony@zed.dev>
Co-Authored-By: Mikayla <mikayla@zed.dev>
Release Notes:
- settings: Major internal changes to settings. The primary user-facing
effect is that some settings which did not make sense in project
settings files are no-longer read from there. (For example the inline
blame settings)
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
Extracts and cleans up GPUI's scheduler code into a new `scheduler`
crate, making it pluggable by external runtimes. This will enable
deterministic integration testing with cloud components by providing a
unified test scheduler across Zed and backend code. In Zed, it will
replace the existing GPUI scheduler for consistent async task management
across platforms.
## Changes
- **Core Implementation**: `TestScheduler` with seed-based
randomization, session tracking (`SessionId`), and foreground/background
task separation for reproducible testing.
- **Executors**: `ForegroundExecutor` (!Send, thread-local) and
`BackgroundExecutor` (Send, with blocking/timeout support) as
GPUI-compatible wrappers.
- **Clock and Timer**: Controllable `TestClock` and future-based `Timer`
for time-sensitive tests.
- **Testing APIs**: `once()`, `with_seed()`, and `many()` methods for
configurable test runs.
- **Dependencies**: Added `async-task`, `chrono`, `futures`, etc., with
updates to `Cargo.toml` and lock file.
## Benefits
- **Integration Testing**: Facilitates reliable async tests involving
cloud sessions, reducing flakiness via deterministic execution.
- **Pluggability**: Trait-based design (`Scheduler`) allows easy
integration into non-GPUI runtimes while maintaining GPUI compatibility.
- **Cleanup**: Refactors GPUI scheduler logic for clarity, correctness
(no `unwrap()`, proper error handling), and extensibility.
Follows Rust guidelines; run `./script/clippy` for verification.
- [x] Define and test a core scheduler that we think can power our cloud
code and GPUI
- [ ] Replace GPUI's scheduler
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
The only warnings remaining are links to private modules/items, but I
lack knowledge to work out if the referenced modules/items should be
made public, or if the links should be rewritten into exposed
traits/items.
Links to associated items such as trait implementations have to be
written using full markdown format such as:
... [[ `App::update_global` ]](( BorrowAppContext::update_global ))
This is due to https://github.com/rust-lang/rust/issues/74563 which
sadly prohibits fully-qualified syntax:
... [[ `<App as BorrowAppContext>::update_global` ]]
Release Notes:
- N/A
Probably related to https://github.com/zed-industries/zed/pull/37072
Instead of manually constructing the venv we now ask the python
toolchain for the relevant information, unifying the approach of vent
inspection
Fixes https://github.com/zed-industries/zed/issues/27350
Release Notes:
- Improved the detection of python virtual environments for terminals
and tasks in remote projects.
- **util: Have maybe! use async closures instead of async blocks**
- **python: Fix flickering of virtual environment indicator in status
bar**
Closes#30723
Release Notes:
- Python: Fixed flickering of the status bar virtual environment
indicator
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Followup to #33678, doing the same thing for all JSON Schema files
provided to json-language-server
Release Notes:
* Added warnings for unknown fields when editing `tasks.json` /
`snippets.json`.
Follow-up to: https://github.com/zed-industries/zed/pull/32637
When Zed is installed in a path containing spaces (e.g.,
`/Applications/Zed Nightly.app/Contents/MacOS/zed`), environment
variable loading fails and leaves this in the Zed log:
```
login shell exited with exit status: 127. stdout: "", stderr: "Nightly.app/Contents/MacOS/zed --printenv >&0: /Applications/Zed: No such file or directory"
```
This was not part a release (only broke in nightly), but fixes it the
issue in any case when the path to the Zed.app bundle has a space (e.g.
"Zed Nightly.app")
Release Notes:
- N/A
In #31331, I made a change that prevents Zed from running with root
privileges, but I forgot about the CLI.
So if you run the CLI without the `--foreground` flag, it just freezes
without any messages. This PR fixes that.
Release Notes:
- N/A
Richard Feldman