# Conflicts:
#	crates/multi_buffer/src/path_key.rs
#	crates/search/src/project_search.rs

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

## Summary

- Display the full branch name in the DocumentationAside panel for
thread branch picker entries, so users can see truncated branch names in
full
- Add a separator between the branch name and descriptive text, matching
the pattern used by the model selector's DocumentationAside

Release Notes:

- Agent: Improved branch picker by displaying the full branch name in
the documentation aside.

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>

Corresponding font-kit commit:
https://github.com/zed-industries/font-kit/commit/94b0f28166665e8fd2f53ff6d268a14955c82269

Before, Zed has 3 different versions of `dirs` crate to compile, this PR
bumps the related dependencies to have one, latest, version of `dirs`
instead.

Release Notes:

- N/A

## Summary

The docs preprocessor was configured with `renderer = ["html"]`, but the
actual output renderer is `zed-html`. This mismatch caused mdbook to
skip the preprocessing step, leaving YAML frontmatter unprocessed in the
rendered HTML.

**Symptoms:**
- YAML frontmatter (`---\ntitle: ...\n---`) leaked into rendered HTML
- `---` rendered as `<hr />`
- Frontmatter fields appeared as `<h2>` headings (setext heading
interpretation)
- Meta description tags showed default values instead of page-specific
descriptions

## Root Cause

The `renderer = ["html"]` config was introduced in August 2024 (#16883)
when the preprocessor was first added. At that time, the output was the
standard `html` renderer.

In July 2025 (#35112), the `[output.zed-html]` custom renderer was added
for frontmatter/postprocessing support, but the preprocessor's
`renderer` filter wasn't updated to match.

**Why it broke now (April 12, 2026):**

The mismatch was latent - it worked inconsistently depending on CI
environment conditions. Comparing two deploys from the same day:

| Deploy | Network Errors | Preprocessing |
|--------|---------------|---------------|
| 19:00 UTC | 0 | ✓ Runs correctly |
| 21:54 UTC | Many (`static.crates.io` connection failures) | ✗ Skipped
|

The 21:54 deploy had network errors during `cargo run -p
docs_preprocessor`. mdbook appears to have silently skipped the
preprocessor and proceeded directly to the renderer. The postprocessor
still ran (via the renderer's separate cargo command), but without
preprocessing, frontmatter wasn't converted to metadata.

**The fix:** Change `renderer = ["html"]` to `renderer = ["html",
"zed-html"]` to support both the custom renderer and any fallback to the
standard html renderer (e.g., during local development or if mdbook
commands internally use html).

## Test plan

- [x] Local build produces correct HTML without frontmatter leaking
- [x] Meta descriptions correctly populated from frontmatter  
- [x] CI `check_docs` shows all 3 preprocessor steps running:
  - `docs_preprocessor supports zed-html`
  - `docs_preprocessor` (preprocessing)
  - `docs_preprocessor postprocess`

Release Notes:

- N/A

Follow up to #53737, that introduced an ordering issue where we would
override the existing thread metadata in the case of loading a session

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

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

This change allows using simple navigation keys (PageDown / PageUp /
Ctrl-Home / Ctrl-End) when the message editor is focused, but only if
the cursor is at the beginning/end of the message, where pressing these
keys would normally result in no-op.

One important corollary is that when the cursor is in an empty message,
navigation keys scroll the thread.

We already have this behavior for Up/Down and this change just expands
it for other navigation keys.

Demo:


[Demo](https://github.com/user-attachments/assets/ff540c8c-a223-417b-b16a-b0d08599b1ae)



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

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

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

Release Notes:

- Fixed the sidebar opening when a new project in a new window was
opened

follow up #47471 

As described in #47471, we introduced a direction-aware strategy to
improve user experience when interacting with hover popovers. In this
follow-up, we are adding `hover_popover_sticky` and
`hover_popover_hiding_delay` to control whether the feature introduced
in 47471 enabled, and to let users configure the delay to balance
responsiveness . Also `hover_popover_sticky` can now be imported from
`editor.hover.sticky`, as well as `hover_popover_hiding_delay` from
`editor.hover.hidingDelay` in VSCode.


Also this PR adds several tests:
- `test_hover_popover_cancel_hide_on_rehover`: when the cursor returns
to the hover after leaving once within the hiding delay, the hover
should persist while canceling the existing hiding timer.
- `test_hover_popover_enabled_false_ignores_sticky` : when
`hover_popover_enabled` is false, the `hover_popover_sticky` and
`hover_popover_hiding_delay` have no effect(since no hover is shown).
- `test_hover_popover_sticky_delay_restarts_when_mouse_gets_closer`:
when mouse gets closer to hover popover, we expect the timer to reset
and the hover remains visible.
- `test_hover_popover_hiding_delay`: check if the delay(in test, that's
500ms) works.
- `test_hover_popover_sticky_disabled`: when hover_popover_sticky is
false, the hover popover disappears immediately after the cursor leaving
the codes.
- VSCode import test in `settings_store.rs`

Release Notes:

- Added `hover_popover_sticky` and `hover_popover_hiding_delay` settings
to balance responsiveness of hover popovers.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Saw this while manually testing other stuff.

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

Semantics and code was mostly taken from the existing behaviour of the
Left/Right arrow keys.

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

Release Notes:

- Added ability to toggle tree collapse in git panel

Missed this yesterday in
https://github.com/zed-industries/zed/pull/53433, because in the `with`
level, we need to use the proper context syntax.

Release Notes:

- N/A

Summary

Semantic token highlighting was missing when opening a file from
multibuffer search results (Ctrl+Shift+F). Which file got hit depended
on window size and scroll offset.

## Root cause

Two async tasks race to write `post_scroll_update`:

1. `set_visible_line_count` (scroll.rs:682) fires on first render and
spawns a task that calls `register_visible_buffers` + `update_lsp_data`
(requests semantic tokens).

2. `open_buffers_in_workspace` (editor.rs:25049) calls
`change_selections` with autoscroll right after creating the editor.
This emits `ScrollPositionChanged`, whose handler (editor.rs:2655)
replaces `post_scroll_update` with a task calling
`update_data_on_scroll`.

3. `update_data_on_scroll` (editor.rs:26099) has a singleton guard: `if
!self.buffer().read(cx).is_singleton()` that skips `update_lsp_data` for
single-file buffers. This is a scroll optimization, singleton buffers
don't change their visible buffer set on scroll.

4. The initial task gets dropped, the replacement skips
`update_lsp_data`, semantic tokens are never requested.

## Fix

Added a `needs_initial_lsp_data` flag to the Editor struct, set to
`true` on creation. `update_data_on_scroll` checks this flag alongside
the singleton guard, so `update_lsp_data` runs at least once even for
singletons. The flag flips to `false` right after, so subsequent scrolls
behave exactly as before. No perf impact after the first render.

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

## Demo

Before:

https://github.com/user-attachments/assets/77d07d95-cb4a-44ff-842d-1f7a46653ca9
After:


https://github.com/user-attachments/assets/2c942f52-4ec3-459f-a97b-93919e4bfb3d



## Release notes

- Fixed semantic token highlighting missing when opening a buffer from
multibuffer search results

Closes #ISSUE

Release Notes:

- N/A

Follow up to https://github.com/zed-industries/zed/pull/53574
Closes https://github.com/zed-industries/zed/issues/53705

In the draft feature PR, we didn't update the new thread creation from
the agent panel's toolbar to _also_ create a corresponding draft item in
the sidebar. Additionally, the draft feature exposed a
previously-existing bug where the toolbar wouldn't get synced with the
currently selected agent; and as you navigated between them, we would
fall back to the native agent, as well as when you hit cmd-n.

cc @mikayla-maki just a quick FYI here for the revamp! Will push this
forward in the meantime given it's a bit of a bad bug.

Release Notes:

- N/A

A note-worthy thing I'm adding in this PR to fix an agent panel problem
is a trait method allowing to set a min-width in panels. I think some of
them—if not all—could benefit from it, because there is a certain width
these panels can get in that we just can't ensure they will work; things
will break. So we either accept that and let the user's common sense
understand that, or we don't allow them to reach that state... Surely, a
small enough _window_ size can still break things, but then it's out of
the realms of solution...

Release Notes:

- Agent: Fixed multi-line queued messages getting cut-off when the agent
panel is in full screen.
- Agent: Fixed agent panel getting auto-closed after submitting a queued
message when the panel is in full screen.
- Agent: Added a min-width to the agent panel, preventing it from
reaching a small enough width where it would be essentially unusable.

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>

When clicking a draft placeholder ("New Agent Thread" tab) or confirming
one via keyboard, the agent panel now always opens. Previously it only
focused the panel if it was already visible.

Regular threads and drafts with IDs already opened the panel through
`activate_draft` and `load_agent_thread_in_workspace`. The project
header click continues to activate the workspace without forcing the
panel open.

cc @danilo-leal

Release Notes:

- N/A

Release Notes:

- N/A

---------

Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Nathan Sobo <nathan@zed.dev>

Fixes a regression introduced in
https://github.com/zed-industries/zed/issues/49603
Supersedes https://github.com/zed-industries/zed/pull/52638

We want to leave these non-existent workspaces in the database for up to
7 days, in case they are on external drives that are restored later, but
we do *not* want to show them in the UI if they don't exist.

Release Notes:

- Fixed an issue where deleted folders appeared in the recent project
picker

---------

Co-authored-by: ojpro <contact@ojpro.me>

This PR adds a callout in the agent panel communicating about the lack
of support for multi-root workspaces within ACP agents.

Release Notes:

- N/A

When the agent panel is zoomed-in, or if it's wide enough to the point
you see a lot of horizontal padding due to the max-width, it wasn't
previously possible to scroll the thread in that padding while your
mouse was resting in that area.

Release Notes:

- Agent: Fixed scroll behavior when the agent panel is zoomed-in.

Previously, when opening a remote project via the sidebar, and picking a
new project path via the path picker, it would incorrectly open in a new
window.

Release Notes:

- N/A

Replaces raw provider error strings in the agent panel with specific,
user-friendly error callouts. Each error now has a clear title,
actionable copy, and appropriate buttons instead of the generic "An
Error Happened" fallback.

Error variants added:

Variant | Title | Body | Trigger |
|---|---|---|---|
| `RateLimitExceeded` | Rate Limit Reached | {Provider}'s rate limit was
reached. Zed will retry automatically. You can also wait a moment and
try again. | Provider rate limit exhausted after retries |
| `ServerOverloaded` | Provider Unavailable | {Provider}'s servers are
temporarily unavailable. Zed will retry automatically. If the problem
persists, check the provider's status page. | Provider server overloaded
or internal server error |
| `PromptTooLarge` | Context Too Large | This conversation is too long
for the model's context window. Start a new thread or remove some
attached files to continue. | Conversation exceeds model's context
window |
| `NoApiKey` | API Key Missing | No API key is configured for
{Provider}. Add your key via the Agent Panel settings to continue. | No
API key configured for a direct provider |
| `StreamError` | Connection Interrupted | The connection to
{Provider}'s API was interrupted. Zed will retry automatically. If the
problem persists, check your network connection. | Stream dropped or I/O
error during generation |
| `InvalidApiKey` | Invalid API Key | The API key for {Provider} is
invalid or has expired. Update your key via the Agent Panel settings to
continue. | API key present but invalid or expired |
| `PermissionDenied` | Permission Denied | {Provider}'s API rejected the
request due to insufficient permissions. Check that your API key has
access to this model. | API key lacks access to the requested model |
| `RequestFailed` | Request Failed | The request could not be completed
after multiple attempts. Try again in a moment. | Upstream provider
unreachable after retries |
| `MaxOutputTokens` | Output Limit Reached | The model stopped because
it reached its maximum output length. You can ask it to continue where
it left off. | Model hit its maximum output token budget |
| `NoModelSelected` | No Model Selected | Select a model from the model
picker below to get started. | No model configured when a message is
sent |
| `ApiError` | API Error | {Provider}'s API returned an unexpected
error. If the problem persists, try switching models or restarting Zed.
## Approach

- Added typed errors (`NoModelConfiguredError`, `MaxOutputTokensError`)
where previously raw strings were used, so they can be reliably downcast
- Extended `From<anyhow::Error> for ThreadError` to downcast
`LanguageModelCompletionError` variants before falling through to the
generic `Other` case
- Each variant has a dedicated `render_*` function with appropriate
buttons (retry icon, New Thread, or none)
- Telemetry events updated with specific `kind` labels for each new
variant

Release Notes:

- Improved error messages in the agent panel to show specific,
actionable copy instead of raw provider error strings

Self-Review Checklist:

- [ x] I've reviewed my own diff for quality, security, and reliability
- [n/a] 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)
- [n/a ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable


Release Notes:

Improved error messages in the agent panel to show specific, actionable
copy instead of raw provider error strings

This changes the behavior of the recent project picker in multi-folder
projects, so that when you select a folder that is a repository, it sets
the active repository in the Git panel as well.

Release Notes:

- N/A

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

Release Notes:

- N/A

This PR makes it so we disable training data collection for Edit
Prediction based on the organization's configuration.

Closes CLO-641.

Release Notes:

- N/A

We hope this fixes an issue with permissions

Release Notes:

- N/A

This will ensure we do not post a second Slack message in case the first
check was successful. We still _run_ the second check, but do not notify

Release Notes:

- N/A

This PR adds the `correctly_deleted_chars` field and updates `kept_rate`
to account for it, not just inserted chars.

It also adds `recall_rate` to measure coverage of reference
insertions/deletions.

Finally, it renames "final" to "reference" and "prediction" to
"candidate".

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

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

## Details

- The [devcontainer CLI writes the `devcontainer.metadata` label as a
bare JSON object](https://github.com/devcontainers/cli/issues/1054) when
there is only one metadata entry (e.g. docker-compose devcontainer with
a Dockerfile and no features)
- Zed's `deserialize_metadata` only accepted a JSON array, causing
deserialization to fail with `invalid type: map, expected a sequence`
- This made it impossible to attach to existing docker-compose
devcontainers created by the devcontainer CLI or VS Code

The fix tries parsing as an array first, then falls back to parsing as a
single object wrapped in a vec. This mirrors how the [devcontainer CLI
itself reads the
label](https://github.com/devcontainers/cli/blob/main/src/spec-node/imageMetadata.ts#L476-L493).

An upstream fix has also been submitted:
https://github.com/devcontainers/cli/pull/1199

## Reproduction

1. Create a docker-compose devcontainer with a Dockerfile and no
features:

`.devcontainer/devcontainer.json`:
```json
{
  "name": "repro",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "remoteUser": "root"
}
```

`.devcontainer/docker-compose.yml`:
```yaml
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    command: sleep infinity
    volumes:
      - ..:/workspace
```

`.devcontainer/Dockerfile`:
```dockerfile
FROM ubuntu:24.04
```

2. `devcontainer up --workspace-folder .`
3. Open the folder in Zed, fails with metadata deserialization error

Release Notes:

- Fixed attaching to a devcontainer that has a single metadata element
which was started with `devcontainer-cli`

This PR makes it so the Collab panel can be disabled by the
organization's configuration:

<img width="239" height="191" alt="Screenshot 2026-04-09 at 2 38 35 PM"
src="https://github.com/user-attachments/assets/48216c00-85cd-441a-b613-7468db2b25bd"
/>

Depends on https://github.com/zed-industries/cloud/pull/2247.

Closes CLO-638.

Release Notes:

- N/A

## What does this PR changed

Adds footnote rendering and navigation to Zed's markdown preview.

- **Footnote references**: (`[^1]`) render inline as `[1]` with link
styling (color + underline)
- **Footnote definitions**: (`[^1]: ...`) render at the bottom with a
horizontal separator, smaller text (85% size), and a label prefix
- **Click-to-navigate**: clicking a footnote reference scrolls to its
definition


https://github.com/user-attachments/assets/a79a0136-f22d-40ac-8b53-cfefa8573d21

## OOS/ Need discussion

- **Display style**: Since currently the gpui crate does not provide a
superscript style, in this PR we publish the feature with using
[`[1]`]() instead of aligning to the GFM styled[^1]
- **Footnote definition placement**: GFM renders the footnote at the
bottom of the content no matter where the user place the footnote
definition, but the `pulldown_cmark` renders the footnote just at where
user place it, for this PR I'll keep the footnote where `pulldown_cmark`
renders it, and we may have some more discuss on if we need to move them
to the bottom of the markdown preview

[^1]: GitHub-flavoured markdown

## What to test

- [ ] Open a markdown file with footnotes (e.g. `Text[^1]\n\n[^1]:
Definition`)
- [ ] Verify reference renders as `[1]` with link color
- [ ] Verify definition renders below a separator with smaller text
- [ ] Verify pointer cursor appears on hover over `[1]`
- [ ] Verify clicking `[1]` scrolls to the definition
- [ ] Verify normal links still work as before
- [ ] `cargo test -p markdown` passes (46 tests)

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

Closes #13603

Release Notes:

- Added support for footnotes in Markdown Preview.

---------

Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>

Related to https://github.com/zed-industries/zed/pull/53484. 

This PR fixes a `--` file being created when staging a hunk.

Release Notes:

- N/A

Follow-up of https://github.com/zed-industries/zed/pull/53452

Release Notes:

- N/A

Release Notes:

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

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

Release Notes:

- Fixed terminal tabs losing keyboard focus after switching tabs on Linux X11

Re-building the tool on CI every time is pointless when can just install
the binary itself

Release Notes:

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

Follow-up of https://github.com/zed-industries/zed/pull/53452

* disables mouse wheel zooming in agent, debugger, keymap editor, dev
inspector and repl-related editors
* adjusts the code to call for theme changes directly instead of sending
the events, so that agent following does not capture the events and
changes its font size

Release Notes:

- N/A

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

- Fix crash on startup when the X11 server supports XInput < 2.4 (e.g.
XInput 2.3)
- Gesture event mask bits (pinch begin/update/end) are now only
requested when the server advertises XInput >= 2.4
- Zed previously failed to open any window on affected systems, printing
`Zed failed to open a window: X11 XiSelectEvents failed`

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









## Problem

On X11 systems where the XInput extension version is older than 2.4, Zed
crashes immediately on startup with:

```
Zed failed to open a window: X11 XiSelectEvents failed.

Caused by:
    X11 error X11Error { error_kind: Value, error_code: 2, sequence: 277,
    bad_value: 27, minor_opcode: 46, major_opcode: 131,
    extension_name: Some("XInputExtension"),
    request_name: Some("XISelectEvents") }
```

This makes Zed completely unusable on any X11 display server that only
supports XInput 2.3 or earlier, which includes many current Ubuntu
20.04/22.04 systems, remote X11 sessions, and VNC/Xvfb setups.

### Root cause

During window creation, `X11WindowState::new` calls `XISelectEvents`
with an event mask that unconditionally includes gesture event bits
(`GESTURE_PINCH_BEGIN`, `GESTURE_PINCH_UPDATE`, `GESTURE_PINCH_END`).
These gesture events were introduced in **XInput 2.4**.

When the X server only supports XInput 2.3 (or older), it does not
recognize these mask bits and rejects the entire `XISelectEvents`
request with a `BadValue` error. This is fatal because the error is
propagated up and prevents the window from being created.

A comment in the original code stated:

> If the server only supports an older version, gesture events simply
won't be delivered.

This is incorrect. The X11 protocol does **not** silently ignore unknown
mask bits in `XISelectEvents` — it rejects the whole request.

### How XInput version negotiation works

The client calls `XIQueryVersion(2, 4)` to announce the highest version
it supports. The server responds with the highest version **it**
supports (e.g. `2.3`). The client is then responsible for not using
features beyond the negotiated version. The existing code ignored the
server's response and used 2.4 features unconditionally.

## Fix

### Approach

Check the XInput version returned by the server. Only include gesture
event mask bits in `XISelectEvents` when the negotiated version is >=
2.4. On older servers, basic input events (motion, button press/release,
enter, leave) still work normally — only touchpad pinch gestures are
unavailable.

### Changed files

**`crates/gpui_linux/src/linux/x11/client.rs`**

1. Added `supports_xinput_gestures: bool` field to `X11ClientState`.
2. After the existing `xinput_xi_query_version(2, 4)` call, compute
whether the server version is >= 2.4:
   ```rust
   let supports_xinput_gestures = xinput_version.major_version > 2
|| (xinput_version.major_version == 2 && xinput_version.minor_version >=
4);
   ```
3. Added an `info!` log line reporting the detected XInput version and
gesture support status.
4. Pass `supports_xinput_gestures` through `open_window` into
`X11Window::new`.

**`crates/gpui_linux/src/linux/x11/window.rs`**

1. Added `supports_xinput_gestures: bool` parameter to both
`X11Window::new` and `X11WindowState::new`.
2. The `XISelectEvents` call now builds the event mask conditionally:
- Always includes: `MOTION`, `BUTTON_PRESS`, `BUTTON_RELEASE`, `ENTER`,
`LEAVE`
- Only when `supports_xinput_gestures` is true: `GESTURE_PINCH_BEGIN`,
`GESTURE_PINCH_UPDATE`, `GESTURE_PINCH_END`

### What is NOT changed

- The gesture event **handlers** in `client.rs`
(`XinputGesturePinchBegin`, `XinputGesturePinchUpdate`,
`XinputGesturePinchEnd`) are left as-is. They simply won't be triggered
on servers without gesture support, since the events are never
registered.
- No behavioral change on systems with XInput >= 2.4 — gesture events
continue to work exactly as before.

## Testing

| Test | Before fix | After fix |
|------|-----------|-----------|
| `./target/release/zed .` on XInput 2.3 | Immediate crash (exit code 1)
| Window opens successfully (runs until killed) |
| XInput version detection | Version queried but response ignored |
Version checked and logged |

Verified on an X11 system with XInput 2.3 (X.Org 1.20.13, Ubuntu 20.04).

## Test plan

- [x] Build succeeds (`cargo build --release`)
- [x] Zed launches and opens a window on XInput 2.3 system
- [x] No regression on the basic input event path (motion, clicks,
enter/leave still registered)
- [ ] Verify gesture pinch events still work on a system with XInput >=
2.4

Release Notes:

- Fixed Zed failing to start on X11 systems with XInput version older
than 2.4, which includes many Linux distributions and remote desktop
setups.

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 or Added/Fixed/Improved ...

Continuation of https://github.com/zed-industries/zed/pull/53566, now
with proper thread root mutation.

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

Fixes a UI regression introduced in
https://github.com/zed-industries/zed/pull/48467, which prevented
automatic update statuses from being shown in the title bar unless the
update was checked for manually by the user, causing some users to
unknowingly cancel updates in progress by closing the application, since
there was no indication.


https://github.com/user-attachments/assets/ea16a600-3db4-49dc-bca5-11c8fcfff619

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 https://github.com/zed-industries/zed/issues/50162

Release Notes:

- Fixed missing indication that an update was currently being downloaded
or installed in the title bar

Removed 'Text Threads' option from the mode dropdown for AI issues,
since #52757 removed the feature

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