Experiment with allowing users to manage terminal sessions along with
threads in the sidebar.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
We were incorrectly calling this with a thread handle, additionally
changing the process priority here doesn't make sense, so just drop
this.
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This fixes a race condition where the thread would not get the LSP tools
at startup if the feature flag was not resolved yet.
We now always add the tools, but filter them out when we start a new
turn if the feature flag is not set.
Release Notes:
- N/A
cc @SomeoneToIgnore
## Summary
Follow-up to https://github.com/zed-industries/zed/discussions/55352,
where the conclusion was to split `editor.rs` incrementally by topic
instead of all at once.
This mechanically extracts two editor topics into focused sibling
modules:
- `crates/editor/src/code_actions.rs`
- `crates/editor/src/completions.rs`
One odd boundary remains: `Editor::context_menu()` is still a general
context-menu accessor, but it now lives in `code_actions.rs` because it
was part of the moved code actions block and is also used by
completions, Vim tests, agent UI, and the quick action bar. Would you
prefer that generic context-menu accessor stay in `editor.rs` for now
until context-menu code gets its own extraction?
## Testing
- `cargo check -p editor --lib`
- `cargo check -p editor --tests`
- `cargo check -p editor --lib --features test-support`
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
When the "+" button created a fresh draft, `active_initial_content`
fell back to the raw editor text when the async `draft_prompt`
observer had not yet resolved. That raw text contains fold placeholder
strings (e.g. "selection") rather than the mention links, so creases
and their registered URIs were dropped from the carried-over draft.
Related to https://github.com/zed-industries/zed/issues/53981.
Release Notes:
- Fixed a bug where selection mentions would resolve to the literal
`selection` rather than the URI in draft threads.
## Summary
Markdown preview tables kept text pinned to the top of a row when a
neighboring cell contained a taller image. This made mixed
text-and-image tables look unbalanced and inconsistent with common
editor behavior. This change makes table text stay visually centered
within taller rows so Markdown tables are easier to scan and match
expected rendering more closely.
## Before / After
| Before | After |
| --- | --- |
| <img width="849" height="869" alt="Screenshot 2026-04-08 at 19 55 50"
src="https://github.com/user-attachments/assets/b3751bff-3750-4ca1-8997-6f5265e4d291"
/> | <img width="898" height="734" alt="Screenshot 2026-04-08 at 21 47
31"
src="https://github.com/user-attachments/assets/d853c0a1-800c-4a2a-aec9-e0ef08453fa7"
/> |
## References
Inspired by comparing this with VS Code preview
<img width="1286" height="878" alt="Screenshot 2026-04-08 at 21 54 06"
src="https://github.com/user-attachments/assets/8dbbfe28-9980-4012-94f1-1b5b3503065b"
/>
Release Notes:
- Improved Markdown preview table cells to vertically center content in
tall rows and respect column alignment from the table header.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
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 #ISSUE
Release Notes:
- Added a setting
[vim.show_edit_predictions_in_normal_mode](zed://settings/vim.show_edit_predictions_in_normal_mode)
to control whether edit predictions are shown in normal mode.
Fixed an issue where the leak detector would sometimes cause panics when
running unit evals. Fixed this by matching the tear-down logic that we
use in the `gpui::test` macro
> thread 'tools::evals::edit_file::eval_from_pixels_constructor'
(14336149) panicked at crates/gpui/src/app/entity_map.rs:1116:9:
Exited with leaked handles:
Leaked handle for entity language::buffer::Buffer (EntityId(50v1)):
Release Notes:
- N/A
## Problem
A Sentry-reported crash on Windows (Intel Iris Xe Graphics, v1.0.1):
```
index out of bounds: the len is 1 but the index is 1
```
panicking at `DirectXAtlasState::texture` in
[`crates/gpui_windows/src/directx_atlas.rs`](https://github.com/zed-industries/zed/blob/main/crates/gpui_windows/src/directx_atlas.rs):
```rust
AtlasTextureKind::Subpixel => {
&self.subpixel_textures[id.index as usize].as_ref().unwrap()
}
```
## Root cause
After a GPU device-lost recovery, GPUI's view cache replays stale
`AtlasTile`
references from the previous frame's `paint_operations` via
`Scene::replay`.
1. **Atlas grows past one texture.** A long enough session pushes
`subpixel_textures.textures.len() ≥ 2` (easy on Iris Xe at the default
1024×1024 atlas size). Top-level views in Zed use `cached(...)`, so
their
`AnyViewState.paint_range` records into
`rendered_frame.scene.paint_operations`,
referencing both index `0` and index `1`.
2. **Device lost.** `handle_device_lost` clears every `AtlasTextureList`
(`textures.len() == 0`)
and `tiles_by_key`, then sets `skip_draws = true`.
3. **`WM_GPUI_FORCE_UPDATE_WINDOW` arrives.** `mark_drawable()` flips
`skip_draws` back to `false` and `request_frame` runs with
`force_render: true`.
4. **The cache hit.** Inside `Window::draw`, `AnyView::prepaint`'s cache
check (`!dirty_views.contains(...) && !window.refreshing`) succeeds for
every cached view because the recovery doesn't touch invalidator state
and
`force_render` doesn't propagate into `Window`. `AnyView::paint` calls
`window.reuse_paint` → `Scene::replay` → `primitive.clone()`, which
(since
`SubpixelSprite`/`AtlasTile` are `Copy`) verbatim copies a
`Primitive::SubpixelSprite { tile: { texture_id: { index: 1, ... }, ...
} }`
into `next_frame.scene`.
5. **Atlas regrows to one.** Dirty/uncached parts of the same frame
(caret, animations, anything that called `cx.notify`) fall through to
`paint_glyph` → `get_or_insert_with` → `push_texture`, growing
`subpixel_textures.textures` from `0` to **`1`** with index `0` valid.
6. **Panic.** After `mem::swap`, `rendered_frame.scene` contains a mix
of
fresh `index = 0` and replayed `index = 1` sprites. `Scene::batches`
emits separate batches per `texture_id`; the `index = 1` batch reaches
`atlas.get_texture_view` → `subpixel_textures[1]` → panic with
`len = 1, index = 1`.
The two earlier related fixes do not catch this:
- **#52389 / c8f20c78** (`if force_render { mark_drawable }`) protects
the
200 ms recovery sleep — pending `WM_PAINT`s carry `force_render = false`
and so do not clear `skip_draws`. But `WM_GPUI_FORCE_UPDATE_WINDOW`
carries `force_render = true`, so `mark_drawable` runs, then
`Window::draw`'s `reuse_paint` still reproduces stale tiles.
- The unmerged Windows draft `2e5d890e37`
(`force_render_after_recovery`)
similarly only forces the forced-render branch — it doesn't bypass the
view cache.
## Fix
Two parts:
**1. Bypass the view cache on a forced draw (cross-platform).**
In the platform-agnostic `request_frame` closure in `Window::new`, call
`window.refresh()` whenever `RequestFrameOptions::force_render` is
`true`.
`Window::refresh` is the documented escape hatch for cached views (per
the
`AnyView::cached` docs: *"The one exception is when [Window::refresh] is
called, in which case caching is ignored."*). With `refreshing = true`
every `AnyView::prepaint` cache check fails, every cached view fully
repaints, and `paint_glyph` allocates fresh tiles for every glyph, so
`rendered_frame.scene` ends up free of stale `AtlasTile`s.
**2. Add the `force_render_after_recovery` flag on Windows.**
Mirror the Linux fix from #52389: a per-window `Cell<bool>` set after
`WindowsWindowInner::handle_device_lost` succeeds and consumed at the
top
of `draw_window`. Together with the GPUI change above, the first frame
after recovery (whether a stray `WM_PAINT` during the 200 ms recovery
sleep or the explicit `WM_GPUI_FORCE_UPDATE_WINDOW`) is treated as a
forced render that both clears `skip_draws` and bypasses the view cache.
## Testing
- `script/clippy -p gpui` is clean.
- I do not have a Windows toolchain available locally, so I have not
cross-compiled `gpui_windows`. Reviewers with Windows access — please
smoke-test on a machine where the device-lost path can be exercised
(Intel iGPU, suspend/resume, or running a TDR-inducing test on a GPU
driver).
## Related
- Sentry issue ID 7457971403 (DirectX subpixel atlas crash, Intel Iris
Xe).
- Builds on / fixes the residual gap in #52389 (`gpui_linux: Force scene
rebuild after GPU device recovery"). The GPUI change here also hardens
the corresponding Linux path against the same `reuse_paint` mechanism.
Release Notes:
- Fixed a crash on Windows when the GPU device is lost and recovered
during use (typically driver crash, suspend/resume, or display
reconfiguration, most commonly on Intel iGPUs)
If you implement can_save, you need to also support reload. Fix a bug
introduced in #53236
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed missing reload implementation for markdown preview.
In the case where the model would respond with `new_text` before
`old_text`, we would just emit an empty `old_text`, because the parsing
layer was operating under the assumption that `old_text` occurs before
`new_text`.
We now hold back new text chunks if we receive them first, and only emit
them once old_text is complete.
In addition to that we also need to handle the case where the first
chunk contains `old_text` and `new_text`. In that case we don't know
which one of the two fields have finished streaming, since we can't rely
on the ordering anymore. Therefore we hold back all events until we
receive the full edit, and emit a single OldTextChunk (done = true) and
a single NewTextChunk (done = true)
Closes#55398
Release Notes:
- agent: Fixed an issue where editing would sometimes fail for specific
models (Deepseek v4)
…/` URI
The ESLint adapter was sending `workspaceFolder.uri` as a raw filesystem
path (e.g. `/Users/foo/project`) instead of a proper `file://` URI (e.g.
`file:///Users/foo/project`).
This caused the vscode-eslint server's `workingDirectory: { mode: "auto"
}` to fail when resolving the workspace root, falling back to the linted
file's directory as the working directory. As a result,
`eslint-import-resolver-typescript` could not locate `tsconfig.json`,
breaking path alias resolution for rules like `import/order` — producing
different lint results compared to VS Code.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A or Added/Fixed/Improved ...
`AcpThread::status` is purely `running_turn.is_some()`. The cleanup that
takes `running_turn` sat below the early-return guard that fires when
the prompt response oneshot resolves to `Err(Cancelled)` (the inner
`send_task` was dropped before `tx.send`). Any code path that drops the
in-flight `send_task` therefore left the panel stuck in `Generating`.
Reordered so cleanup runs before the dropped-tx guard; the same-turn
invariant is preserved.
Related to #47928 (partial — that issue also has an upstream
`claude-agent-acp` component this PR does not address).
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed agent panel staying in a generating state when the underlying
prompt task was cancelled before completing
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] 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)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Change the actions in docs to adopt the right format.
Release Notes:
- N/A
Closes#24820
This PR fixes the bug specified in issue
https://github.com/zed-industries/zed/issues/24820, now the matching
function checks if the cursor is above a comment or a directive before
defaulting to a bracket range as neovim does.
It also fixes fixes the `line_end` calculations so that when `%` is
pressed inside a bracket range
https://github.com/user-attachments/assets/f59daa6f-9769-45e8-bb8c-2d533470b59d
Release Notes:
- `fn matching()` checks for `preprocessor directives` or `comments`
before defaulting to any bracket range.
- In `fn matching()`line_end calculations avoid expanding a blank
current line into start..EOF.
This PR introduces native LSP support for Bash by integrating
`bash-language-server`. Combined with the existing Tree-sitter grammar,
Zed now provides a complete, out-of-the-box development experience for
shell scripting.
The implementation is very similar to other npm-managed language
servers. With `shellcheck` installed, standard LSP features—including
diagnostics, code actions, go-to-definition, find-references, and code
completion—work as expected.
Since I am not a frequent user of Bash, I have intentionally limited
this implementation to a standard, "out-of-the-box" setup. I lack the
hands-on experience to identify specific pain points or advanced LSP
features that might require custom integration, so I've avoided adding
any speculative or specialized configurations, especially within the
`LspAdapter` trait.
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#51917
Release Notes:
- Added built-in language server support for Bash
---------
Co-authored-by: Finn Evers <finn@zed.dev>
This PR makes editor diff hunk colors configurable from themes, instead
of hardcoded values.
It introduces 6 new optional theme keys:
- `editor.diff_hunk.added.background`
- `editor.diff_hunk.added.hollow_background`
- `editor.diff_hunk.added.hollow_border`
- `editor.diff_hunk.deleted.background`
- `editor.diff_hunk.deleted.hollow_background`
- `editor.diff_hunk.deleted.hollow_border`
When a theme omits these keys, each color falls back to the existing
version-control color with the previous hardcoded opacity values:
- Light defaults:
- background_opacity = 0.16
- hollow_background_opacity = 0.08
- hollow_border_opacity = 0.48
- Dark defaults:
- background_opacity = 0.12
- hollow_background_opacity = 0.06
- hollow_border_opacity = 0.36
There is an existing feature request
https://github.com/zed-industries/zed/discussions/51667
## Screenshots
I used `Modus Themes` (Modus Vivendi) since these themes provide highly
accessible themes.
Original version:
<img width="3248" height="2120" alt="CleanShot 2026-03-17 at 20 26
41@2x"
src="https://github.com/user-attachments/assets/730be802-835d-436e-a1fc-4c60dcb5fce8"
/>
This version:
<img width="3248" height="2120" alt="CleanShot 2026-03-17 at 20 23
09@2x"
src="https://github.com/user-attachments/assets/785c86d3-147e-437f-9624-9576bc201551"
/>
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:
- Added theme keys for configuring editor diff hunk colors.
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
A follower could crash when following another collaborator into a
newly-opened multibuffer if the leader's recent edits hadn't yet
propagated. The follower would receive the view state with excerpt
anchors pointing into still-unobserved edits, tripping
`panic_bad_anchor`.
The fix waits for each buffer to observe the anchors timestamps before
resolving them, matching what's already done for selection and scroll
anchors. Includes a regression test in `collab` that reproduces the race
deterministically.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed a crash in follow mode when opening multibuffers
Git's `-d` flag deletes a branch only if it's fully merged into its
upstream or HEAD - this is what we were using before, which caused the
"not fully merged" error. The `-D` flag force deletes a branch even with
unmerged changes (equivalent to `--delete --force`).
### Before
Deleting an unmerged branch failed with a "not fully merged" error
toast.
### After
- Deleting an unmerged branch prompts for confirmation to force delete
- Delete button tooltip shows "Hold alt to force delete" hint
- Holding **alt** turns the delete icon red and tooltip changes to
"Force Delete Branch"
- Force delete keybinding: `cmd-alt-shift-backspace`
Release Notes:
- Added confirmation prompt when deleting unmerged git branches, with
option to force delete.
- Added alt+click on delete button to force delete a branch immediately.
Before this PR, `ListState` always used a proportional pending scroll
fraction to preserve the relative scroll position when list items were
resized. This caused text to creep in the agent panel when the scrollbar
was in the middle of the list while the agent was generating text,
because streaming updates changed the logical scroll top slightly.
This PR fixes that behavior by using an absolute offset when only a
subset of items is remeasured, added, or deleted, keeping the logical
top position stable.
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 #ISSUE
Release Notes:
- N/A
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
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
#55770 changed the npm package version spec to `package@<=1.2.3`. On
Windows this fails with `The system cannot find the file specified.`
because:
- `npm` resolves to `npm.cmd`, a batch file. Windows runs `.cmd` files
via cmd.exe, which parses the invocation and treats unquoted `<` as
input redirection.
- The single quotes our shell builder emits around args are PowerShell
string-literal syntax that PS strips during parsing. PS only re-adds
CRT-style transport quotes around native command args containing
whitespace, so `package@<=0.25.3` reaches `npm.cmd` bare and cmd.exe
fails before the batch body even runs.
Switch to npm's hyphen-range syntax (`0.0.0 - <version>`, equivalent to
`<=<version>`), which has no `<`.
Closes#55921
Release Notes:
- Fixed ACP agents failing to launch on Windows with "The system cannot
find the file specified"
Replace all hardcoded `"Zed"` and `"zed"` directory names in
`config_dir()`, `data_dir()`, `state_dir()`, and `temp_dir()` with a
single `APP_NAME` constant in the `paths` crate.
- On macOS/Windows (native paths like Application Support, LocalAppData,
Caches), `APP_NAME` is used directly (`"Zed"`).
- On Linux/FreeBSD (XDG-style paths), `app_name_lowercase()` is used
(`"zed"`).
This ensures forks that change `APP_NAME` automatically get their own
data directories, preventing them from stomping on Zed users' databases
and config.
Release Notes:
- N/A
In #54481, the `handle_event` function was altered to check for an
`Access` event after the callbacks were acquired via a global state
lock. The lock/Vec-collect has enough overhead (or maybe there's enough
lock contention?) that the handler isn't performant enough to keep up
with the volume of inotify events, and its queue fills up, resulting in
[a rescan event getting
emitted](https://github.com/notify-rs/notify/blob/79007aefb41d9f853d00656eb768600e3ea41ee0/notify/src/inotify.rs#L304-L306),
which presumably results in *more* access events for the file as it's
rescanned, which further serve to fill up the inotify queue.
Moving the check for an `Access` event and returning before doing
anything remotely expensive seems to resolve the issues I've been having
lately. Not sure if it addresses the original issue in #53480 though.
Longer-term, it might be prudent to do the event handler's heavy-lifting
in a separate thread with its own event queue, and let the handler
passed to the `notify` crate be just a dumb `tx` sender.
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
Related to #53480Fixes#55829
Release Notes:
- Fixed inotify event queue overflows on linux
Non-functional change that just makes use of our most recent version
bump and helps with readability IMO. Also helps with showing that we are
in fact missing dev extension installation support for Windows ARM at
the moment.
Release Notes:
- N/A
This ensures that upon workflow removal in Rust code, the corresponding
workflow file will not accidentally stay in the repository.
Release Notes:
- N/A
This PR introduces a `UserService` trait to Collab.
This is a step towards moving Collab away from reading user information
directly from the database.
We currently have two implementations for the trait:
- The `DatabaseUserService`, which leverages the existing query methods
to talk to the database
- The `FakeUserService`, which will be used in tests
Once we're ready, we'll be able to replace the `DatabaseUserService`
with a `CloudUserService` to fetch the users from Cloud.
Release Notes:
- N/A
Following our incident earlier, I noticed a report that mentioned their
extension was uninstalled upon update which made them stumble across the
issue for our outage.
The reason for this was that currently, whenever we install extension
updates, we _first_ removed the old directory and _then_ went ahead and
downloaded the new version. This would in turn obviousy lead to issus
where something malfunctioned during the update/install download -
whether that is an issue on our side with the servers or an issue on the
users side when they have a poor network connection or lose that.
This PR changes this - we now do the entirety of the download on a
background task, unpack the archive into a temporary directory if
possible and then proceed with removing the old extension contents and
moving the new contents only _after_ everything prior succeeded.
I also moved this off of the main thread since there is no reason to do
this there as well as the `Drop` impl of a `TempDir` doing some blocking
work on the main thread otherwise.
Release Notes:
- Made extension updates more resilient to network and upstream failures
Currently, there is no method provided to grab installed extensions on
Windows in Auto install extensions page.
```pwsh
Get-ChildItem "$env:LOCALAPPDATA\Zed\extensions\installed" -Name
```
will return extension list in a simple format that look like this:
<img width="646" height="135"
alt="{32ADE0F7-8EAF-4893-8E94-51DDFF6FF169}"
src="https://github.com/user-attachments/assets/5a020477-5fdf-42b0-8817-5b5372f21ff8"
/>
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
It seems new cancellation behavior in tree-sitter caused at least one
issue for a user.
Attempting to proactively reset before any parser use to make sure
things are clean.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
## Summary
- Restructures docs nav: new **Account & Billing**, **Zed Business**,
and **Privacy & Security** sections, positioned above Platform Support
- Moves Plans & Pricing and Billing out of AI > Subscription into
Account & Billing
- Moves Models and Providers to direct children of AI (removes
Subscription wrapper)
- Adds 4 new Zed Business pages: Overview, Organizations, Admin
Controls, Business Support
- Existing `roles.md` wired in as Roles & Permissions
- Privacy & Security, Privacy for Business, and SOC2 remain as draft
entries pending BIZOPS-983
- Adds redirect: `/ai/subscription.html` →
`/docs/ai/plans-and-usage.html`
## Status
Draft — active work in progress. Remaining issues on this branch:
- BIZOPS-982 (due 3/21): Account & Billing content updates
- BIZOPS-983 (due 3/23): Privacy & Security content
- BIZOPS-984 (due 3/25): Final review and QA
## Notes for reviewers
- Implementation-specific UI flows in the Business pages are stubbed
with `<!-- TODO -->` comments — these need to be filled in closer to
launch once the dashboard is finalized
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Katie Geer <katie@zed.dev>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
## Summary
Filenames containing md syntax (e.g. `__somefile__`, `*somefile*`) were
being rendered as markdown text in the file deletion confirmation
dialog.
Fixes#55651
## Changes
Wrapped file paths with `MarkdownEscaped` in the single and multi-file
deletion confirmation dialogs in `project_panel.rs`, so special md chars
like `_`, `*`, and `[` are escaped before being rendered.
## Testing
Created a file named `__somefile__` and tried to delete it, the name now
displays literally in the confirmation dialog instead of being rendered
as bold text:
<img width="339" height="206" alt="img"
src="https://github.com/user-attachments/assets/93e4e7d1-d5dc-45bb-9c08-2fe83c75aad2"
/>
Also added `test_delete_prompt_escapes_markdown_in_file_name` in
`project_panel_tests.rs` that verifies filenames with markdown special
characters render literally in the confirmation dialog.
Release Notes:
- Fixed file names containing markdown special characters (e.g.
`__somefile__`)
being rendered as formatted text in the file deletion confirmation
dialog.
I added navigation for file:line:col hover links e.g. `file.rs:83`,
similar to what the cli and terminal already do. I also added backticks
as file delimiters so that you can open file paths in markdown
documents, see:
https://github.com/user-attachments/assets/e31fca8e-6a22-4b5c-97c5-b8ddf8982e72
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
Btw the Zed docs don't mention this yet, but on native ARM64 Windows the
build fails with `error: instruction requires: fullfp16` from the
`gemm-f16` crate. I fixed this by adding `+fp16` to the target feature
flags:
```toml
[target.'cfg(target_os = "windows")']
rustflags = [
"--cfg", "windows_slim_errors",
"-C", "target-feature=+crt-static,+fp16",
]
```
CI cross-compiles from x86_64 so it doesn't hit this.
Closes https://github.com/zed-industries/zed/discussions/41123
Release Notes:
- Added file:line:col navigation from ctrl+click hover links in the
editor
Splits the edit tool into two separate tools `write_file` (previously
`mode = write`), and `edit_file` (previously `mode = edit`).
This makes the JSON schema for the `edit_tool` much simpler. We've seen
models (especially older ones) struggle with providing `mode = edit +
edits` and `mode = write + content` fields. This seems to improve eval
scores for Sonnet 4.6 slightly.
Also added two unit evals to ensure that the model uses the tool to
create new/override existing files
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Add support for Helix' buffer picker that is opened via `space b` by
default.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
Closes https://github.com/zed-industries/zed/issues/55867
Self-Review Checklist:
- [ x] I've reviewed my own diff for quality, security, and reliability
- [ x] Unsafe blocks (if any) have justifying comments
- [ n/a] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ n/a] Tests cover the new/changed behavior
- [ n/a] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
The hot-exit shortcut in `save_all_internal` silently serializes dirty
buffers instead of prompting. It assumes the workspace will still be
reachable, but that's not true for `ReplaceWindow`, or for `CloseWindow`
of an empty workspace on macOS — both detach the workspace and orphan
its serialized buffers in the DB with no UI path back to them.
Only allow the shortcut when the workspace is actually recoverable
(`Quit`, `save_last_workspace`, or has visible worktrees). Otherwise
prompt.
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#55726
Release Notes:
- Fixed unsaved untitled buffers being silently lost when opening a file
or project from an empty window
Closes#52292
This PR preserves the scroll offset of the List used in Recent Projects
while deleting items. It does that by:
- Adding the `is_scrolled_to_end` method to the GPUI list, which helps
us determine where the new selection should be, since it depends on
whether items are taking the deleted slot from below or above.
- Adding `ScrollBehavior` to `update_matches`, which lets you preserve
the scroll offset even for `List` (not `UniformList`) after a reset.
Before:
https://github.com/user-attachments/assets/e3eb7092-59ec-4b54-b57a-503555addd27
After:
https://github.com/user-attachments/assets/6929f6a0-04d7-44f9-a9b2-f9e5c077b368
Release Notes:
- Fixed the recent projects list jumping to the top after deleting a
project, so you can now bulk-delete entries by repeatedly clicking the
delete icon or pressing the keybind.
MCP servers that strictly validate the schema will reject notification
requests with params:null. Zed needs to either send an empty object or
omit the key altogether:
https://modelcontextprotocol.io/specification/2024-11-05/basic/messages#notifications
This one-line patch omits the key, consistent with the behavior in
Request messages.
I tested it with a dev build and confirmed that our internal MCP server
now accepts Zed's "notifications/initialized" request, and Zed is
subsequently able to discover the tools provided by this server.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Two bugs caused MCP server child processes (e.g. `npm`/`node` for
`mcp-remote`) to accumulate as zombie processes that were never cleaned
up:
**Bug 1: `stop_server()` only called `stop()` for `Running` servers**
If a server completed initialization but was still in `Starting` state
when `stop_server()` was called (a race between the init task completing
and `maintain_servers` restarting), the client/transport/process were
never released. The `Arc<ContextServer>` was moved into a `Stopped`
state with its inner client still holding the transport and child
process handle.
Fix: call `stop()` unconditionally in `stop_server()`. It is a safe
no-op when the client has not been initialized (`None`).
**Bug 2: `kill_on_drop` only killed the direct child, not the process
tree**
`StdioTransport` used a raw `smol::process::Child` with
`kill_on_drop(true)`, which sends SIGKILL only to the direct child
process (the shell/`npm` wrapper). The actual MCP server (e.g. `node
mcp-remote`) runs as a grandchild and survives the kill, getting
reparented to launchd.
Fix: use `util::process::Child`, which already exists in the codebase
for exactly this purpose. It calls `setsid()` via `pre_exec` to make the
child a process group leader, and uses `killpg()` to terminate the
entire process tree on kill. This requires passing a
`std::process::Command` (via `build_std_command`) instead of a
`smol::process::Command` (via `build_smol_command`), because that is
what `util::process::Child::spawn` accepts — it needs to call `pre_exec`
on the `std::process::Command` before internally converting it to
`smol::process::Command` for async I/O.
Release Notes:
- Fixed zombie MCP server processes accumulating over time
Fixes#54244
When the `read_file` tool is called with a path that points to a
directory instead of a file, it now returns a clear, actionable error
message telling the agent to use `list_directory` instead.
Previously the tool would fail with an unhelpful generic error. Now it
explicitly checks whether the path is a directory before attempting to
read it.
A test covering this case is also included.
Release Notes:
- Fixed `read_file` tool returning an unhelpful error when given a
directory path; it now suggests using `list_directory` instead.
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
"msg.string_contents();" return more than just content. It also return
tool result (which need special handling, and should be emitted from the
tool role) and thinking (which need already implemented special
handling).
This resulted in thinking being sent as content, which apparently
ollama’s gemma4 parser didn’t handled well, and caused a number of issue
that manifested by 1. outputting end of though token where unappropriate
and 2. repeating things endlessly
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 is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
(no UI/UX impact)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable (a quick
review, without benchmark, show that this should be at least as fast as
the previous code. This is called only exceptionally anyway.)
Closes#55537
Release Notes:
- Fixed "thinking" text being badly formatted when sent to Ollama
