## Context
<!-- What does this PR do, and why? How is it expected to impact users?
Not just what changed, but what motivated it and why this approach.
Link to Linear issue (e.g., ENG-123) or GitHub issue (e.g., Closes#456)
if one exists — helps with traceability. -->
## 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
- [ ] 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:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
`PathList` stores both sorted paths and the original insertion order
(for display in the project panel). Previously, `PartialEq`, `Eq`, and
`Hash` were derived, which meant two `PathList` values with the same
paths but different display orderings were considered unequal.
This change replaces the derived impls with manual ones that only
compare
the sorted `paths` field, matching the semantic intent: a `PathList`
identifies a set of directories, and the display order is not part of
that identity.
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
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Closes#46307
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [X] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Improved compatibility with mounted VHDs on Windows.
---------
Co-authored-by: John Tur <john-tur@outlook.com>
## Summary
Fixes Windows file-open parsing for names like `main (1).log`.
`PathWithPosition::parse_str` could treat `(1)` in a normal filename as
a position suffix and drop the extension/path tail. The regex is now
anchored so parenthesized row/column parsing only applies at the end of
the filename (with optional trailing `:` and optional range suffix).
## Testing
- `cargo test -p util path_with_position_parse_`
Closes#50597
Release Notes:
- Fixed opening files with names like `main (1).log` on Windows.
This will help with test times (in some cases), as nextest cannot figure
out whether a given rdep is actually an alive edge of the build graph
Closes #ISSUE
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
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
---------
Co-authored-by: Eric <eric@zed.dev>
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Anthony Eid <anthony@zed.dev>
Co-authored-by: John Tur <john-tur@outlook.com>
Closes#47823
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] No UI changes
Release Notes:
- Solves the issue where env variables failed to load when a project
with dir path had `'`(single quote) in them, for example:
`C:\Temp\O'Brien\project_1`.
- added a zed pre-quote for directory paths and zed executable
- handled pwsh, nushell, cmd, fish, posix, csh, tcsh, rc, xonsh, elvish
based terminals
- uses `try_quote` for quoting shell paths
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
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
Closes#47678
When using mixed sort mode in the project panel, a folder and file with
the same name but different case (e.g., `hello` folder and `Hello.txt`
file) would sort incorrectly. The file could appear between an expanded
folder and its contents.
The issue was in `compare_rel_paths_mixed`: the tie-breaker logic used
case-sensitive comparison (`a == b`) to decide directory-before-file
ordering, but `natural_sort_no_tiebreak` already considers entries equal
case-insensitively. Changed to use `eq_ignore_ascii_case` to match.
Release Notes:
- Fixed project panel mixed sort mode ordering incorrectly when a file
and folder share the same name with different casing.
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>
A collection of small independent fixes:
- **Visual test runner**: Replace ~20 instances of `.ok()` and `let _ =`
with `.log_err()` to avoid silently discarding errors per project
guidelines.
- **recent_projects**: Add missing `remote_connection/test-support` to
the `test-support` feature gate.
- **util/shell.rs**: Add doc comment on `supports_posix_chaining()`
explaining its relationship to tool permission pattern matching.
Release Notes:
- N/A
`brush-parser` handles `;` (sequential execution) and `|` (piping) which
all these shells use, so we can safely parse their commands for
`always_allow` pattern matching.
(No release notes because granular tool permissions haven't been
released yet.)
Release Notes:
- N/A
## 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>
<img width="1110" height="280" alt="Screenshot 2026-01-28 at 3 35 52 PM"
src="https://github.com/user-attachments/assets/4d467e2c-2e7b-4ec7-bc87-6f0df8e667f0"
/>
<img width="1094" height="411" alt="Screenshot 2026-01-28 at 3 40 54 PM"
src="https://github.com/user-attachments/assets/f559df93-e72e-4457-ba1b-f7d6239f3285"
/>
Previously, if a user configured `^ls` as an always-allow pattern, an
attacker could craft a command like `ls && rm -rf /` which would be
auto-approved because the regex only matched the beginning of the
command string.
Now the command is parsed into individual sub-commands (`ls`, `rm -rf
/`) and EACH sub-command must match an allow pattern for auto-approval.
This prevents shell injection attacks using operators like:
- `&&` and `||` (boolean operators)
- `;` and `&` (sequential/background execution)
- `|` (pipes)
- Newlines
- Command substitution (`$()` and backticks)
- Process substitution (`<()` and `>()`)
## Matching Logic
- **always_deny**: if ANY sub-command matches, deny the entire command
- **always_confirm**: if ANY sub-command matches, require confirmation
(unless always_deny matched, in which case deny)
- **always_allow**: ALL sub-commands must match for auto-approval
(unless always_confirm or always_deny matched, in which case defer to
those)
- If parsing fails, or if the shell is unsupported, then always_allow is
disabled for this command
As usual, `always_allow_tool_actions` supercedes all of these. If it is
`true`, then we always allow all tool calls, no questions asked.
## Shell Compatibility
The shell parser only supports POSIX-like command chaining syntax (`&&`,
`||`, `;`, `|`).
**Supported shells:** Posix (sh, bash, dash, zsh), Fish 3.0+, PowerShell
7+/Pwsh, Cmd, Xonsh, Csh, Tcsh
**Unsupported shells:** Nushell (uses `and`/`or` keywords), Elvish (uses
`and`/`or` keywords), Rc (Plan 9 shell - no `&&`/`||` operators)
For unsupported shells:
- The "Always allow" UI options are hidden for the terminal tool
- If the user has `always_allow` patterns configured in settings, they
will see a `Deny` with an explanatory error message
(No release notes because granular tool permissions are behind a feature
flag.)
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
We might interface with the LSP using URL heres across remotes that have
differing path styles which then breaks every now and then when we have
windows to unix connections. This should helps us fix these occurences
more correctly
Release Notes:
- N/A *or* Added/Fixed/Improved ...
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
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
I saw that this test is failing at head, with what turns out to be a
dependency on the test environment umask.
This removes the over-strict assertions about permissions from extracted
zips when permissions aren't preserved. I tested locally that it passes
with 022, 002, 077.
Also, some of the comments and variable names seemed to be out of date
for this test, in which the file is not executable, so I changed/removed
them.
cc @MrSubidubi
follows on from #45515
Before:
```
mbp@amorfati ~/s/zed> umask 002
mbp@amorfati ~/s/zed> cargo nextest run -p util archive::tests::test_extract_zip_sets_default_permissions
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.21s
────────────
Nextest run ID de9e0712-0db1-4e4e-8c9f-421bb68ed23c with nextest profile: default
Starting 1 test across 1 binary (71 tests skipped)
FAIL [ 0.003s] util archive::tests::test_extract_zip_sets_default_permissions
stdout ───
running 1 test
test archive::tests::test_extract_zip_sets_default_permissions ... FAILED
failures:
failures:
archive::tests::test_extract_zip_sets_default_permissions
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 71 filtered out; finished in 0.00s
stderr ───
thread 'archive::tests::test_extract_zip_sets_default_permissions' (755934) panicked at crates/util/src/archive.rs:290:13:
assertion `left == right` failed: Expected default set of permissions for unzipped file with no permissions set.
left: 436
right: 420
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Closes #ISSUE
Release Notes:
- N/A
I really enjoyed this feature in Claude Code. Helps me get a sense of
how effortful something is.
Release Notes:
- Added a "show_turn_stats" setting, default to false, that shows the
timer and the number of tokens down.
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`.
This mimics VSCode's `files.readonlyExclude` setting, to allow setting
specific path matches as readonly locations like lockfiles and generated
sources etc.
Also renders a lock icon to the right side of the path names for
readonly files now.
This does a couple more things for completion sake:
- Tabs of readonly buffers now render a file lock icon
- Multibuffer buffer headers now render a file lock icon if the excerpts
buffer is readonly
- ReadWrite multibuffers now no longer allow edits to read only buffers
contained within
Release Notes:
- Added `read_only_files` setting to allow specifying glob patterns of
files that should not be editable by default
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
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
`npx`, and any `npm install`-ed programs, exist as batch
scripts/PowerShell scripts on the PATH. We have to use a shell to launch
these programs.
Fixes https://github.com/zed-industries/zed/issues/41435
Closes https://github.com/zed-industries/zed/pull/42651
Release Notes:
- windows: Custom MCP and ACP servers installed through `npm` now launch
correctly.
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
## 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.
The JSON language server looks for a top-level `allowTrailingCommas`
flag to decide whether it should warn for trailing commas. Since the
JSONC parser for these builtin files can handles trailing commas, adding
this flag to the schema also prevents a warning for those commas.
I don't think there's an issue that is only for this specific issue, but
it relates to *many* existing / older issues:
- #18509
- #17487
- #40970
- #18509
- #21303
Release Notes:
- Suppress warning for trailing commas in builtin JSON files
(`settings.json`, `keymap.json`, etc.)
We were using `std::path::Path::strip_prefix` to determine which
repository an absolute path belongs to, which doesn't work when the
paths are Windows-style but the code is running on unix. Replace it with
a platform-agnostic implementation of `strip_prefix`.
Release Notes:
- Fixed git features not working when a Windows host collaborates with a
unix guest
I have git installed via [scoop](https://scoop.sh). The current
implementation finds `git.exe` in scoop's shims folder and then tries to
find `bash.exe` relative to it.
For example, `git.exe` (shim) is located at:
```
C:\Users\<username>\scoop\shims\git.exe
```
And the code tries to find `bash.exe` at:
```
C:\Users\<username>\scoop\shims\..\bin\bash.exe
```
which doesn't exist.
This PR changes the logic to first check if `bash.exe` is available in
PATH (using `which::which`), and only falls back to the git-relative
path if that fails.
