Commit Graph
39413 Commits
Author SHA1 Message Date
procr1337 8e18ab0cd7 util: Fix stdin redirect for ShellBuilder (#62078)
# Objective

This is a follow-up to my own PR #59270 which fixed the hang it targeted
(#55042) only partially and broke `ShellBuilder::build` for fish.

**The hang is only half fixed.** The agent's terminal tool wraps
commands as `sh -i -c 'exec </dev/null; <command>'`. The redirect sits
on the same line as the command, but POSIX shells parse an entire line
before executing any of it. So when `<command>` has a syntax error, the
whole line is discarded — including the `exec` that was supposed to
close stdin. Interactive `dash` then recovers from the error, finds
stdin still attached to the PTY, and sits at a `$` prompt until the user
presses Ctrl+D.

That means #59270 only helped when the redirect had already run, i.e.
multi-line commands whose error is on a later line. A single-line
command still hangs, including `cat <(echo hi)`, the example from that
PR's own description. Probably prompts or tool definitions changed since
that PR landed which now make it more likely again to run into this
issue, at least with Anthropic models.

**fish runs no command at all.** #59270 also applied the `exec
</dev/null; …` form to fish, replacing its `begin; …; end </dev/null`
wrapper. But fish's `exec` requires a command to replace the shell with,
so a bare `exec </dev/null` is a usage error: fish prints `exec`'s help
text, skips the rest of the command, and exits 0.

## Solution

For POSIX shells, put the redirect on its own line:

```sh
sh -i -c 'exec </dev/null
<command>'
```

That makes it a separate parse-and-execute unit, so it runs before the
command line is parsed. Any syntax error is then reported by a shell
that already has `/dev/null` on stdin, and it exits instead of
prompting.

For fish, go back to `begin; <command>; end </dev/null`. fish exits on a
parse error even when interactive, so it never needed the `exec` form to
begin with.

Only the `Posix` and `Fish` arms change; the other shells' redirects are
untouched.

Note this is still a targeted fix for `dash`. The underlying reason a
syntax error becomes an interactive prompt is that agent terminals are
built with `-i` at all — non-interactive `dash` exits cleanly even with
no redirect. Dropping `-i` would remove the whole class of hang, but it
would also stop sourcing users' interactive shell config in agent
terminals.

## Testing

`cargo test -p util --lib shell_builder` covers the changed command
assembly.

Reviewers can check the shell behavior directly on a PTY, without
building Zed:

```sh
# hangs at a `$` prompt until Ctrl+D
script -qec "sh -i -c 'exec </dev/null; echo hi ;;'" /dev/null

# exits immediately with just the syntax error
script -qec "sh -i -c 'exec </dev/null
echo hi ;;'" /dev/null
```

```sh
fish -i -c 'exec </dev/null; echo test'        # prints exec's help, no "test", exit 0
fish -i -c 'begin; echo test; end </dev/null'  # prints "test"
fish -i -c 'if true'                           # exit 127, no hang
```

macOS is unaffected in practice because `/bin/sh` there is bash, which
exits on a syntax error even with `-i`; Windows goes through the
`Cmd`/`PowerShell` arms, which this doesn't touch. A `zsh`-as-`/bin/sh`
setup is likewise 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 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 agent terminal commands hanging at a shell prompt after a syntax
error
2026-08-05 08:16:06 +00:00
feeiyu 655ed1385b Prevent inactive windows from updating the IME position on linux/Wayland (#62086)
# Objective
Fixes #62084

Fix the Wayland IME candidate window flickering between two positions
when an inactive Zed window has a terminal producing continuous output.

Terminal wakeup events in the inactive window can trigger IME position
updates, causing its cursor bounds to alternate with those from the
active window.


https://github.com/zed-industries/zed/blob/90d024b88abc91264d9a0ad260eb4f365fa695c3/crates/terminal_view/src/terminal_view.rs#L1130-L1136


https://github.com/zed-industries/zed/blob/90d024b88abc91264d9a0ad260eb4f365fa695c3/crates/gpui/src/window.rs#L5617-L5627

## Solution

Ignore IME position updates from inactive Wayland windows.

This ensures that only the active window can update the cursor rectangle
of the shared Wayland text-input object.

## Testing

To test manually on Linux with Wayland and Fcitx5:

1. Open two Zed windows.
2. Start continuous terminal output in the first window.
3. Use the Chinese IME in an editor in the second window.
4. Verify that the IME candidate window remains at a stable position.


## 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#uxui-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable

## Showcase

after fix:


[2026-08-02
22-43-35.webm](https://github.com/user-attachments/assets/ff2e3bc7-7772-481e-82f8-92e6e3fa7275)



---

Release Notes:

- Fixed the IME candidate window flickering when another Zed window has
continuous terminal output
2026-08-05 07:30:17 +00:00
Xin Zhao 381953d448 collab_ui: Fix inconsistent channel icons in collab panel (#62114)
# Objective

In PR #61397, the channel icons for public and private channels were
updated, but the tab icon for channel notes was not covered, causing the
tab icon to mismatch the channel icons shown in the collab panel, as
shown below:
<img width="850" height="185" alt="before"
src="https://github.com/user-attachments/assets/232a798c-122e-4ce1-9735-900fde851736"
/>

## Solution

Update the tab icon for channel notes to match the already-updated
channel icons in the collab panel (public channels use `#`, private
channels use a lock).

## Testing

Built and tested locally, with before/after comparison attached below.

## 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

## Showcase

| Before | After |
|:--:|:--:|
|<img width="850" height="185" alt="before"
src="https://github.com/user-attachments/assets/f915f61d-4fac-451d-b930-b751e6a1035e"
/>|<img width="905" height="195" alt="after"
src="https://github.com/user-attachments/assets/11ffe280-4416-4050-8b2d-ea5bc989c39a"
/>|

---

Release Notes:

- Fixed channel tab icons for public and private channels not matching
the icons shown in the collab panel.
2026-08-05 03:37:37 +00:00
Ben Kunkle 158c16f51c workspace: Choose the replacement workspace inside MultiWorkspace::remove (#62141)
# Objective

Follow-up to #62028. When archiving removed a thread's workspace, the
replacement
was derived from whichever sidebar row sat adjacent to the archived one.
Rows are
a flat list with project headers as separators, so archiving the oldest
thread in
a project selected the next project's newest thread and moved the user
out of the
project they were working in — and when that neighbor was remote,
connected to
its host just to pick a fallback.

# Solution

- `MultiWorkspace::remove` now chooses the replacement itself from a
`RemovalIntent` (keep the project vs close it): a live workspace in the
same
project, the project's own roots when kept, the nearest retained
neighbor,
an adjacent local project, then an empty workspace. The workspaces being
  removed are excluded from that search in one place instead of five.
- Sidebar neighbor selection stays within the entry's project section.
- The three archive paths now share one removal orchestration, and the
three
  "open the closed workspace first" helpers collapse into one.

# Testing

New tests cover: the keep-project fallback, neighbor selection staying
inside the
project section, and archiving with a mock-remote neighboring project
never
connecting to it. Each was verified to fail against the previous
behavior.

## 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 archiving a thread switching the window to a different project.
- Fixed a possible crash when archiving a thread while its window was
closing.
2026-08-05 02:48:46 +00:00
Anthony Eid 300972bea3 gpui: Add async task benchmark support (#62180)
### Summary

This PR improves GPUI's Criterion benchmark integration by adding
task-based measurement APIs to `BenchAppContext`. Benchmarks can now
await asynchronous GPUI operations whose completion depends on
foreground work, background work, timers, or external wakes, while
keeping setup and destruction outside the measured interval.

#### Added `BenchAppContext` APIs

- Add `bench_task` to measure a GPUI `Task` through completion in
Criterion's iteration loop.
- Add `bench_batched_task` to perform per-iteration setup outside the
timed interval before measuring a task.
- Preserve support for non-`Send` foreground task outputs and destroy
outputs after timing stops.
- Collect frame timings produced during asynchronous benchmark
iterations without including collection in the measurement.
- Drive task completion across temporary dispatcher quiescence and
externally delivered wakes.

Release Notes:

- N/A
2026-08-04 23:38:36 +00:00
Ben Kunkle 20ce54f8e4 project: Compare WorktreePaths by pairing, not by path sets (#62144)
# Objective

- Prevent changed main/folder associations from being skipped during
thread metadata updates.

## Solution

- Compare WorktreePaths as ordered main/folder pairs.
- Keep PathList equality order-insensitive.

## Testing

- cargo test -p project test_worktree_paths_equality_compares_pairings

## Self-Review Checklist:

- [x] I have reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed UI standards
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

---

Release Notes:

- N/A
2026-08-04 17:51:11 +00:00
Cameron McloughlinandLukas Wirth 4601ead416 gpui: Webgl backend (#62165)
Currently gpui only supports webgpu as a backend when compiling for the
web. However, webgpu support on Linux browsers is spotty (without
setting experimental flags):
- chromium has is enabled for nvidia and recent intel chips
- firefox does not enable it

This PR adds a WebGL backend, which is much more widely supported

---

Release Notes:

- N/A or Added/Fixed/Improved ...

---------

Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
2026-08-04 15:53:09 +00:00
Joseph T. Lyons a12e3c0673 Remove project panel undo and redo feature flag (#62124)
Release Notes:

- N/A
2026-08-04 15:35:05 +00:00
Albert Bogusz b8c75f1717 Use correct provider icons for extension repository links (#58108)
Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments (N/A)
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

I was unable to find an issue or PR which mentions this.

Extensions with non-GitHub repository links always use the GitHub icon,
which is inconsistent with the changes merged in #44738 and #57500. This
change makes `extension_ui.rs` use the Git hosting provider registry to
determine these icons. Below is a preview of the change:

<div align="center">
    <img
        width="450"
        alt="Preview"

src="https://github.com/user-attachments/assets/e35f0eed-de54-48f9-824d-8a5b9bfc596f"
    />
</div>

Release Notes:

- Improved extension repository links to show provider-specific icons.
2026-08-04 15:14:33 +00:00
Drew Ridley bbd198f57b editor: Resolve semantic token overlaps by configured server order (#61735)
`RawSemanticTokens` says tokens later in the list override earlier ones
on overlap, but there's no list to be later in — the tokens are stored
in a `HashMap<LanguageServerId, _>` and the sort that flattens them keys
only on `range.start`:


https://github.com/zed-industries/zed/blob/9dcc3c29099724321c34797d18573d28a2c9df25/crates/project/src/lsp_store/semantic_tokens.rs#L702-L709


https://github.com/zed-industries/zed/blob/9dcc3c29099724321c34797d18573d28a2c9df25/crates/editor/src/semantic_tokens.rs#L312-L314

`sort_by` is stable, so two servers' tokens at the same position keep
whatever order the map iteration gave them, and which one wins changes
between sessions.

You hit this any time two servers tokenize the same range. In my case a
server that highlights an embedded query inside a string literal renders
fine, then loses the range to svelte-language-server once that
refreshes. Setting `languages.Svelte.language_servers` doesn't help,
since that isn't what decides it.

Breaking ties by `server_id` makes it deterministic.
`SemanticTokenHighlight` already carries the id and `LanguageServerId`
is `Ord`, so it's just the tiebreak.

Worth noting the servers do arrive as an ordered `Vec` from
`language_server_ids_for_buffer` and that order is dropped when they go
into the `HashMap`. Sorting by id gets determinism but not that original
order; if preserving it is what was intended I'm happy to submit a PR
for that functionality instead.

Release Notes:

- Fixed semantic token highlighting being applied unpredictably when
more than one language server provides tokens for the same range.
2026-08-04 14:05:46 +00:00
William Whittakeranddino c6e0868cb8 vim: Fix insert above auto-indentation (#52594)
Fixes InsertLineAbove (Shift + O) auto-indent handling by deciding
whether to trim the first character or the last character based on
direction. Previously, inserting a line above would auto format the line
the cursor was originally on and not the new line (instead of the
correct behavior which is to do the opposite).

No tests because I couldn't find any Vim-specific auto-indent tests and
this only affects Vim mode. If I'm missing something there LMK and I'll
take a closer look.

Closes #52588.

Release Notes:

- Vim: Fixed auto-indentation for insert above action.

---------

Co-authored-by: dino <dinojoaocosta@gmail.com>
2026-08-04 11:45:33 +00:00
Piotr OsiewiczandSmit Barmase 1ade7854f2 Respect regex assertions more faithfully with search (#62158)
- **project_search: Add failing test for regex searches with
assertions**
- **project_search: Improve handling of regex assertions**

# Objective

Fixes #55995 by removing a faulty optimization path for regex searches.


## Solution

## Testing

We've added 3 extra tests for the changed behavior.

## 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

## Showcase

> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.

- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!

While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:

<details>
  <summary>Click to view showcase</summary>

My super cool demos here

</details>

---

Release Notes:

- Improved handling of regexes in project/buffer searches

---------

Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
2026-08-04 11:23:39 +00:00
184e124bba terminal: Resolve path hyperlinks using per-line cwd (#52454)
## Context

When cmd/ctrl-clicking a relative path in the terminal, Zed was
resolving it against the *current* working directory at click time, not
the directory that was active when the line was printed. So if you run
command `cd folder1` after running command `ls`, clicking `test.txt` in
the old `ls` output would open `ROOT/test.txt` instead of
`ROOT/folder1/test.txt`.

The approach is similar to the VSCode approach for hyperlinks in the
terminal

**Video below of the test on VSCode:**

[Screencast from 2026-03-25
23-28-26.webm](https://github.com/user-attachments/assets/d1c3b163-7b18-43db-9981-71c1cb09a801)

**Video below of the test on Zed after the fix:**

[Screencast from 2026-03-25
23-31-49.webm](https://github.com/user-attachments/assets/fc23da34-dd16-4cce-afed-53f681762152)

Closes #52325

## How to Review

Two files changed — read in this order:

1. **`crates/terminal/src/pty_info.rs`** Bug fix:
`emit_title_changed_if_changed` was comparing cwd with itself because
`load()` writes to `self.current` *before* the comparison. Fixed by
capturing `prev_cwd`/`prev_name` before calling `load()`. Also extended
the background task to return the new cwd when it changes, so the
foreground task can call `terminal.record_cwd_change(cwd)`.

2. **`crates/terminal/src/terminal.rs`** 
- `cwd_history: Vec<(i32, PathBuf)>` field on `Terminal`, seeded with
`(i32::MIN, initial_cwd)` for PTY terminals so all pre-history lines
resolve correctly.
- `record_cwd_change` called when the PTY cwd changes; records the
current scrollback position alongside the new path.
- `cwd_at_line` given a scrollback line, binary-searches the history to
find the most recent cwd active at or before that line.
- `process_hyperlink` updated to use `cwd_at_line` for both plain paths
and `file://` URLs.

## Self-Review Checklist

- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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 terminal path hyperlinks resolving against the current working
directory instead of the one active when the line was printed

---------

Co-authored-by: Lukas Wirth <lukas@zed.dev>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
2026-08-04 09:27:46 +00:00
Travis McHenryandLukas Wirth e717010c82 Remote: Stream remote server into WSL on /mnt copy failure (#57624)
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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

Closes #47375


The current `crates/remote/src/transport/wsl.rs` remote transport code
tries to copy the remote-server from /mnt/c/* from within WSL. This
fails if you have automount disabled, or otherwise have your drive
unmounted.

How to reproduce this error:

Prerequisites: Windows with WSL2 and a WSL distro installed.

1. Inside the WSL distro, disable Windows automount — edit
`/etc/wsl.conf`:
```ini
[automount]
enabled = false
```

2. From a Windows shell: `wsl --shutdown`
3. Open the distro shell again and confirm `mount | grep /mnt/c` returns
nothing.
4. From Zed (any version before this PR), open a remote WSL project on
that distro for the first time (no cached
`~/.zed_server/zed-remote-server-*` inside the distro — `rm` it if
present).

The solution was to pipe the server in over stdin if the copy fails.
This is a fallback path similar to how ssh.rs has a fallback path if the
download fails there.

With this PR the logs look like this:
```
2026-05-24T18:51:37-07:00 INFO  [remote::transport::wsl] uploading remote server to WSL ".zed_server/download-72808-remote_server" (441187kb)
2026-05-24T18:51:37-07:00 WARN  [remote::transport::wsl] failed to upload remote server via /mnt, falling back to wsl.exe stdin: Command 'Command("wsl.exe" "--distribution" "Ubuntu" "--cd" "~" "--exec" "wslpath" "-u" "C:/Users/<user>/Documents/GitHub/zed/target/remote_server/x86_64-unknown-linux-musl/debug/remote_server")' failed: wslpath: C:/Users/<user>/Documents/GitHub/zed/target/remote_server/x86_64-unknown-linux-musl/debug/remote_server: Command 'Command("wsl.exe" "--distribution" "Ubuntu" "--cd" "~" "wslpath" "-u" "C:/Users/<user>/Documents/GitHub/zed/target/remote_server/x86_64-unknown-linux-musl/debug/remote_server")' failed: wslpath: C:/Users/<user>/Documents/GitHub/zed/target/remote_server/x86_64-unknown-linux-musl/debug/remote_server
2026-05-24T18:51:38-07:00 INFO  [remote::transport::wsl] uploaded remote server in 945.899ms
```

I considered making wsl just use curl/wget to download as a fallback, as
docker/ssh do, but that would lose the 'cache' effect of downloading
once on windows and sending to multiple WSL distros. Which seems to have
been the intent of the copy method in the first place.

I also considered using the network-drive style UNC mount to copy from
Windows to the WSL distro, but that could run into similar issues where
the user may have that disabled. It also seems to copy as WSL's default
user, rather than the --user specified to Zed for the distro. Currently
--user is not passed by default to wsl.exe, so that ends up being the
default user. However, it is settable through the settings.json, so some
rare users may still have an issue with ownership of the copied files.

I chose to make the new stdin option the fallback instead of the default
because the current code is working for most people, and it seemed like
a much larger change to replace the default.

For the tests there don't seem to be any tests for wsl.rs currently that
I can find, so it seemed like a lot of extra code needed to satisfy that
PR checkbox. wsl.rs and docker.rs have zero inline tests, and the ones
that are in ssh.rs don't cover the ensure/upload/download portion. The
integration tests seem to use RemoteClient::fake_server and bypass the
real transports.

For manual testing I tested these scenarios:
1. WSL distro with automount **on** AND existing binary: **still works**
2. WSL distro with automount **on** AND **no** existing binary: **still
works**
3. WSL distro with automount **off** AND existing binary: **still
works**
4. WSL distro with automount **off** AND **no** existing binary: **now
works**

I'm not all that proficient with rust so I used a coding agent to help,
but I reviewed every line and it all makes sense to me. Please let me
know if something looks off, I'm trying to learn.


Release Notes:

- Fixed remote server installation failing in WSL when automount is
disabled.

---------

Co-authored-by: Lukas Wirth <lukas@zed.dev>
2026-08-04 08:54:56 +00:00
Ben Kunkle 4aad57fd1f workspace: Return the created workspace when opening a remote project (#62028)
# Objective

Fix the `fallback workspace must not be one of the workspaces being
removed` panic.

Fixes FR-148
Fixes ZED-AKR
Fixes ZED-97M

# Solution

The remote path of `find_or_create_workspace` opened a project, then
returned the
window's *active* workspace instead of the one it created. The open
awaits toolchain
loading and item restoration, and a save prompt from a concurrent
workspace removal
can re-activate a workspace being removed during that wait; the stale
return value
then trips the assert in `MultiWorkspace::remove`.

Return the created workspace from `open_remote_project_inner` and use it
at the
call sites instead of re-reading the active workspace after the await.

# Testing

Added
`test_find_or_create_workspace_returns_the_created_remote_workspace`:
opens a
mock remote project and re-activates the previous workspace mid-open
(standing in
for the save prompt), then asserts the open returns the workspace it
created.
Verified it fails against the pre-fix behavior.

## 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 crash when a workspace was removed while a remote project was
opening in the same window.
2026-08-03 20:43:45 +00:00
Ben Kunkle b5764581d2 project: Refresh MCP settings after worktree changes (#62026)
# Objective

Prevent MCP servers from remaining unavailable when a project is created
before its first worktree.

## Solution

Refresh effective MCP settings before maintaining servers after worktree
additions or removals.

## 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:

- Agent: Fixed MCP servers missing from new project threads after a
worktree opens.
2026-08-03 20:33:31 +00:00
Ben Kunkle 41c0f28bf9 project: Fix branch diff with older servers (#62134)
# Objective

Prevent branch diffs from failing when a server does not recognize
worktree diff requests.

## Solution

Send `HEAD` as a valid committed-only fallback for servers that ignore
`includes_worktree`.

## 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

---

Release Notes:

- N/A
2026-08-03 20:24:39 +00:00
Joseph T. Lyons 7759e9f93a feature_flags: Remove unused auto-watch flag (#62122)
Release Notes:

- N/A
2026-08-03 15:36:02 +00:00
feeiyu b036368ce9 Align agent sidebar headers with title bar (#62079)
# Objective

Fix the Agent sidebar header being two pixels lower than the title bar
on Linux.

This only affects Linux with client-side decorations: the main title bar
uses a negative one-pixel margin to overlap the client-drawn window
border, while the sidebar previously used a positive one-pixel margin on
every platform.

Fixes #53739

## Solution

Match the sidebar header spacing to the window decoration mode:

- Use `-1px` top margin for client-side decorations.
- Preserve the existing spacing for server-side decorations.
- Apply the fix to both the thread list and archive headers.

## Testing

- Manually tested on Linux. This only affects Linux because its
client-side window decorations require the adjusted title bar offset.

## 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)](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)](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable


## Showcase

After this change:

[2026-08-02
18-20-19.webm](https://github.com/user-attachments/assets/1ef13ff2-2036-442b-8bcc-74ebeb8436c7)


---

Release Notes:

- Fixed misaligned Agent sidebar headers on Linux.
2026-08-03 14:47:45 +00:00
John Tur be8c6f9fb3 Tweak renderer resource management (#62069)
Factoring some changes out of
https://github.com/zed-industries/zed/pull/61461:
- On Metal and wgpu, bulk-upload instance buffers at the start of the
frame rather than uploading chunks as we draw them. The depth buffer
patch needs this architecture since all opaque quads in the scene are
painted before anything else. This also lets us get rid of the awkward
retry loop when the GPU buffer is too small for the scene.
- On Windows, use a constant buffer for the instance offset rather than
creating SRVs with different `FirstElement`s. `FirstElement` is buggy on
some vendors' drivers, and reusing the SRV object should reduce D3D
runtime overhead.
- Misc. refactoring: remove redundant parameters, deduplicate code,
create fewer bind groups on wgpu, etc.

Fixes https://github.com/zed-industries/zed/issues/49588
Fixes https://github.com/zed-industries/zed/issues/59192

Release Notes:

- Fixed an issue where UI elements would flicker on some Windows
devices.
2026-08-03 14:37:21 +00:00
Dino 2d9680fc02 feature_flags: Enable project panel undo/redo on all release channels (#62104)
# Objective

Ensure that the Project Panel's Undo/Redo system is enabled in Stable
before this week's release, as it's enabled on all release channels
except stable.

Since, as far as I'm aware, there hasn't been any issue reported
regarding last week's Preview release, I'm going to go ahead and enable
this in stable.

## Solution

Update
`feature_flags::flags::ProjectPanelUndoRedoFeatureFlag::enabled_for_all`
to `true`, we no longer need to match on the release channel.

## Testing

N/A

## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] 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)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable

---

Release Notes:

- N/A
2026-08-03 13:48:23 +00:00
Cameron Mcloughlin 849ec5898a agent: Fix NTFS warning breaking terminal tool when WSL not available (#62049)
There is a bug on main and preview causes all terminal tool calls to
fail when:
- on windows
- sandboxing is not available (i.e. no WSL)
- sandboxing is enabled in settings (the default)
- the "warn windows-drive grants" setting is enabled (the default)

Example error:
<img width="352" height="79" alt="image"
src="https://github.com/user-attachments/assets/24affbec-f086-40eb-8827-ad74aabc6167"
/>

This PR fixes it by making sure we only show the check at the right time

---

Release Notes:

- N/A or Added/Fixed/Improved ...
2026-08-03 11:53:30 +00:00
Evan VinciguerraandClaude Opus 4.8 35cb7558a9 editor: Add configurable git gutter width setting (#61304)
## Summary

Adds a `gutter.git_gutter_width` setting that lets users pin the width,
in pixels, of the git diff hunk indicators in the editor gutter.

Previously the width was always derived from the buffer font size
(`floor(0.275 * line_height)`), which can render too thin or too thick
depending on font family and display pixel density. This adds an
optional override:

```json
{
  "gutter": {
    "git_gutter_width": 6
  }
}
```

When the setting is unset (`null`, the default), the width continues to
scale with the buffer font size, so existing behavior is unchanged.

## Motivation

Requested in [discussion
#27799](https://github.com/zed-industries/zed/discussions/27799). Beyond
the width itself, participants noted the git hunk hit target is
extremely narrow and hard to click. Because the hunk hitbox reuses the
painted strip bounds, setting a wider `git_gutter_width` also widens the
clickable area, addressing that complaint with the same setting.

## Changes

- `settings_content`: new `git_gutter_width: Option<f32>` on
`GutterContent`.
- `editor`: mirror field on the resolved `Gutter`; `gutter_strip_width`
now consults the setting, and the value flows through `diff_hunk_bounds`
(including the deleted-hunk marker) and the gutter layout anchors for
line numbers, folds, and expand toggles.
- `settings` (VS Code import): pass through the new field.
- Docs + `default.json`: document the new setting.

## Notes

- `Eq` was dropped from `GutterContent`/`Gutter` because `f32` is not
`Eq`; this matches the existing `EditorSettingsContent` convention for
float-bearing settings.

Release Notes:

- Added a `gutter.git_gutter_width` setting to configure the width of
git diff indicators in the editor gutter

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-03 01:46:00 +00:00
Nathan Sobo 8886dcb0d4 gpui: Expose threaded dispatcher for tests (#62096)
Some tests need real OS threading and timers rather than the
deterministic, single-threaded behavior of `TestDispatcher`. The
existing multithreaded dispatcher provides those production-like
scheduling semantics, but it is named and gated as a benchmark-only
facility, which unnecessarily pulls in Criterion and histogram
dependencies.

This renames `BenchDispatcher` to `ThreadedDispatcher` and exposes it
through GPUI's `test-support` feature. Benchmark contexts continue using
the same dispatcher, while Criterion and benchmark reporting remain
isolated behind the `bench` feature.

### Testing

- `cargo check -p gpui --features test-support`
- `cargo check -p gpui --features bench`
- `cargo nextest run -p gpui 'threaded_dispatcher::tests'`
- `cargo fmt --all --check`

Release Notes:

- N/A
2026-08-02 22:21:34 +00:00
Piotr Osiewicz 538a4a267b Add wezel scenario for an incremental editor build (#62016)
# Objective

This PR codifies one of the scenarios I've used to measure build health
of a codebase via [Wezel](https://wezel.build), a tool I've built for
that purpose.
## Solution

`wezel exp run incremental-editor`

## Testing

- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?

## Self-Review Checklist:

- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] 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)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable

## Showcase

> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.

- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!

While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:

<details>
  <summary>Click to view showcase</summary>

My super cool demos here

</details>

---

Release Notes:

- N/A or Added/Fixed/Improved ...
2026-08-02 18:40:37 +00:00
Vlad GaevskyandDanilo Leal 66ed3027b8 agent_ui: Show the agent panel's full screen button as toggled (#62041)
The agent panel's full screen button and a pane's zoom button drive the
same mechanism — both emit `PanelEvent::ZoomIn`/`ZoomOut`, and
`Workspace::zoomed` holds a single entry, so at most one of them is
active at a time.

The pane's button reflects that state: it is rendered with
`toggle_state(zoomed)`, so it is visibly active while zoomed
(`crates/workspace/src/pane.rs`). The agent panel's button only swapped
its icon, so while the panel was zoomed the button still looked like an
inactive control.

This makes the agent panel's button use the same `toggle_state` +
`selected_icon` pattern as the pane's. Behavior is unchanged; the button
now looks active while full screen is on. The element id is now stable
across both states instead of changing with the icon.

Unrelated to this change, but worth mentioning since it is the same
button: the two controls also disagree on wording. The pane calls it
"Zoom In"/"Zoom Out", the agent panel "Enable/Disable Full Screen".
Because `Workspace::zoomed` is a single slot, activating any other
panel's zoom drops the agent panel back out of full screen — which reads
as surprising under the "full screen" name and unsurprising under
"zoom". Happy to align the wording in a follow-up if you'd like, but I
left it alone here since it is a naming call rather than a fix.

Release Notes:

- Fixed the agent panel's full screen button not appearing active while
full screen was enabled.

---------

Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
2026-08-02 12:45:44 +00:00
ce6f3af5f7 remote: Fix incorrect arguments passed to SCP & SFTP (#56080)
All arguments passed to the initial remote connection command were
initially blindly passed to `scp` or `sftp` command line.
This is an issue with some arguments like "-X" or "-Y" that either does
not exist, or have a different semantic.
This PR introduces a denylist of arguments before crafting the command
to execute.

Reproduce steps:

1. Create a new remote connection, e.g `ssh -X user@192.168.1.1`
2. Expect the upload of the remote server to fail with a message saying
that '-X' is not a valid argument for `ssh` / `sftp` depending on your
setup.

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)
- [ ] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable

Release Notes:

- Fixed wrong arguments that may be passed to scp or sftp command when
pushing remote files.

---------

Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
2026-08-02 09:09:11 +00:00
Kirill Bulatov 90d024b88a Fix the display point out of range panic due to wrong coordinate space used (#62055)
Closes ZED-AKV
Closes ZED-ANB

Follow-up to https://github.com/zed-industries/zed/pull/61153

The original PR mixed up the coordinate spaces, and the newly added
methods used buffer rows (as the existing code did before that PR), but
the new code uses `FoldMap` which expects a tab row instead of the
buffer one.

Release Notes:

- Fixed a panic when selections are added by tab-expanded column
2026-08-01 21:34:47 +00:00
Kirill Bulatov 21f16f7b5b Speed up cargo build -p zed compilation (#62059)
Splits the crate graph.
Before, the compilation graph: `editor → picker_preview → search →
project_panel → open_path_prompt → recent_projects → title_bar →
collab_ui → zed`
After, the compilation graph: `editor → picker_preview → search →
agent_ui → sidebar → zed`

With sccache disabled and project fully built, `touch
crates/editor/src/editor.rs` and `cargo build -p zed` took time
Before (5e1fd392f6): 13.19s
After: 11.85s (-10.2% speed up)

Each commit contains a separate compilation instructions, and a test in
the final commit.
The main approach is to split coupled crates and replace them with
`zed_actions` and move some shared functionality into `git_ui_core` new,
shared module.

I've also tried to add a test to prevent common pitfalls, but not sure
I'm happy with the end result — can remove it if it looks too synthetic.

Release Notes:

- N/A
2026-08-01 19:42:37 +00:00
Mikayla MakiandBen Kunkle 5e1fd392f6 git: Add diff_base setting for showing changes since the default branch (#61501)
# Objective

Let git indicators — the editor gutter, file colors, and `git::Diff` —
show all changes on the current branch relative to its merge base with
the default branch, instead of only uncommitted changes.

Supersedes #60398; thanks to @samuelcolvin for the original
implementation and motivation.

Closes FR-135

## Solution

- New `git.diff_base` setting (`"head"` | `"default_branch"`), applied
live and toggleable per session from the editor controls menu ("Diff
Against Default Branch").
- Statuses come from a real merge-base-to-worktree tree diff (`git diff
--merge-base`), so local edits that revert branch changes correctly show
as unchanged.
- `GitStore` shares one `DiffBufferList` per repository with the Branch
Diff view; `repo_snapshots` and `project_path_git_status` keep returning
index/worktree truth, while display surfaces use separate `display_*`
APIs.
- `BufferDiff` now records what its base is (`DiffBaseKind`); hunks
whose base isn't HEAD are read-only in the gutter — stage/restore
buttons and keybindings are inert, so committed work can't be silently
rewritten.
- `git::Diff` follows the setting; new `git::DiffHead` always opens the
HEAD diff; `git::BranchDiff` is renamed `git::DiffBranch` (deprecated
alias kept).

Tradeoffs / known limitations:

- Hunk-level staging is unavailable while in `default_branch` mode
(whole-file staging via the git panel still works). Staging just the
uncommitted sub-ranges of a branch hunk is a follow-up.
- Remote hosts running an older server ignore the new
`GetTreeDiff.includes_worktree` proto field and degrade to
committed-changes-only branch diffs.
- Repositories with no resolvable default branch fall back to
HEAD-relative behavior; a failed first resolution retries on the next
branch-list change.

## Testing

- Real-git-repo tests for the merge-base-to-worktree diff's edge cases:
files recreated after index deletion, committed deletions recreated on
disk, and symlinks.
- GPUI tests for status semantics (a branch change reverted on disk
shows clean), `git::Diff` routing, live setting changes, and read-only
hunk enforcement (restore/stage leave buffer and index untouched).

## 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:

- Git: Added a `git.diff_base` setting (`"head"` or `"default_branch"`)
that makes the editor gutter, file colors, and diff view show all
changes on the current branch since its merge base with the default
branch, instead of only uncommitted changes.

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>
2026-07-31 19:57:13 +00:00
Sathwik Chirivelli 5e03f2d387 solo_diff_view: Hide multibuffer controls in solo diffs (#61998)
# Objective

Remove the redundant expand/collapse-all-files control from solo diff
views. A solo diff represents one file, so the multibuffer-wide control
is not applicable and duplicates the per-file full-file/changes-only
toggle.

## Solution

Treat searchable items that intentionally hide their underlying
splittable editor as ineligible for the generic multibuffer
expand/collapse control.

This keeps search bound to the focused side of a split diff while
preserving the existing expand/collapse controls in Project Diff, Branch
Diff, staged/unstaged diffs, Commit View, and other regular multibuffer
views.

## Testing

- `cargo -q test -p search test_uses_primary_left_when_in_multi_buffer
-- --nocapture`
- `cargo -q test -p search buffer_search -- --nocapture` (26 passed)
- `git diff --check`
- Manually verified the solo diff no longer shows the
expand/collapse-all-files control and that the full-file/changes-only
toggle remains available.

Reviewers can open a file from Project Diff, use Option+Enter to switch
between Project Diff and Solo Diff, and verify search follows the
focused side in split diff mode.

## 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

## Showcase

Solo diff views now retain the full-file/changes-only toggle without
showing the unrelated expand/collapse-all-files control.

<details>
  <summary>Click to view showcase</summary>
<img width="1120" height="724" alt="Screenshot 2026-07-31 at 6 44 50 PM"
src="https://github.com/user-attachments/assets/58519dda-d77a-410e-bbe2-0aebfac93fbd"
/>

</details>

---

Release Notes:

- Fixed a redundant expand/collapse-all-files control appearing in solo
diff views.
2026-07-31 18:11:47 +00:00
Lena 98f39bfcca Duplicate Bot: Improve candidate retrieval (v6) (#62011)
Release Notes:

- N/A
2026-07-31 15:45:04 +00:00
Tai Nguyen f56ff65c92 editor: Stop opt-left on the right side of punctuation between words (#61916)
Closes #61884

Release Notes:

- Fixed Option+Left stopping to the left of punctuation between words
Video URL: https://files.catbox.moe/8d5g2t.mp4
2026-07-31 15:19:16 +00:00
Danilo Leal f99da3a491 Add dedicated icon for the GPT Subscription provider (#62009)
Just to make it easier to differentiate when using an OpenAI model
coming from the GPT Subscription vs. from the API key.

Release Notes:

- N/A
2026-07-31 15:06:40 +00:00
Tim VermeulenandMrSubidubi 779c35d256 acp_thread: Disable Git's configured pager in agent terminals (#61732)
Applies the same fix as #43277 to Zed's native agent, which indeed fixes
this issue for me locally (which I could only reproduce when
specifically telling the agent to not use `--no-pager`, FWIW).

Closes #42943

## 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

---

Release Notes:

- Fixed hang when the Zed Agent runs a `git` command with a pager
configured.

---------

Co-authored-by: MrSubidubi <finn@zed.dev>
2026-07-31 13:48:46 +00:00
Matei Opreaanddino 2318f45f4c multi_workspace: Allow closing of currently selected project (#60602)
# Objective

When working across multiple projects open in the same window, closing
the **currently selected** project requried a two-step flow: switch to
another project first then close the one that you initially wanted to.
The project's close button was hidden on the active project, so the only
way to remove the project was to navigate away first.

## Solution

Always render the close button in the project picker, including for the
active project. Closing the active project now removes it and switches
to a neighboring project automatically.
This worked well for local projects but broke for remote ones. For any
remote neighbor it actually fell through to an empty workspace.

There are 3 cases now: 
1. Activate the neighbor's already open workspace when one exists (now
either if its local or remote)
2. Load the neighbor through the host-aware **find_or_create_workspace**
which connects and opens a remote neighbor when it isn't already open
3. Fallback to an empty workspace only when no neighbor remains

## Testing

- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't 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

## Showcase

> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.

- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!

While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:

<details>
  <summary>Click to view showcase</summary>


https://github.com/user-attachments/assets/6e1d1968-702a-4f13-9442-5e90fe7ae9f9

</details>

---

Release Notes:

- Improved the project switcher to allow closing the currently selected
project, switching to a neighboring project (local or remote)
automatically.

---------

Co-authored-by: dino <dinojoaocosta@gmail.com>
2026-07-31 12:55:11 +00:00
Lena 59cb143caf Fix triage queue board matching every open issue (#61993)
Our date filter used two qualifiers ("created:>START created:<=END"),
which isn't valid range syntax, so GitHub ignored it and returned every
open issue. Use a single "created:START..END" range. Also fix the window
math, which was a business day too recent and excluded its start day.

Release Notes:

- N/A
2026-07-31 12:44:52 +00:00
CarboFish 1ac840ab2f workspace: Fix dropping Windows files onto a WSL remote (#57146)
Dropping a local Windows file (e.g. `E:\foo\bar.md`) onto a Zed window
connected to a WSL remote previously forwarded the path verbatim. On the
remote Linux side `E:\foo\bar.md` isn't absolute, so it got joined with
the worktree CWD, producing nonsense like `/home/user/E:\foo\bar.md` and
a "failed to canonicalize root path" error from the worktree scanner.

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

Closes #49915

before:
<img width="1343" height="331" alt="before"
src="https://github.com/user-attachments/assets/193cfbf6-d07e-4c5f-b941-75e4a0c62345"
/>

after:
<img width="1181" height="288" alt="after"
src="https://github.com/user-attachments/assets/7ad56e13-3723-4b48-aa3d-59eca6038a7f"
/>


Release Notes:

- Fixed dragging local Windows files onto a Zed window connected to a
WSL remote.
2026-07-31 10:49:11 +00:00
Erik W c7aea6cbbd gpui_linux: Add wl_data_source support for outbound drags on Wayland (#61947)
# Objective

- Enable drag'n'drop from Zed in Wayland.
- Partially addresses #13186
- Related to #58161, #61940

## Solution

- Implement wl_data_source support for outbound drags on Wayland

## Testing

Tested on KDE Wayland, kwin 6.7.3
I dragged files to Firefox, to other Zed windows and into Dolphin.  

## 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

## Showcase

Can try to record if requested

Release Notes:

- Added support for dragging files from the Project Panel to external
Linux Wayland apps.
2026-07-31 10:29:47 +00:00
Kirill Bulatov 56cf49bc1a Fix parameter colors for gruvbox themes (#61983)
Left before, right after:
<img width="1728" height="370" alt="image"
src="https://github.com/user-attachments/assets/3229ba26-18e6-415e-8df3-25fa5fea43aa"
/>

Closes https://github.com/zed-industries/zed/issues/61976

https://github.com/zed-industries/zed/pull/61134 picked a wrong color
for `variable.parameter` that exactly matched `variable.special` and
caused visual conflicts.
Instead, use `variable` for such colors.


Release Notes:

- Fixed Gruvbox parameter colors
2026-07-31 10:27:51 +00:00
Mohammad Adnaan 9c7a5c9485 docs: Document the --existing CLI option (#61979)
# Objective

Fixes #61730.

Document the `-e`, `--existing` CLI option, which was missing from the
CLI reference.

## Solution

- Added documentation for the `-e`, `--existing` CLI option.
- Added a usage example.
- Updated the default behavior note to include `-e`.

## Testing

- Built the documentation locally using `mdbook`.
- Verified that the new section renders correctly in the CLI Reference
page.
- Confirmed the example and updated default behavior note appear as
expected.

## Self-Review Checklist

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards (Not applicable)
- [ ] Tests cover the new/changed behavior (Documentation change only)
- [x] Performance impact has been considered and is acceptable

## Showcase

The CLI Reference now includes documentation for the `-e`, `--existing`
option.

<details>
<summary>Documentation Preview</summary>

<img width="935" height="539" alt="Screenshot 2026-07-31 151714"
src="https://github.com/user-attachments/assets/c2e4ad05-a961-4fe1-8c22-5e3a474e96ca"
/>


</details>

---

Release Notes:

- Improved CLI documentation by adding the missing `--existing` option.
2026-07-31 10:02:11 +00:00
Ben Kunkle 4f047acc17 edit_prediction: Prevent v4 cursor marker leaks (#61957)
# Objective

Prevent V4 cursor markers from appearing in edit prediction previews or
accepted edits.

## Solution

Replace the cursor marker with an internal sentinel before sub-line
diffing, so matching source text cannot reconstruct the marker.

## 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
2026-07-31 09:53:28 +00:00
Yassen Damyanov b209000d28 Make Install script reject 32-bit Linux architectures (#61919)
# Objective

Prevent successful installations on 32-bit Linux architectures where the
`zed` binary will **fail to execute** post-installation. Rather, fail at
installation time with a proper verdict.

`script/install.sh` maps `uname -m` onto the two architectures Zed
publishes builds for. Two of the matchers named 32-bit userlands and
mapped them onto a 64-bit tarball:

- `linux-armhf` mapped to `aarch64`
- `linux-i686*` mapped to `x86_64`

Neither can execute the binary it selected. Tested on i386 Debian Trixie
container: the installer downloaded, unpacked, symlinked and reported
success, and the failure surfaced later as an exec error -- see
[Showcase](##showcase).

Thus the installer's correct behavior would be to reject the 32-bit
architecture and terminate with an "unsupported" verdict.


## Solution

Remove the case-statement-based mapping of `linux-armhf` to `aarch64`,
and of `linux-i686*` to `x86_64`.


## Testing

Tested in isolation, simulating supported and unsupported platforms, and
supported and unsupported architectures:

| Platform | `uname -m` | Outcome |
| --- | --- | --- |
| Linux | `x86_64` | ✅ Installed — resolves to `x86_64`, symlink created
|
| Linux | `i386` | ❌ Unsupported — `i386` doesn't match glob `x86*` (no
case handles plain i386 anyway |
| Linux | `i686` | ❌ Unsupported — same reason |
| Linux | `aarch64` | ✅ Installed — resolves to `aarch64` |
| Linux | `arm64` | ✅ Installed — resolves to `aarch64` |
| Linux | `armv7l` | ❌ Unsupported — no 32-bit ARM case |
| Linux | `riscv64` | ❌ Unsupported |
| Darwin | `arm64` | ✅ Installed — resolves to `aarch64`, copied to real
`/Applications/Zed.app`, symlink created; |
| Darwin | `x86_64` | ✅ Installed — resolves to `x86_64`, copied to real
`/Applications/Zed.app`, symlink created |
| Darwin | `i386` | ❌ Unsupported — no case for macOS 32-bit |
| FreeBSD | `x86_64` | ❌ Unsupported platform - expected |

This is all correct behavior. Successful installations are expected to
work. Unsupported architectures are detected and rejected as unsupported
during installation.

## Showcase

```plaintext
~# file /usr/bin/dash  # a sample executable showing the 32-bit arch
/usr/bin/dash: ELF 32-bit LSB pie executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=7e2e8652114c8c2ae595b6f78798716a9ba07671, for GNU/Linux 3.2.0, stripped

~# file .local/zed.app/bin/zed
.local/zed.app/bin/zed: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e550eeb1d97f0cdac2460de672bfa36e9e3f6e25, not stripped

~# .local/zed.app/bin/zed
bash: .local/zed.app/bin/zed: cannot execute: required file not found
# It cannot find  ELF 64-bit interpreter /lib64/ld-linux-x86-64.so.2 -- this is
# a 32-bit container on a 64-bit host. On a genuine 32-bit host it would fail with:
# `Exec format error`.
```


## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Locally conducted tests cover the new/changed behavior

---

Release Notes:

- N/A
2026-07-31 09:48:15 +00:00
Tai Nguyen a5615f092d Reset panel saved size when default_size changes (#61855)
Closes #59235

When a panel's `default_size` changes (e.g. `git_panel.default_width` is
edited in settings), the persisted per-workspace size is now cleared so
the new default takes effect immediately. Previously the saved dragged
size took precedence forever, making `default_width` effectively useless
after the first manual resize.

This fix is at the Dock level (`crates/workspace/src/dock.rs`), so it
applies to all panels — Git Panel, Project Panel, Terminal Panel, etc.

Release Notes:

- Fixed panel `default_width` setting being ignored after manually
resizing the panel


https://github.com/user-attachments/assets/97ef69b2-387f-4e29-bc4c-0f336f24eb0b
2026-07-31 09:27:11 +00:00
Tim Vermeulen 0b3621db47 terminal_view: Fix inline terminal clipping its first line of output (#61939)
Fixes #53518:

| before | after |
| --- | --- |
| <img width="790" height="458" alt="before"
src="https://github.com/user-attachments/assets/2314fb13-6782-4397-a022-0252c82bf7b9"
/> | <img width="790" height="458" alt="after"
src="https://github.com/user-attachments/assets/1058970c-ae0a-4a9f-8f14-84b810ddaba4"
/> |

`TerminalBounds::line_height` floors `height / line_height`, so
`TerminalElement::request_layout` does the inverse logic to calculate
the height for inline terminals with `displayed_lines * line_height`,
but intermediate rounding in `to_taffy` could break this. Fixed by
rounding up to the next integer device pixel in
`TerminalElement::request_layout`.

## 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 the first line of terminal output sometimes being hidden in the
agent panel.
2026-07-31 08:56:46 +00:00
Rabindra Kumar Meher 864ff0ba3f Run string-form dev container lifecycle commands in /bin/sh -c (#60792)
# Objective

Fixes #60228.

String-form dev container lifecycle commands are currently executed by
splitting the command on spaces and running the first token directly.
This means shell features such as variable expansion, pipes,
redirection, and command chaining do not work.

According to the Dev Container specification, string-form lifecycle
commands should run through `/bin/sh -c`, while array-form commands
should continue to execute directly.

## Solution

- Added `LifecycleScript::shell_command()` to wrap string-form commands
in `/bin/sh -c`.
- Updated string deserialization to use `shell_command()` instead of
splitting on spaces.
- Kept array-form commands unchanged.

## Testing

- Ran `cargo test -p dev_container` (107 tests passed).
- Added a regression test to verify string-form commands run through
`/bin/sh -c`.
- Added a regression test to verify array-form commands still execute
directly.
- Updated the existing deserialization tests to match the expected
behavior.

## 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
- [x] Tests cover the new behavior
- [x] Performance impact has been considered and is acceptable

---

Release Notes:

- Fixed string-form dev container lifecycle commands so they execute
through `/bin/sh -c` as required by the Dev Container specification.
2026-07-31 08:53:21 +00:00
9rum 58a3c0fa0e docs: Fix mismatch of default dock position setting in project panel (#61971)
# Objective

Fixes #56277, the document-source mismatch of the default dock position
setting in project panel.
I also have found that the visual customization guide has the same
issue, so this PR fixes it too.

## Solution

I have updated the corresponding markdown files.

## Testing

I have tested the updated documents by rendering them in my local.

## 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
2026-07-31 07:38:17 +00:00
AidanVandLukas Wirth 5f180e06dc editor: Add multiple_selections key context (#60018)
# Objective

- I would like to have the Vim command `z z` do different actions
depending on if I have multiple selections. If I only have one selection
I want `z z` to center my only selection (current behavior); however, if
I have multiple selections I would like `z z` to run
`editor::OpenSelectionsInMultibuffer`. This PR does not add this
specific functionality (happy to be convinced otherwise), but it does
let users add this type of functionality.

## Solution

- Add a new key context field that is active only when there are
multiple selections.

## Testing

- Changes are quite small. A test on this would really be testing other
parts of the code-base more than this change.

## 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

## Showcase



https://github.com/user-attachments/assets/2559e218-d6fa-492a-949b-f4ab8b880f28


This allows us to add something like the following to the `keymap.json`:

```json
  {
    "context": "VimControl && !menu && multiple_selections",
    "bindings": {
      "z z": "editor::OpenSelectionsInMultibuffer",
    },
  },
```

which lets us change the functionality of a keystroke based on if there
are multiple selections.

This video has the following keystroke sequence:

`z z` (Center the cursor normally)
`5 g l` (Select the 5 next occurrences of the word under the cursor)
`z z` (Open selections in multi-buffer) (Previously `z z` in this
context would just center the last selection)


https://github.com/user-attachments/assets/a0dc1813-5420-4cda-a1ec-99e6681680e7

---

Release Notes:

- Added `multiple_selections` keystroke context

Co-authored-by: Lukas Wirth <lukas@zed.dev>
2026-07-31 06:49:53 +00:00
aetos 2ec2997789 Honor window preference when opening remote projects (#61048)
# Objective

Fixes #60873.

`projects::OpenRemote` has two handling paths:

- The remote-project picker handles `from_existing_connection: false`.
- The active remote workspace handles `from_existing_connection: true`.

The existing-connection path ignored the action’s `create_new_window`
field. Consequently, selecting another project from an active SSH
workspace always created a new OS window—even when:

- the action explicitly specified `create_new_window: false`, or
- `create_new_window` was omitted and `default_open_behavior` was set to
`"existing_window"`.

The expected behavior is:

| `create_new_window` | `default_open_behavior` | Result |
|---|---|---|
| `true` | Any value | Open a new window |
| `false` | Any value | Reuse the current window |
| Not specified | `"new_window"` | Open a new window |
| Not specified | `"existing_window"` | Reuse the current window |

## Root cause

The `from_existing_connection: true` action handler forwarded the
selected paths to `open_new_ssh_project_from_project` without reading
`action.create_new_window`.

That helper then called `open_remote_project` with:

```rust
OpenOptions {
    workspace_matching: WorkspaceMatching::None,
    ..Default::default()
}
```

This left `OpenOptions::requesting_window` as `None`. The remote-opening
path interprets a missing requesting window as a request to create a new
window, so the action always opened one regardless of the action payload
or workspace setting.

## Solution

The existing-connection action handler now resolves `create_new_window`
before starting the asynchronous open operation.

When the action does not provide an explicit value, it uses the same
`WorkspaceSettings::default_open_behavior` fallback as the normal
project-opening path:

```rust
let create_new_window = action.create_new_window.unwrap_or_else(|| {
    matches!(
        WorkspaceSettings::get_global(cx).default_open_behavior,
        DefaultOpenBehavior::NewWindow
    )
});
```

The resolved boolean is passed to `open_new_ssh_project_from_project`.

The helper translates that policy into the existing `OpenOptions` API:

- When `create_new_window` is `true`, `requesting_window` remains
`None`.
- When it is `false`, `requesting_window` is set to the current
`MultiWorkspace` window handle.

The existing `WorkspaceMatching::None` behavior is intentionally
preserved. This PR changes only which OS window hosts the opened remote
workspace; it does not change workspace matching, path selection,
connection handling, telemetry, or error behavior.

### Why resolve the setting in the action handler?

The action handler is where the explicit action value and the workspace
setting are both available. Resolving the option there also matches the
neighboring local and remote project-opening flows.

Passing the resolved boolean keeps the helper’s input aligned with the
user-facing policy while allowing the helper to translate it into the
lower-level `requesting_window` representation.

### Why not change `open_remote_project`?

`open_remote_project` is shared by several remote-opening flows.
Inferring an active window inside that function would change the
semantics of unrelated callers that deliberately omit
`requesting_window` to create a new window.

Keeping the change in the existing-connection action path limits the
behavioral change to the reported issue.

### Dependency impact

The regression test needs a real mock remote workspace so that it
exercises the same action registration and remote-client checks as the
application.

The following test-support development dependencies were enabled for the
`zed` crate:

- `fs`, for `FakeFs`
- `remote`, for the mock `RemoteClient`
- `remote_server`, for `HeadlessProject`

These are development-only dependencies and do not change Zed’s runtime
dependency graph. The `Cargo.lock` change records `remote_server` as a
dependency of the `zed` package under the test configuration.

## Testing

Added an end-to-end GPUI regression test:

```text
test_open_remote_from_existing_connection_reuses_window
```

The test:

1. Creates a fake remote filesystem with two project directories.
2. Starts a headless mock remote server.
3. Opens the initial project through `open_remote_project`.
4. Verifies that exactly one window exists.
5. Transitions the mock client to `ServerNotRunning`.
6. Injects `/other-project` as the path-prompt result.
7. Dispatches:

   ```rust
   zed_actions::OpenRemote {
       from_existing_connection: true,
       create_new_window: Some(false),
   }
   ```

8. Verifies that the application still has exactly one window.
9. Answers the expected failed-reconnection prompt with `Cancel`,
allowing the detached action task to terminate cleanly.

The unavailable-server step keeps the test focused on window routing. It
avoids requiring a second successful mock SSH lifecycle while still
exercising the real action handler, path prompt, remote workspace,
helper, and `open_remote_project` entry point.

Before the production change, the test failed with:

```text
create_new_window: false should reuse the current window

left:  2
right: 1
```

After the change, the test passes.

### Verification performed

Focused regression test:

```sh
cargo test -p zed test_open_remote_from_existing_connection_reuses_window
```

Result:

```text
1 passed; 0 failed
```

GPUI scheduler sweep:

```sh
ITERATIONS=20 cargo test -q -p zed test_open_remote_from_existing_connection_reuses_window -- --nocapture
```

Result:

```text
Seeds 0 through 19 passed
```

Complete `zed` test target, run serially because several existing tests
share global session state:

```sh
cargo test -q -p zed -- --test-threads=1
```

Result:

```text
74 passed; 0 failed; 1 ignored
```

Formatting:

```sh
cargo fmt -p zed --check
```

Repository-prescribed Clippy check:

```sh
./script/clippy -p zed
```

This ran the release, all-targets, all-features configuration with
warnings denied and completed successfully.

The change and test were run on Fedora Linux.

### Manual verification

This can also be verified interactively:

1. Connect to a project over SSH.
2. Bind or dispatch:

   ```json
   [
     "projects::OpenRemote",
     {
       "from_existing_connection": true,
       "create_new_window": false
     }
   ]
   ```

3. Select another directory on the connected host.
4. Confirm that the project opens in the current Zed window.
5. Repeat with `create_new_window: true` and confirm that a new window
is created.
6. Omit `create_new_window` and confirm that the result follows
`default_open_behavior`.

No screenshot is included because this does not change rendered UI; it
changes which window contains the opened remote workspace.

## Scope and impact

- No unsafe code was added.
- No remote protocol or transport behavior changed.
- No settings schema changed.
- No action schema changed.
- No user-facing strings changed.
- No new runtime dependencies were introduced.
- The added work is limited to resolving one optional boolean and
downcasting the current window handle when reuse is requested.
- The window-handle lookup occurs only when this action is dispatched
and has no meaningful performance impact.

## 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 opening a project from an existing remote connection to respect
the configured window behavior.
2026-07-31 06:45:43 +00:00
Xin Zhao 2610332077 path: Normalize Windows paths independently of the host platform (#61374)
# Objective

Zed's `PathStyle` is designed to handle paths across platforms. Its
behavior should depend only on the selected path style, not on the
platform where Zed is running. This is essential for remote development,
where the local and remote platforms may differ.

While fixing bugs involving Windows remote targets, I found that
`PathStyle::normalize` does not behave consistently across host
platforms. For `PathStyle::Windows`, it delegates to
`crate::normalize_path`:


https://github.com/zed-industries/zed/blob/914e1c9873b6b85bfeedc5b58e8270885bdd532e/crates/path/src/path.rs#L237-L263

That function uses `Path::components()`, which interprets paths
according to the host platform. As a result, when Zed runs on a
Unix-like system and connects to a Windows remote, something maybe wrong
here.

`PathStyle::normalize` should instead interpret paths according to the
selected `PathStyle`, independently of the host platform.

## Solution

Implement Windows path normalization directly in `PathStyle::normalize`
without relying on `std::path::Path` parsing.

The new implementation:

- Recognizes drive-letter, rooted, relative, and UNC paths.
- Treats both `\` and `/` as Windows path separators.
- Resolves `.` and `..` components lexically.
- Uses `\` as the normalized Windows path separator.
- Produces the same result regardless of the host platform.

## Testing

New test is added and tested with `cargo test -p util`, this test would
fail on current main branch.

## 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 or Added/Fixed/Improved ...
2026-07-31 06:41:53 +00:00