This change contains a number of fixes to make kept_rate more intuitive.
It also adds a CLI utility to print debug info on how the metric is
computed.
Release Notes:
- N/A
This PR makes Zed only have one worktree picker, as opposed to a flavor
of it in the title bar and another in the agent panel. It then moves it
to the title bar, making it always present, so that its trigger is
separate from the branch picker (which now contains only two views:
branches and stashes). For the worktree picker, I'm mostly favoring the
behavior we've introduced in the agent-panel-flavored version.
It also updates the title bar settings migration to use the JSON
`migrate_settings` helper instead of a shallow Tree-sitter rewrite, so
old `show_branch_icon = true` values are promoted to
`show_branch_status_icon = true` across root, platform, release-channel,
and profile settings scopes.
- [x] Move worktree creation logic to the `git_ui` crate to make this
more generic and less agent-specific
- [x] Double-check the remote use case and ensure nothing broke there
- [x] Improve the UX for the detached HEAD state; better invite people
to create a branch
- [x] Migrate `show_branch_icon = true` to `show_branch_status_icon =
true` across nested settings scopes
Suggested .rules additions
When migrating renamed settings keys that can appear in platform
overrides, release-channel overrides, or profiles, prefer the JSON
`migrations::migrate_settings` helper over shallow Tree-sitter key
rewrites unless tests explicitly cover every nested scope that can
contain the key.
Release Notes:
- Improved migration of the title bar branch status icon setting.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
### 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
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
#### Closes#52702
### Video
[Screencast from 2026-03-30
13-17-08.webm](https://github.com/user-attachments/assets/8b0f6927-04d2-406b-b7fd-064a730b2f86)
Release Notes:
- Fixed the Inline Assist button showing in the Project Diagnostics
toolbar when the agent is disabled.
Bumps the `lsp-types` rev which contains patch for breaking change
introduced by upstream `typescript-go` repo
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed tsgo LSP
This PR revamps our feature flag system, to enable richer iteration.
Feature flags can now:
- Support enum values, for richer configuration
- Be manually set via the settings file
- Be manually set via the settings UI
This PR also adds a feature flag to demonstrate this behavior, a
`agent-thread-worktree-label`, which controls which how the worktree tag
UI displays.
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
Adds instrumentation to track input-to-frame latency in GPUI windows,
helping diagnose input responsiveness issues.
## What this does
- Records the time between when an input event is dispatched and when
the resulting frame is presented, capturing worst-case latency when
multiple events are coalesced into a single frame.
- Tracks how many input events get coalesced per rendered frame.
- Both metrics are stored in
[HdrHistogram](https://docs.rs/hdrhistogram) instances with 3
significant digits of precision.
- Latency is only recorded when the input event actually causes a redraw
(i.e. marks the window dirty), so idle mouse moves and other no-op
events don't skew the data.
- Adds a `Dump Input Latency Histogram` command that opens a buffer with
a formatted report including percentile breakdowns and visual
distribution bars.
## Example output
The report shows percentile latencies, a bucketed distribution with bar
charts, and a per-frame event coalescing breakdown.
Release Notes:
- N/A
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Cole Miller <cole@zed.dev>
When the Agent panel (or any dock panel without its own pane) is focused
and a file is open in the center editor, pressing `/` in vim mode would
steal focus to the buffer's search bar instead of staying on the panel.
## Root cause
`Vim::pane()` calls `workspace.focused_pane()`, which falls back to the
center pane when a dock panel without its own `pane()` method is
focused. Vim search commands then open the `BufferSearchBar` on the
center pane and focus it, stealing focus from the panel.
## Fix
Add a guard in `Vim::pane()` that returns `None` when the resolved pane
doesn't actually contain focus. This prevents all vim search/match
commands (`/`, `?`, `n`, `N`, `*`, `#`, etc.) from stealing focus from
non-pane panels.
All 497 vim tests and 253 agent_ui tests pass.
Release Notes:
- Fixed vim search (`/`) stealing focus from the Agent panel when a file
is open in the editor.
Sometimes the action log would not auto-accept agent edits when
commiting.
Gpt-5.4 identified this race condition:
This fixes a race where `keep_committed_edits` could run after
`head_commit` changed but before the new git base text had been applied,
leaving committed agent edits marked as unreviewed; `ActionLog` now
waits for an explicit `BufferDiffEvent::BaseTextChanged` instead of
inferring readiness from generic `DiffChanged` activity, so it only
accepts edits after the diff base itself is actually updated.
- `ReloadGitState` updates `head_commit` before `ReloadBufferDiffBases`
finishes loading and applying the new HEAD text.
- In that gap, an unrelated `DiffChanged` can fire from a normal diff
recalculation.
- The old logic treated that event as the commit signal and ran
`keep_committed_edits` too early.
- `keep_committed_edits` then read stale diff base text, so it failed to
match the committed agent edits.
- When the real base-text update arrived later, the HEAD had already
been overwritten (`old_head`), and the edits stayed unreviewed.
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:
- Fixed an issue where committing agent written code would sometimes not
mark edits as accepted
Follow up to #53999
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
Closes#53426
Fixes a crash when previewing markdown with GIFs, and enables GIF
animation in the preview panel.
Two issues: a partially-decoded GIF could crash the preview, and GIFs in
markdown previews never animated.
The fix for GIFs with empty comment extensions (`21 fe 00`) was
implemented upstream in the `image-gif` crate (image-rs/image-gif#228)
and released as `gif 0.14.2`. This PR bumps the dependency so those GIFs
now render correctly in the markdown preview without any further changes
to Zed itself.
## Screenshot
Left=VS Code
Right=Zed
https://github.com/user-attachments/assets/7950abbc-1a79-4f01-a425-9595aa688325
Release Notes:
- Fixed a crash in certain scenarios when opening Markdown Preview with
GIFs.
- Added GIF animation support for Markdown Preview.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
- Adds a status toast to the announcement banner for surfacing the
layout revert option
- Removes the agent panel banner
A good chunk of the diff here was because I touched up the status toast
component API a little bit.
Release Notes:
- N/A
Track new telemetry:
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:
- N/A
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
The `cli_default_open_behavior` setting controls how `zed <path>` opens
directories, but the underlying behavior is gated behind the
`AgentV2FeatureFlag` in `open_listener.rs`. Without the flag enabled,
the setting has no effect — Zed always falls back to `NewWindow`
behavior.
This change gates the settings UI entry behind the same feature flag so
it only appears when the feature is actually active.
**Changes:**
- Converted `general_settings_section()` from a fixed-size array to a
`Vec` so the CLI setting can be conditionally appended
- Added `feature_flags` as a dependency to `settings_ui`
Release Notes:
- N/A
Adds initial beta test of ACP usage stats. Behind a flag for now while
we work on standardizing the usage values.
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
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [rand](https://rust-random.github.io/book)
([source](https://redirect.github.com/rust-random/rand)) |
workspace.dependencies | patch | `0.9.2` → `0.9.3` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the [Dependency
Dashboard](../issues/15138) for more information.
### GitHub Vulnerability Alerts
####
[GHSA-cq8v-f236-94qc](https://redirect.github.com/rust-random/rand/pull/1763)
It has been reported (by @​lopopolo) that the `rand` library is
[unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library)
(i.e. that safe code using the public API can cause Undefined Behaviour)
when all the following conditions are met:
- The `log` and `thread_rng` features are enabled
- A [custom
logger](https://docs.rs/log/latest/log/#implementing-a-logger) is
defined
- The custom logger accesses `rand::rng()` (previously
`rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`)
methods on `ThreadRng`
- The `ThreadRng` (attempts to) reseed while called from the custom
logger (this happens every 64 kB of generated data)
- Trace-level logging is enabled or warn-level logging is enabled and
the random source (the `getrandom` crate) is unable to provide a new
seed
`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe`
code to cast `*mut BlockRng<ReseedingCore>` to `&mut
BlockRng<ReseedingCore>`. When all the above conditions are met this
results in an aliased mutable reference, violating the Stacked Borrows
rules. Miri is able to detect this violation in sample code. Since
construction of [aliased mutable references is Undefined
Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html),
the behaviour of optimized builds is hard to predict.
Affected versions of `rand` are `>= 0.7, < 0.9.3` and `0.10.0`.
---
### Release Notes
<details>
<summary>rust-random/rand (rand)</summary>
###
[`v0.9.3`](https://redirect.github.com/rust-random/rand/compare/0.9.2...0.9.3)
[Compare
Source](https://redirect.github.com/rust-random/rand/compare/0.9.2...0.9.3)
</details>
---
### Configuration
📅 **Schedule**: (in timezone America/New_York)
- Branch creation
- ""
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
Release Notes:
- N/A
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMTAuMiIsInVwZGF0ZWRJblZlciI6IjQzLjExMC4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Based on a partial revert of: 42351ee103
The main difference is instead of a feature flag we now check
`ReleaseChannel::Stable` != current_release_channel when the UI checks
if agent v2 (sidebar) features should be enabled.
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
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This fixes an issue reported by @Veykril where the "Try Now" button
would open a different panel than the agent panel. The bug was caused by
us attempting to focus the agent panel before layout settings updates
had been applied.
This should also make all programmatic settings updates more responsive,
because they won't have to wait for FS watchers to take effect.
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
When archiving a thread's last reference to a linked worktree, the
worktree workspace must be removed from the MultiWorkspace before the
background cleanup task runs `git worktree remove`. Previously, only the
workspace found via exact PathList match on the thread's `folder_paths`
was removed. This missed cases where the workspace's root paths diverged
from the thread's `folder_paths` (e.g. after folders were added/removed
from the workspace).
Now we also scan `roots_to_archive` for any linked worktree workspaces
that contain the worktree being archived and include them in the removal
set. This ensures all editors are dropped, releasing their
`Entity<Worktree>` references (held through `File` structs in buffers),
so `wait_for_worktree_release` completes and `git worktree remove` can
proceed.
Release Notes:
- Fixed some linked worktree directories not always being cleaned up
from disk when archiving a thread.
> **Foundation PRs:** #53732, #53733, #53734 — These three draft PRs
contain the base refactors (retained workspaces, agent panel overlay
split, ThreadId introduction) that this PR builds on.
## Goal
Remove `DraftId` and merge `draft_threads` + `background_threads` into a
single `retained_threads: HashMap<ThreadId, Entity<ConversationView>>`
in `AgentPanel`. A draft is just a thread that hasn't sent its first
message — no separate identity or storage needed.
## Changes
### agent_panel.rs
- Remove `DraftId` / `DraftIdCounter` / the `Global` impl
- Merge the two maps into `retained_threads`
- Add `thread_id: ThreadId` field to `BaseView::AgentThread`
- Rename methods: `create_draft` → `create_thread`, `activate_draft` →
`activate_retained_thread`, `remove_draft` → `remove_thread`, etc.
- Replace `clear_active_thread` with `show_or_create_empty_draft`
- Update `update_thread_work_dirs` to sync `ThreadMetadataStore` paths
when worktrees change
- Keep `load_agent_thread(...)` cleanup so activating a real thread
removes empty retained drafts
### sidebar.rs
- Remove `active_entry` derivation from `rebuild_contents` (was racing
with deferred effects)
- Add `sync_active_entry_from_panel` called from event handlers instead
- Simplify `ActiveEntry` — remove `ThreadActivation` struct, make
`session_id` optional
- Move `seen_thread_ids` to global scope (was per-group, causing
duplicate thread entries)
- Remove dead code: `clear_draft`, `render_draft_thread`
- Generalize `pending_remote_thread_activation` into
`pending_thread_activation` so all persisted-thread activations suppress
fallback draft reconciliation
- Set the activation guard before local persisted-thread activation
switches workspaces
- Make `reconcile_groups(...)` bail while a persisted-thread activation
is in flight
- On `ActiveViewChanged`, clear empty group drafts as soon as a pending
persisted-thread activation resolves
### thread_metadata_store.rs
- Make `ThreadMetadata.title` an `Option<SharedString>` with
`display_title()` fallback
- Add `update_worktree_paths` for batched path updates when project
worktrees change
### Other crates
- Update all `ThreadMetadata` construction sites and title display sites
across `agent_ui` and `sidebar`
## Fallback draft invariant
This PR now tightens the retained-thread invariant around fallback
drafts vs real thread activation/restoration:
- Fallback drafts are always empty
- User-created drafts worth preserving are non-empty
- While a persisted thread is being activated/restored/loaded, sidebar
reconciliation must not create an empty fallback draft for that target
group/workspace
- Once the real thread becomes active, empty fallback drafts in that
target group are removed
This is enforced by the sidebar-side activation guard plus existing
`AgentPanel` empty-draft cleanup after real-thread load.
## Tests
Added and/or kept focused sidebar regression coverage for:
-
`test_confirm_on_historical_thread_in_new_project_group_opens_real_thread`
-
`test_unarchive_into_inactive_existing_workspace_does_not_leave_active_draft`
-
`test_unarchive_after_removing_parent_project_group_restores_real_thread`
- `test_pending_thread_activation_suppresses_reconcile_draft_creation`
Focused test runs:
- `cargo test -p sidebar activate_archived_thread -- --nocapture`
- `cargo test -p sidebar unarchive -- --nocapture`
- `cargo test -p sidebar archive_last_thread_on_linked_worktree --
--nocapture`
- `cargo test -p sidebar
test_confirm_on_historical_thread_in_new_project_group_opens_real_thread
-- --nocapture`
- `cargo test -p sidebar
test_unarchive_into_inactive_existing_workspace_does_not_leave_active_draft
-- --nocapture`
- `cargo test -p sidebar
test_unarchive_after_removing_parent_project_group_restores_real_thread
-- --nocapture`
- `cargo test -p sidebar
test_pending_thread_activation_suppresses_reconcile_draft_creation --
--nocapture`
## Test fix
Fixed flaky `test_backfill_sets_kvp_flag` — added per-App `AppDatabase`
isolation in `setup_backfill_test` so backfill tests no longer share a
static in-memory DB.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This PR adds the `cli_default_open_behavior` setting and a first-run TUI
prompt
that appears when `zed <path>` is invoked without flags while existing
windows are
open and the setting hasn't been configured yet.
## What it does
### Setting and prompt
- Adds a new `cli_default_open_behavior` workspace setting with two
values:
`existing_window` (default) and `new_window`.
- When the user runs `zed <path>` for the first time with existing Zed
windows
open, a `dialoguer::Select` prompt in the CLI asks them to choose their
preferred behavior. The choice is persisted to `settings.json`.
- The prompt is skipped when:
- An explicit flag (`-n`, `-e`, `-a`) is given
- No existing Zed windows are open
- The setting is already configured in `settings.json`
- The paths being opened are already contained in an existing workspace
### IPC transport abstraction
- Introduces a `CliResponseSink` trait in the `cli` crate that abstracts
`IpcSender<CliResponse>`, with an implementation for the real IPC
sender.
- Replaces `IpcSender<CliResponse>` with `Box<dyn CliResponseSink>` /
`&dyn CliResponseSink` across all signatures in `open_listener.rs`:
`OpenRequestKind::CliConnection`, `handle_cli_connection`,
`maybe_prompt_open_behavior`, `open_workspaces`, `open_local_workspace`.
- Extracts the inline CLI response loop from `main.rs` into a testable
`cli::run_cli_response_loop` function.
- Switches the request channel from bounded `mpsc::channel(16)` to
`mpsc::unbounded()`, eliminating `smol::block_on` in the bridge thread.
### End-to-end tests
Seven new tests exercise both the CLI-side response loop and the
Zed-side
handler connected through in-memory channels, using `allow_parking()` so
the
real `cli::run_cli_response_loop` runs on an OS thread while the GPUI
executor
drives the Zed handler:
- No flags, no windows → no prompt, opens new window
- No flags, existing windows, user picks "existing window" → prompt,
setting persisted
- No flags, existing windows, user picks "new window" → prompt, setting
persisted
- Setting already configured → no prompt
- Paths already in existing workspace → no prompt
- Explicit `-e` flag → no prompt
- Explicit `-n` flag → no prompt
Existing tests that previously used `ipc::channel()` now use a
`DiscardResponseSink`, removing OS-level IPC from all tests.
Release Notes:
- Added a first-run prompt when using `zed <path>` to choose between
opening
in an existing window or a new window. The choice is saved to settings
and
can be changed later via the `cli_default_open_behavior` setting.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [wasmtime](https://redirect.github.com/bytecodealliance/wasmtime) |
workspace.dependencies | patch | `36.0.6` → `36.0.7` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the [Dependency
Dashboard](../issues/15138) for more information.
### GitHub Vulnerability Alerts
####
[CVE-2026-34941](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hx6p-xpx3-jvvv)
### Summary
Wasmtime contains a vulnerability where when transcoding a UTF-16 string
to the latin1+utf16 component-model encoding it would incorrectly
validate the byte length of the input string when performing a bounds
check. Specifically the number of code units were checked instead of the
byte length, which is twice the size of the code units.
This vulnerability can cause the host to read beyond the end of a
WebAssembly's linear memory in an attempt to transcode nonexistent
bytes. In Wasmtime's default configuration this will read unmapped
memory on a guard page, terminating the process with a segfault.
Wasmtime can be configured, however, without guard pages which would
mean that host memory beyond the end of linear memory may be read and
interpreted as UTF-16.
A host segfault is a denial-of-service vulnerability in Wasmtime, and
possibly being able to read beyond the end of linear memory is
additionally a vulnerability. Note that reading beyond the end of linear
memory requires nonstandard configuration of Wasmtime, specifically with
guard pages disabled.
### Impact
This is an out-of-bounds memory access. Any user running untrusted wasm
components that use cross-component string passing (with UTF-16 source
and latin1+utf16 destination encodings) is affected.
- With guard pages: Denial of service. The host process crashes with
SIGBUS/SIGSEGV.
- Without guard pages: Potential information disclosure. The guest can
read host memory beyond its linear memory allocation.
Patches
Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this
bug. Users are recommended to update to these patched versions of
Wasmtime.
Workarounds
There is no workaround for this bug. Hosts are recommended to updated to
a patched version of Wasmtime.
####
[CVE-2026-34942](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jxhv-7h78-9775)
### Impact
Wasmtime's implementation of transcoding strings into the Component
Model's `utf16` or `latin1+utf16` encodings improperly verified the
alignment of reallocated strings. This meant that unaligned pointers
could be passed to the host for transcoding which would trigger a host
panic. This panic is possible to trigger from malicious guests which
transfer very specific strings across components with specific
addresses.
Host panics are considered a DoS vector in Wasmtime as the panic
conditions are controlled by the guest in this situation.
### Patches
Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this
bug. Users are recommended to update to these patched versions of
Wasmtime.
### Workarounds
There is no workaround for this bug. Hosts are recommended to updated to
a patched version of Wasmtime.
####
[CVE-2026-34943](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-m758-wjhj-p3jq)
### Impact
Wasmtime contains a possible panic which can happen when a `flags`-typed
component model value is lifted with the `Val` type. If bits are set
outside of the set of flags the component model specifies that these
bits should be ignored but Wasmtime will panic when this value is
lifted. This panic only affects wasmtime's implementation of lifting
into `Val`, not when using the `flags!` macro. This additionally only
affects `flags`-typed values which are part of a WIT interface.
This has the risk of being a guest-controlled panic within the host
which Wasmtime considers a DoS vector.
### Patches
Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this
bug. Users are recommended to update to these patched versions of
Wasmtime.
### Workarounds
There is no workaround for this bug if a host meets the criteria to be
affected. To be affected a host must be using `wasmtime::component::Val`
and possibly work with a `flags` type in the component model.
####
[CVE-2026-34944](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-qqfj-4vcm-26hv)
On x86-64 platforms with SSE3 disabled Wasmtime's compilation of the
`f64x2.splat` WebAssembly instruction with Cranelift may load 8 more
bytes than is necessary. When
[signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps)
are disabled this can result in a uncaught segfault due to loading from
unmapped guard pages. With guard pages disabled it's possible for
out-of-sandbox data to be loaded, but this data is not visible to
WebAssembly guests.
### Details
The `f64x2.splat` operator, when operating on a value loaded from a
memory (for example with f64.load), compiles with Cranelift to code on
x86-64 without SSE3 that loads 128 bits (16 bytes) rather than the
expected 64 bits (8 bytes) from memory. When the address is in-bounds
for a (correct) 8-byte load but not an (incorrect) 16-byte load, this
can load beyond memory by up to 8 bytes. This can result in three
different behaviors depending on Wasmtime's configuration:
1. If guard pages are disabled then this extra data will be loaded. The
extra data is present in the upper bits of a register, but the upper
bits are not visible to WebAssembly guests. Actually witnessing this
data would require a different bug in Cranelift, of which none are
known. Thus in this situation while it's something we're patching in
Cranelift it's not a security issue.
2. If guard pages are enabled, and
[signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps)
are enabled, then this operation will result in a safe WebAssembly trap.
The trap is incorrect because the load is not out-of-bounds as defined
by WebAssembly, but this mistakenly widened load will load bytes from an
unmapped guard page, causing a segfault which is caught and handled as a
Wasm trap. In this situation this is not a security issue, but we're
patching Cranelift to fix the WebAssembly behavior.
3. If guard pages are enabled, and
[signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps)
are disabled, then this operation results in an uncaught segfault. Like
the previous case with guard pages enabled this will load from an
unmapped guard page. Unlike before, however, signals-based-traps are
disabled meaning that signal handlers aren't configured. The resulting
segfault will, by default, terminate the process. This is a security
issue from a DoS perspective, but does not represent an arbitrary read
or write from WebAssembly, for example.
Wasmtime's default configuration is case (2) in this case. That means
that Wasmtime, by default, incorrectly executes this
WebAssembly instruction but does not have insecure behavior.
### Impact
If
[signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps)
are disabled and guard pages are enabled then guests can trigger an
uncaught segfault in the host, likely aborting the host process. This
represents, for example, a DoS vector for WebAssembly guests.
This bug does not affect Wasmtime's default configuration and requires
[signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps)
to be disabled. This bug only affects the x86-64 target with the SSE3
feature disabled and the Cranelift backend (Wasmtime's default backend).
### Patches
Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this
bug. Users are recommended to update to these patched versions of
Wasmtime.
### Workarounds
This bug only affects x86-64 hosts where SSE3 is disabled. If SSE3 is
enabled or if a non-x86-64 host is used then hosts are not affect.
Otherwise there are no known workarounds to this issue.
####
[CVE-2026-34945](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-m9w2-8782-2946)
### Impact
Wasmtime's Winch compiler contains a bug where a 64-bit table, part of
the memory64 proposal of WebAssembly, incorrectly translated the
`table.size` instruction. This bug could lead to disclosing data on the
host's stack to WebAssembly guests. The host's stack can possibly
contain sensitive data related to other host-originating operations
which is not intended to be disclosed to guests.
This bug specifically arose from a mistake where the return value of
`table.size` was statically typed as a 32-bit integer, as opposed to
consulting the table's index type to see how large the returned register
could be. When combined with details about Wnich's ABI, such as
multi-value returns, this can be combined to read stack data from the
host, within a guest. This information disclosure should not be possible
in WebAssembly, violates spec semantics, and is a vulnerability in
Wasmtime.
### Patches
Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug.
Users are recommended to update to these patched versions of Wasmtime.
### Workarounds
Users of Cranelift are not affected by this issue, but users of Winch
have no workarounds other than disabling the `Config::wasm_memory64`
proposal.
####
[CVE-2026-34946](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q49f-xg75-m9xw)
### Impact
Wasmtime's Winch compiler contains a vulnerability where the compilation
of the `table.fill` instruction can result in a host panic. This means
that a valid guest can be compiled with Winch, on any architecture, and
cause the host to panic. This represents a denial-of-service
vulnerability in Wasmtime due to guests being able to trigger a panic.
The specific issue is that a historical refactoring, #​11254,
changed how compiled code referenced tables within the `table.*`
instructions. This refactoring forgot to update the Winch code paths
associated as well, meaning that Winch was using the wrong indexing
scheme. Due to the feature support of Winch the only problem that can
result is tables being mixed up or nonexistent tables being used,
meaning that the guest is limited to panicking the host (using a
nonexistent table), or executing spec-incorrect behavior and modifying
the wrong table.
### Patches
Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug.
Users are recommended to update to these patched versions of Wasmtime.
### Workarounds
Users of Cranelift are not affected by this issue, but for users of
Winch there is no workaround for this bug. Hosts are recommended to
updated to a patched version of Wasmtime.
####
[CVE-2026-34971](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jhxm-h53p-jm7w)
### Impact
Wasmtime's Cranelift compilation backend contains a bug on aarch64 when
performing a certain shape of heap accesses which means that the wrong
address is accessed. When combined with explicit bounds checks a guest
WebAssembly module this can create a situation where there are two
diverging computations for the same address: one for the address to
bounds-check and one for the address to load. This difference in address
being operated on means that a guest module can pass a bounds check but
then load a different address. Combined together this enables an
arbitrary read/write primitive for guest WebAssembly when accesssing
host memory. This is a sandbox escape as guests are able to read/write
arbitrary host memory.
This vulnerability has a few ingredients, all of which must be met, for
this situation to occur and bypass the sandbox restrictions:
* This miscompiled shape of load only occurs on 64-bit WebAssembly
linear memories, or when `Config::wasm_memory64` is enabled. 32-bit
WebAssembly is not affected.
* Spectre mitigations or signals-based-traps must be disabled. When
spectre mitigations are enabled then the offending shape of load is not
generated. When signals-based-traps are disabled then spectre
mitigations are also automatically disabled.
The specific bug in Cranelift is a miscompile of a load of the shape
`load(iadd(base, ishl(index, amt)))` where `amt` is a constant. The
`amt` value is masked incorrectly to test if it's a certain value, and
this incorrect mask means that Cranelift can pattern-match this lowering
rule during instruction selection erroneously, diverging from
WebAssembly's and Cranelift's semantics. This incorrect lowering would,
for example, load an address much further away than intended as the
correct address's computation would have wrapped around to a smaller
value insetad.
### Patches
Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug.
Users are recommended to update to these patched versions of Wasmtime.
### Workarounds
This bug only affects users of Cranelift on aarch64. Cranelift on other
platforms is not affected. Additionally this only affects 64-bit
WebAssembly linear memories, so if `Config::wasm_memory64` is disabled
then hosts are not affected. Note that `Config::wasm_memory64` is
enabled by default. If spectre mitigations are enabled, which are
enabled by default, then hosts are not affected by this issue.
####
[CVE-2026-34988](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-6wgr-89rj-399p)
### Impact
Wasmtime's implementation of its pooling allocator contains a bug where
in certain configurations the contents of linear memory can be leaked
from one instance to the next. The implementation of resetting the
virtual memory permissions for linear memory used the wrong predicate to
determine if resetting was necessary, where the compilation process used
a different predicate. This divergence meant that the pooling allocator
incorrectly deduced at runtime that resetting virtual memory permissions
was not necessary while compile-time determine that virtual memory could
be relied upon.
Exposing this bug requires specific configuration values to be used. If
any of these configurations are not applicable then this bug does not
happen:
* The pooling allocator must be in use.
* The `Config::memory_guard_size` configuration option must be 0.
* The `Config::memory_reservation` configuration must be less than 4GiB.
* The pooling allocator must be configured with `max_memory_size` the
same as the `memory_reservation` value.
If all of these conditions are applicable then when a linear memory is
reused the VM permissions of the previous iteration are not reset. This
means that the compiled code, which is assuming out-of-bounds loads will
segfault, will not actually segfault and can read the previous contents
of linear memory if it was previously mapped.
This represents a data leakage vulnerability between guest WebAssembly
instances which breaks WebAssembly's semantics and additionally breaks
the sandbox that Wasmtime provides. Wasmtime is not vulnerable to this
issue with its default settings, nor with the default settings of the
pooling allocator, but embeddings are still allowed to configure these
values to cause this vulnerability.
### Patches
Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug.
Users are recommended to update to these patched versions of Wasmtime.
### Workarounds
All four conditions above must be met to be vulnerable to this bug, and
users can work around this bug by adjusting any of the above conditions.
For example it is strongly recommended that guard pages are configured
for linear memories which would make this bug not applicable.
####
[CVE-2026-35195](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-394w-hwhg-8vgm)
### Impact
Wasmtime's implementation of transcoding strings between components
contains a bug where the return value of a guest component's `realloc`
is not validated before the host attempts to write through the pointer.
This enables a guest to cause the host to write arbitrary transcoded
string bytes to an arbitrary location up to 4GiB away from the base of
linear memory. These writes on the host could hit unmapped memory or
could corrupt host data structures depending on Wasmtime's
configuration.
Wasmtime by default reserves 4GiB of virtual memory for a guest's linear
memory meaning that this bug will by default on hosts cause the host to
hit unmapped memory and abort the process due to an unhandled fault.
Wasmtime can be configured, however, to reserve less memory for a guest
and to remove all guard pages, so some configurations of Wasmtime may
lead to corruption of data outside of a guest's linear memory, such as
host data structures or other guests's linear memories.
### Patches
Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this
bug. Users are recommended to update to these patched versions of
Wasmtime.
### Workarounds
There is no known workaround for this issue and affected
hosts/embeddings are recommended to upgrade.
---
### Release Notes
<details>
<summary>bytecodealliance/wasmtime (wasmtime)</summary>
###
[`v36.0.7`](https://redirect.github.com/bytecodealliance/wasmtime/releases/tag/v36.0.7)
[Compare
Source](https://redirect.github.com/bytecodealliance/wasmtime/compare/v36.0.6...v36.0.7)
#### 36.0.7
Released 2026-04-09.
##### Fixed
- Miscompiled guest heap access enables sandbox escape on aarch64
Cranelift.
[GHSA-jhxm-h53p-jm7w](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jhxm-h53p-jm7w)
- Wasmtime with Winch compiler backend may allow a sandbox-escaping
memory
access.
[GHSA-xx5w-cvp6-jv83](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xx5w-cvp6-jv83)
- Out-of-bounds write or crash when transcoding component model strings.
[GHSA-394w-hwhg-8vgm](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-394w-hwhg-8vgm)
- Host panic when Winch compiler executes `table.fill`.
[GHSA-q49f-xg75-m9xw](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q49f-xg75-m9xw)
- Wasmtime segfault or unused out-of-sandbox load with `f64x2.splat`
operator
on x86-64.
[GHSA-qqfj-4vcm-26hv](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-qqfj-4vcm-26hv)
- Improperly masked return value from `table.grow` with Winch compiler
backend.
[GHSA-f984-pcp8-v2p7](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-f984-pcp8-v2p7)
- Panic when transcoding misaligned utf-16 strings.
[GHSA-jxhv-7h78-9775](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jxhv-7h78-9775)
- Panic when lifting `flags` component value.
[GHSA-m758-wjhj-p3jq](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-m758-wjhj-p3jq)
- Heap OOB read in component model UTF-16 to latin1+utf16 string
transcoding.
[GHSA-hx6p-xpx3-jvvv](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hx6p-xpx3-jvvv)
- Data leakage between pooling allocator instances.
[GHSA-6wgr-89rj-399p](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-6wgr-89rj-399p)
- Host data leakage with 64-bit tables and Winch.
[GHSA-m9w2-8782-2946](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-m9w2-8782-2946)
</details>
---
### Configuration
📅 **Schedule**: (in timezone America/New_York)
- Branch creation
- ""
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
Release Notes:
- N/A
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMTAuMiIsInVwZGF0ZWRJblZlciI6IjQzLjExMC4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.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#52928
Release Notes:
- Fixed handling of multi-stage and stage-specified dockerfiles in dev
container manifests
- Fixed the way we find the base image in a dev container when build
args need expansion
- Introduce `project_panel::Redo` action
- Update all platform keymaps in order to map
`redo`/`ctrl-shift-z`/`cmd-shift-z` to the `project_panel::Redo` action
### Restore Entry Support
- Update both `Project::delete_entry` and `Worktree::delete_entry` to
return the resulting `fs::TrashedEntry`
- Introduce both `Project::restore_entry` and `Worktree::restore_entry`
to allow restoring an entry in a worktree, given the `fs::TrashedEntry`
- Worth pointing out that support for restoring is not yet implemented
for remote worktrees, as that will be dealt with in a separate pull
request
### Undo Manager
- Split `ProjectPanelOperation` into two different enums, `Change` and
`Operation`
- While thinking through this, we noticed that simply recording the
operation that user was performing was not enough, specifically in the
case where undoing would restore the file, as in that specific case, we
needed the `trash::TrashedEntry` in order to be able to restore, so we
actually needed the result of executing the operation.
- Having that in mind, we decided to separate the operation (intent)
from the change (result), and record the change instead. With the change
being recorded, we can easily building the operation that needs to be
executed in order to invert that change.
- For example, if an user creates a new file, we record the
`ProjectPath` where the file was created, so that undoing can be a
matter of trashing that file. When undoing, we keep track of the
`trash::TrashedEntry` resulting from trashing the originally created
file, such that, redoing is a matter of restoring the
`trash::TrashedEntry`.
- Refer to the documentation in the `project_panel::undo` module for a
better breakdown on how this is implemented/handled.
- Introduce a task queue for dealing with recording changes, as well as
undo and redo requests in a sequential manner
- This meant moving some of the details in `UndoManager` to a
`project_panel::undo::Inner` implementation, and `UndoManager` now
serves as a simple wrapper/client around the inner implementation,
simply communicating with it to record changes and handle undo/redo
requests
- Callers that depend on the `UndoManager` now simply record which
changes they wish to track, which are then sent to the undo manager's
inner implementation
- Same for the undo and redo requests, those are simply sent to the undo
manager's inner implementation, which then deals with picking the
correct change from the history and executing its inverse operation
- Introduce support for tracking restore changes and operations
- `project_panel::undo::Change::Restored` – Keeps track that the
file/directory associated with the `ProjectPath` was a result of
restoring a trashed entry, for which we now that reverting is simply a
matter of trashing the path again
- `project_panel::undo::Operation::Restore` – Keeps track of both the
worktree id and the `TrashedEntry`, from which we can build the original
`ProjectPath` where the trashed entry needs to be restored
- Move project panel's undo tests to a separate module
`project_panel::tests::undo` to avoid growing the
`project::project_panel_tests` module into a monolithic test module
- Some of the functions in `project::project_panel_tests` were made
`pub(crate)` in order for us to be able to call those from
`project_panel::tests::undo`
### FS Changes
- Refactored the `Fs::trash_file` and `Fs::trash_dir` methods into a
single `Fs::trash` method
- This can now be done because `RealFs::trash_dir` and
`RealFs::trash_file` were simply calling `trash::delete_with_info`, so
we can simplify the trait
- Tests have also been simplified to reflect this new change, so we no
longer need a separate test for trashing a file and trashing a directory
- Update `Fs::trash` and `Fs::restore` to be async
- On the `RealFs` implementation we're now spawning a thread to perform
the trash/restore operation
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
Relates to #5039
Release Notes:
- N/A
---------
Co-authored-by: Yara <git@yara.blue>
Co-authored-by: Miguel Raz Guzmán Macedo <miguel@zed.dev>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Update both `Fs::trash_dir` and `Fs::trash_file` to now return the
location of the trashed directory or file, as well as adding the
`trash-rs` create dependency and updating the `RealFs` implementation
for these methods to simply leverage `trash::delete_with_info`.
* Add `fs::Fs::TrashedEntry` struct, which allows us to track the
original file path and the new path in the OS' trash
* Update the `fs::Fs::trash_dir` and `fs::Fs::trash_file` signatures to
now return `Result<TrashedEntry>` instead of `Result<()>`
* The `options` argument was removed because it was never used by
implementations other than the default one, and with this change to
the signature type, we no longer have a default implementation, so the
`options` argument would no longer make sense
* Update `fs::RealFs::trash_dir` and `fs::RealFs::trash_file`
implementations to simply delegate to `trash-rs` and convert the
result to a `TrashedEntry`
* Add `fs::FakeFs::trash` so we can simulate the OS' trash during tests
that touch the filesystem
* Add `fs::FakeFs::trash_file` implementation to leverage
`fs::FakeFs::trash`
* Add `fs::FakeFs::trash_dir` implementation to leverage
`fs::FakeFs::trash`
Remove the standalone storybook binary and the story crate, as component
previews are now handled by the component_preview crate.
Also removes the stories features from the ui and title_bar crates.
Release Notes:
- N/A or Added/Fixed/Improved ...
When git commands (push, pull, hooks...) produce output containing ANSI
escape sequences for colors or formatting, Zed was displaying them as
raw escape codes in the output buffer, making the output hard to read.
This simply escapes ANSI from the git output
### Before and After
<table>
<tr>
<th align="center">Before</th>
<th align="center">After</th>
</tr>
<tr>
<td>
<img width="882" height="862" alt="Screenshot 2026-04-08 at 21 13 07"
src="https://github.com/user-attachments/assets/58731e80-d864-47ca-8983-d0e86e924843"
/>
</td>
<td>
<img width="882" height="862" alt="Screenshot 2026-04-08 at 21 15 14"
src="https://github.com/user-attachments/assets/7649200a-2d82-4442-88da-e231304911a8"
/>
</td>
</tr>
</table>
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
Related to #43817. This PR only addresses the escaping of the ANSI
codes; colors and other stuff are not handled
Release Notes:
- Fixed ANSI escape codes being displayed as raw text in git command
output
This PR greatly improves our handling of remote threads in the sidebar.
One primary issue was that many parts of the sidebar were only looking
at a thread's path list and not its remote connection information. The
fix here is to use `ProjectGroupKey` more consistently throughout the
sidebar which also includes remote connection information.
The second major change is to extend the MultiWorkspace with the ability
to initiate the creation of remote workspaces when needed. This involved
refactoring a lot of our remote workspace creation paths to share a
single code path for better consistency.
Release Notes:
- (Preview only) Fixed remote project threads appearing as a separate
local project in the sidebar
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Stacked on https://github.com/zed-industries/zed/pull/50566.
Begin collecting kept chars rate, as well as the count of tree-sitter
errors in the code before and after applying the prediction.
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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
Connect the git API and archived worktree data model to the sidebar's
archive/unarchive flow:
- Add `thread_worktree_archive` module: orchestrates the full archive
cycle (WIP commits, DB records, git refs, worktree deletion) and restore
cycle (detached worktree creation, reset to recover staged/unstaged
state, branch restoration)
- Integrate into sidebar: `archive_thread` now persists worktree state
before cleanup; `activate_archived_thread` restores worktrees via git
with targeted path replacement for multi-root threads
- Add pending worktree restore UI state with spinner and cancel button
- Show toast on restore failure instead of silent log
- Switch to surviving workspace when archiving active thread whose
workspace will be deleted
- Deserialize persisted `project_group_keys` on window restore
- Guard `cleanup_empty_workspaces` against dropped entities
- Await rollback DB operations instead of fire-and-forget
Part 3 of 3 in the persist-worktree stack. Stacked on #53214. This wires
up parts 1 and 2.
Release Notes:
- Added worktree state preservation when archiving agent threads,
automatically restoring staged and unstaged changes when the thread is
unarchived
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
We were incorrectly wrapping new terminal auth methods in double ssh
calls.
Only affected ACP beta users, but important for testing and stabilizing
the feature.
We moved the ssh wrapping to be only added in the acp process creation
where it was needed.
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>
It's happening.
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 filtering themes with a query that matches nothing (e.g., "zzz"),
`show_selected_theme` returned `None` and overwrote `selected_theme`.
Clearing the filter then lost track of the previous selection and
defaulted to index 0.
The fix only updates `selected_theme` when `show_selected_theme` returns
`Some`. Same change in both the theme selector and the icon theme
selector.
## Context
When `update_matches` runs a filter that yields zero results,
`show_selected_theme` returns `None`. The old code unconditionally
assigned that back to `selected_theme`, wiping out the previous
selection. When the user clears the filter, the selector falls into the
`query.is_empty() && selected_theme.is_none()` branch and resets to
index 0 instead of restoring the original pick.
## Demo
### Before:
https://github.com/user-attachments/assets/62b1531b-d059-4f30-b1f4-a830f2d13a09
### After:
https://github.com/user-attachments/assets/72348666-8dbb-4f35-9446-fa2618340b6c
## How to review
The fix is the same one-line change in two files:
1. `crates/theme_selector/src/theme_selector.rs` — line 458
2. `crates/theme_selector/src/icon_theme_selector.rs` — line 272
The rest is test infrastructure:
3. `crates/theme/src/registry.rs` — `register_test_themes` /
`register_test_icon_themes` helpers
4. Tests in both selector files covering the empty filter → clear filter
flow
## 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 theme selector losing the selected theme after filtering with a
query that matches nothing and then clearing the filter.
After chat functionality was removed, this panel became redundant. It
only displayed three notification types: incoming contact requests,
accepted contact requests, and channel invitations.
This PR moves those notifications into the collab experience by adding
toast popups and a badge count to the collab panel. It also removes the
notification-panel-specific settings, documentation, and Vim command.
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Removed the notification panel from Zed
- `language_model` no longer depends on provider-specific crates such as
`anthropic` and `open_ai` (inverted dependency)
- `language_model_core` was extracted from `language_model` which
contains the types for the provider-specific crates to convert to/from.
- `gpui::SharedString` has been extracted into its own crate (still
exposed by `gpui`), so `language_model_core` and provider API crates
don't have to depend on `gpui`.
- Removes some unnecessary `&'static str` | `SharedString` -> `String`
-> `SharedString` conversions across the codebase.
- Extracts the core logic of the cloud `LanguageModelProvider` into its
own crate with simpler dependencies.
Release Notes:
- N/A
---------
Co-authored-by: John Tur <john-tur@outlook.com>
This fixes a crash with new Preview versions of tsgo after
https://github.com/microsoft/typescript-go/pull/3313
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
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- 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 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 or Added/Fixed/Improved ...
Context
The markdown preview had no search functionality — pressing Ctrl+F did
nothing. This PR implements the SearchableItem trait for
MarkdownPreviewView, enabling in-pane text search with match
highlighting and navigation.
Changes span four crates:
- project: Added SearchQuery::search_str() — a synchronous method to
search plain &str text, since the existing search() only works on
BufferSnapshot.
- markdown: Added search highlight storage to the Markdown entity and
paint_search_highlights to MarkdownElement. Extracted the existing
selection painting into a reusable paint_highlight_range helper to avoid
duplicating quad-painting logic.
- markdown_preview: Implemented SearchableItem with full match
navigation, active match tracking, and proper SearchEvent emission
matching Editor behavior.
- Keymaps: Added buffer_search::Deploy bindings to the MarkdownPreview
context on all three platforms.
The PR hopefully Closes
https://github.com/zed-industries/zed/issues/27154
How to Review
1. crates/project/src/search.rs — search_str method at the end of impl
SearchQuery. Handles both Text (AhoCorasick) and Regex variants with
whole-word and multiline support.
2. crates/markdown/src/markdown.rs — Three areas:
- New fields and methods on Markdown struct (~line 264, 512-548)
- paint_highlight_range extraction and paint_search_highlights (~line
1059-1170)
- The single-line addition in Element::paint (~line 2003)
3. crates/markdown_preview/src/markdown_preview_view.rs — The main
change. Focus on:
- SearchEvent::MatchesInvalidated emission in schedule_markdown_update
(line 384)
- EventEmitter<SearchEvent> and as_searchable (lines 723, 748-754)
- The SearchableItem impl (lines 779-927), especially active_match_index
which computes position from old highlights to handle query changes
correctly
4. Keymap files — Two lines each for Linux/Windows, one for macOS.
Self-Review Checklist
- [ x ] I've reviewed my own diff for quality, security, and reliability
- [ x ] Unsafe blocks (if any) have justifying comments (no unsafe)
- [ x ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
(should be 😄 )
- [ - ] Tests cover the new/changed behavior (not sure)
- [ - ] Performance impact has been considered and is acceptable (I'm
not sure about it and it would be nice to see experienced people to
test)
Release Notes:
- Added search support (Ctrl+F / Cmd+F) to the markdown preview
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR bumps the version of the Proto extension to v0.3.2.
Release Notes:
- N/A
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Oleksiy Syvokon