Release Notes:

- N/A

### Summary

This PR implements remote support for git store operations that the
sidebar's archive thread checkpoint/restore featured relied on. This was
the second to last blocker for remote usage of this feature.

I also made a shared backend between `update_ref` and `delete_ref`
called `edit_ref` because they run the same git command and this allowed
for some code unification.

#### Remote Git Operations 
- `Repository::update_ref`
- `Repository::delete_ref`
- `Repository::repair_worktrees`
- `Repository::create_archive_checkpoint`
- `Repository::restore_archive_checkpoint`


#### Follow up

`agent_ui::thread_worktree_archive::find_or_create_repository` needs to
be made aware of the remote machine that the repository it's searching
for is on. Once that is completed, we can get the correct repo when
archiving a remote thread and the flow should work without any problems.

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 archiving a thread, we now check whether the linked worktree lives
inside the Zed-managed worktrees directory (configured via
`git.worktree_directory`). If it doesn't — meaning the user created it
themselves outside of Zed — we skip both the directory deletion and the
`git worktree remove`, leaving it untouched.

Previously, archiving a thread would delete *any* linked worktree
associated with the thread's folder paths, even ones the user had
created manually via `git worktree add`.

Release Notes:

- Fixed archiving an agent thread deleting linked git worktrees the user
created outside of Zed's managed worktrees directory.

The `worktree_receivers` and `worktree_directory_setting` were pre
computed as `Option`s before the async block, then unwrapped with
`expect` inside the match arm that always had them set. Move the
fetching directly into the `WorktreeCreationArgs::New` arm so the values
are never optional, replacing the panicking expects with error
propagation via `?`.

The expects were guaranteed to never panic because the `Some` codepath
used the same branching logic of the unwrap codepath later on. This
change is just for future maintainability though.

Self-Review Checklist:

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

Release Notes:

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

This fixes a but that @ConradIrwin noticed where the flexible docks
widths are weirdly dependent on the width of the active pane.

Release Notes:

- Fixed a bug where flexible docks resized incorrectly in certain cases.
- Fixed an issue where resizing a flexible-width panel in the left dock
would also resize fixed-width panels.

This adds a merge queue trigger to our main CI job to allow for a merge
queue which runs a subset of our tests before merging to main.

With this setup, merging to main would probably take around one to two
minutes and would not catch all but definitely most issues. We could
extend it here though as we'd like.

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

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:

- Added "New Center Terminal" button to window context menu

"New Terminal" only opens a new terminal window in the dedicated
terminal view, while "New Center Terminal" opens a new terminal in the
currently active view.

"+"/"New..." context menu
<img width="487" height="318" alt="Screenshot_20260411_184840"
src="https://github.com/user-attachments/assets/7c1597cf-5638-4d76-a486-537033cb8da5"
/>

Right click context menu
<img width="422" height="386" alt="Screenshot_20260411_184904"
src="https://github.com/user-attachments/assets/4e557e21-8839-4226-b704-87e37fbd8f46"
/>

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

Release Notes:

- Fixed gap where runArgs were not respected when specified in
devcontainer.json

Release Notes:

- N/A

This is a follow up to #48003, instead of removing the settings key in a
new migration, we can prevent the existing one from adding settings in
the first place.

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

Remove the `DEFAULT_THREADS_SHOWN` limit and the View More / Collapse
row from the sidebar thread list. When a project group is expanded, all
of its threads are now shown. Fold/unfold of project group headers is
preserved.

### Changes

- Remove `ListEntry::ViewMore` variant and `render_view_more`
- Remove `DEFAULT_THREADS_SHOWN`, `group_extra_batches`,
`set_group_visible_thread_count`, `expand/collapse_thread_group`
- Remove `visible_thread_count` from `ProjectGroupState`,
`SerializedProjectGroupState`, `ProjectGroup`, and persistence
- Remove `ShowMoreThreads` / `ShowFewerThreads` actions and vim
keybindings

cc @danilo-leal

Release Notes:

- N/A

### Docs update.

  - adding 'what is Dexter' one-liner
  - adding config examples

Self-Review Checklist:

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

✅ Elixir LS update -
[PR](https://github.com/zed-extensions/elixir/pull/115) merged

Release Notes:
- N/A

---------

Co-authored-by: AltCode <altcode@vivaldi.net>

HTTP context servers don’t support the settings field, so remove it
during migration to avoid confusion. Other context server types are
unaffected.

Closes #44786.


https://github.com/user-attachments/assets/4cabf405-c9e7-4d6e-a43d-f642fc4771e0



Release Notes:

- Removed deprecated key from HTTP `context_servers`

---------

Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>

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

---------

Co-authored-by: Gaauwe Rombouts <mail@grombouts.nl>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>

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>

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

---------

Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>

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

Release Notes:

- N/A

Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>

## Summary

- The cross-compile path for building `remote_server` via `cargo
zigbuild` was missing `.current_dir()`, causing it to inherit the
process cwd
- This fails with "cannot specify features for packages outside of
workspace" when Zed is launched from outside its source tree
- The native build path at the same location already sets
`.current_dir()` correctly — this aligns the cross-compile path

Closes #53950

## Test plan

- [x] Build Zed from source
- [x] Launch from `/tmp`: `cd /tmp && /path/to/zed some-project
--dev-container`
- [x] Verify dev container cross-compilation succeeds

Release Notes:

- Fixed dev container cross-compilation failing when Zed is launched
from outside its source directory

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

When adding code lens to the long list of search items, I've failed to
find it when searching, as we always select first item in the matches
list, which is not necessarily the best one.

Left is before, right is after:


https://github.com/user-attachments/assets/9033dfd8-abde-4a45-a214-ae859105d6ad


Release Notes:

- Improved settings search ergonomics

We will not be proceeding with this, thus removing it here to have less
variants.

Release Notes:

- N/A

Closes #53919

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:

- gemini: Fixed an issue with MCP servers specifying tools with specific
schemas

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

## Context

When a file is renamed via the project panel while open in an editor,
Zed would restore the old (no longer existing) path on reload .

On rename, `language::Buffer` emits `BufferEvent::FileHandleChanged`,
which propagates to `multi_buffer::Event::FileHandleChanged` →
`EditorEvent::TitleChanged`. However, `should_serialize()` only matched
`Saved | DirtyChanged | BufferEdited`, so no re-serialization was
triggered and the `editors` DB table retained the stale `abs_path`.

The fix adds a dedicated `EditorEvent::FileHandleChanged` variant, emits
it alongside `TitleChanged` when the buffer's file handle changes, and
adds it to `should_serialize()`. Since `Editor::serialize()` already
reads the current path from the buffer at call time, this naturally
writes the new path to the DB.

Closes #51629

## How to Review

Three files edited:
- `editor.rs`: splits `FileHandleChanged` into its own arm and emits the
new event variant
- `items.rs`: adds `FileHandleChanged` to `should_serialize`
- `items.rs` (test): `test_file_handle_changed_on_rename` does a full
rename via `Project::rename_entry` and asserts the event fires and the
buffer path updates

## Self-Review Checklist

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

Release Notes:

- Fixed renamed files being reopened with their old path after a restart

**Important remark :**
This pull request is a follow-up on the review of @SomeoneToIgnore on
this pull request, https://github.com/zed-industries/zed/pull/51717,
which was inadvertently closed because I mistakenly deleted my previous
fork of the zed repo, sorry for any inconvenience caused by this

Manual test video below :

[Screencast from 2026-03-16
23-28-46.webm](https://github.com/user-attachments/assets/ff2e3259-ae26-4655-83b8-f693e84306d2)

## Context

Closes #53252

When using `ToggleAll` to open the tab switcher and then closing the
last tab in the currently active pane via `CloseSelectedItem`, the tab
switcher would unexpectedly dismiss. Closing tabs from an inactive pane
worked correctly.

**Root cause:** `force_remove_pane` in `Workspace` unconditionally calls
`window.focus(fallback_pane)` when the active pane is removed. This
focus change causes the tab switcher picker's editor to receive a
`Blurred` event, which
triggers `Picker::cancel` → `delegate.dismissed` → `DismissEvent`,
dismissing the modal.

**Fix:** When a modal is active, skip the `window.focus` call and
instead call `set_active_pane` directly. This keeps the active pane
pointer up to date without stealing focus from the modal.

Video of manual test after fix :

[Screencast from 2026-04-07
00-24-56.webm](https://github.com/user-attachments/assets/eeb74313-1713-48db-8421-db740ef7a7b2)

## How to Review

- `crates/workspace/src/workspace.rs` : In `force_remove_pane`, when the
removed pane was the active pane, the fallback pane now only receives
focus if no modal is currently open. Otherwise, `set_active_pane` is
called directly, which updates `active_pane`, `last_active_center_pane`,
and the status bar without touching window focus.

- `crates/tab_switcher/src/tab_switcher_tests.rs` : New test
`test_toggle_all_stays_open_after_closing_last_tab_in_active_pane`
reproduces the issue: two panes each with one file, the active pane's
tab is closed via `CloseSelectedItem`, and the test asserts the tab
switcher remains open with the other file still listed.

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

Release Notes

- Fixed tab switcher dismissing when closing the last tab in the active
pane

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

Fixes calculation of Ollama model context length. Now prefers num_ctx
model configuration over model architecture context length the same way
Ollama does.

Closes #42340

Release Notes:

- Fix calculation of Ollama model context length

When archiving a thread's linked worktree, `git worktree remove` can
fail to delete the working directory while still removing the admin
metadata in `.git/worktrees/<name>`. This leaves an orphaned folder on
disk that no longer appears in `git worktree list`.

## Fix

Delete the directory ourselves first with `std::fs::remove_dir_all`,
then call `git worktree remove --force` to clean up only the admin
entry. Git already handles the case where the working tree is already
gone (since
[git/git@ee6763a](https://github.com/git/git/commit/ee6763af0a3b97225803c6c908a29de40336cf38)).

Also fixes `FakeGitRepository::remove_worktree` to handle a missing
working tree directory (matching real git behavior) by scanning
`.git/worktrees/` entries when the `.git` pointer file can't be read.

Release Notes:

- Fixed archiving an agent thread sometimes leaving the worktree folder
on disk even though the git worktree was removed.

This fixes #53740.

A few MCP docs links were still pointing at old extension slugs, so they
led to dead pages. This updates those links to the current canonical
slugs.

Release Notes:

- N/A

This fixes a regression where `zed -n .` in a subdirectory of an
already-open
project would redirect to the parent window instead of creating a new
one.
The root cause was that commit 66d2cb20c9 ("Adjust `zed -n` behavior")
made
`-n` run the worktree matching loop with subdirectory matching enabled,
when
previously `-n` skipped matching entirely.

## Changes

### Bug fix
- **Restore `-n` to always create a new window.** No worktree matching,
no
exceptions. This matches the behavior from when `-n` was first
introduced.

### New `--classic` flag
- Adds a hidden `--classic` CLI flag that explicitly selects the
pre-sidebar
default behavior: new window for directories, reuse existing window for
  files already in an open worktree.
- The `cli_default_open_behavior` setting now toggles between `-e` (add
to
sidebar) and `--classic` behavior. When set to `new_window`, the classic
  logic is used instead of unconditionally opening a new window.

### Refactor CLI open options
Replaces the old grab-bag of `open_new_workspace: Option<bool>`,
`force_existing_window: bool`, `classic: bool`, and `reuse: bool` with:

- **`cli::CliOpenBehavior` enum** — a single enum on the IPC boundary
with
variants `Default`, `AlwaysNew`, `Add`, `ExistingWindow`, `Classic`, and
  `Reuse`.
- **`workspace::WorkspaceMatching` enum** — describes how to match paths
against existing worktrees (`None`, `MatchExact`, `MatchSubdirectory`).
- **`workspace::OpenOptions`** — uses `WorkspaceMatching` plus a simple
  `add_dirs_to_sidebar: bool` instead of overlapping boolean flags.

The translation from CLI enum to workspace options happens in
`open_listener.rs`, keeping both layers clean and independent.

Release Notes:

- N/A

<img width="297" height="505" alt="Screenshot 2026-04-14 at 3 20 23 PM"
src="https://github.com/user-attachments/assets/90366ccd-86db-497e-9c81-af94b4144ebe"
/>


Display the git branch name alongside the worktree name in the sidebar's
thread list (or without the worktree name, if it's a main worktree).

Release Notes:

- Added branch name display next to worktree names in the agent sidebar
thread list.

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

- Remove the ability to pick a branch from the agent panel; delegate
this to the title bar picker
- Make the worktree creation earger, just as you selected whether you
want to create it from main or current branch
- Remove flicker when creating a new worktree and switching to a
previously existing one
- Improve some UI stuff: how we display that a worktree is
creating/loading, the branch and worktree icons, etc.
- Fixed a bug where worktrees in a detached HEAD state wouldn't show up
in the worktree pickers

A big part of the diff of this PR is the removal of everything involved
with the `StartThreadIn` enum/the set up involved in only creating the
worktree by the time of the first prompt send.

Release Notes:

- Agent: Improved and simplified the UX of creating threads in Git
worktrees.
- Git: Fixed a bug where worktrees in a detached HEAD state wouldn't
show up in the worktree picker.

---------

Co-authored-by: Nathan Sobo <nathan@zed.dev>

Improves the worktree restore and archive code paths:

- In `restore_worktree_via_git`, the old code blindly attempted
`change_branch` and fell back to `create_branch` on failure, which could
clobber a branch that had moved to a different SHA during archival. Now
resolves the branch ref first and only checks out the branch if it still
points at the original commit; if the branch has moved, the worktree
stays in detached HEAD. If the branch doesn't exist, tries to recreate
it.
- In `change_worktree_paths` and `change_worktree_paths_by_main`,
archived threads are now excluded from path mutations so their folder
paths are preserved for restore.
- In the sidebar, `ProjectGroupKey` construction for archived thread
activation now uses `from_worktree_paths` (which resolves to main
worktree paths) instead of `new` with the linked worktree's folder
paths. This ensures that restoring a linked worktree thread matches the
main repo workspace rather than creating a spurious new one.
- Added `Repository::resolve_ref` for resolving a git ref to its SHA.
- Added tests for `resolve_ref`, branch-moved/not-moved/deleted restore
scenarios, and workspace-matching on restore.

Release Notes:

- N/A

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

---------

Co-authored-by: Kunall Banerjee <hey@kimchiii.space>

Remove the ability to add and remove individual folders from project
groups in the sidebar.

## Changes

**Sidebar project group menu:**
- When there are 2+ local project groups, the ellipsis menu shows "Open
Project in New Window" and "Remove Project" (no separators, no folder
listing)
- When there's only one group or it's remote, the ellipsis menu is
replaced with a close X button that removes the project directly

**Project picker labels:**
- "Open Local Project" → "Open Local Folders"
- "Open Remote Project" → "Open Remote Folder"
- "Add Local Project" → "Add Local Folders"
- "Add Remote Project" → "Add Remote Folder"

**Dead code removal:**
- `MultiWorkspace::remove_folder_from_project_group`
- `MultiWorkspace::prompt_to_add_folders_to_project_group`
- `MultiWorkspace::add_folders_to_project_group`
- `MultiWorkspace::update_project_group_key`
- `MultiWorkspaceEvent::ProjectGroupKeyUpdated`
- `Sidebar::move_threads_for_key_change`
- `ThreadMetadataStore::change_worktree_paths_by_main`
- Associated tests for removed functionality

Per-workspace thread regrouping (when a workspace's worktree paths
change) continues to work via the existing `WorktreePathsChanged` →
`move_thread_paths` flow. The existing
`test_worktree_add_only_regroups_threads_for_changed_workspace` test
(renamed and strengthened) verifies that only the changed workspace's
threads are regrouped, while sibling worktree threads remain in their
original group.

Release Notes:

- Improved sidebar project group menu to show a simple close button for
single-project windows and a streamlined two-item menu for multi-project
windows.

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 will make this easier to use with the GitHub worker.

Release Notes:

- N/A

In `GitStore::open_diff_internal`, when opening a `DiffKind::Unstaged`
diff, we previously always overwrote the `unstaged_diff` field of
`BufferGitState`. This causes a bug in the following situation:

- We call `open_unstaged_diff`, and it hits an await point where it is
loading the index text
- While that task is suspended, we call `open_uncommitted_diff`. It
reaches `open_diff_internal` and sets
`buffer_git_state.uncommitted_diff` and
`buffer_git_state.unstaged_diff`. It also sets the secondary diff for
the uncommitted diff to be the unstaged diff that it just opened.
- The `open_unstaged_diff` task wakes up and enters
`open_diff_internal`. It creates a new entity for the unstaged diff and
overwrites `buffer_git_state.unstaged_diff` with it, but it doesn't
update the secondary diff of the uncommitted diff, which still has the
entity that was produced in the previous step.
- Now the uncommitted diff's secondary diff will never receive updates
from the `GitStore`, causing staging information to be incorrect.

The fix is for `open_diff_internal` to not overwrite an existing
unstaged diff.

Self-Review Checklist:

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

Release Notes:

- Fixed a bug that could cause diff hunks to have an incorrect staged
status.

`AgentPanel::open_thread` (called when clicking `@thread` mention links,
pasting thread links, or opening threads via the CLI) was calling
`external_thread` directly, bypassing the de-duplication guards in
`load_agent_thread`. This meant clicking a thread link to the
currently-active thread would create a redundant `ConversationView`
sharing the same `NativeAgent` session. When the old CV was later
evicted from `background_threads`, its `on_release` called
`close_all_sessions`, removing the session and breaking the surviving CV
with "Session not found".

Fix this by routing `open_thread` through `load_agent_thread`, which
checks the active view, retained threads, and background threads before
creating a new `ConversationView`. This prevents the duplicate from
being created in the first place.

Release Notes:

- Fixed a "Session not found" error that could occur after clicking a
thread mention link.

When a thread created in a git worktree is archived, the archive flow
removes the linked worktree from the project. If a subsequent thread
event fires after this (e.g. an async title-generation task completing),
`handle_thread_event` recalculates `worktree_paths` from the project's
current state — which no longer includes the removed worktree — and
overwrites the archived thread's stored paths with empty ones.

This causes restoring the thread to prompt the user to re-associate a
project, instead of restoring it directly.

**Fix:** return early from `handle_thread_event` when the thread is
already archived, so the stored paths are never overwritten.

Release Notes:

- Fixed archived threads in git worktrees losing their project
association.

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 

Follow up on: https://github.com/zed-industries/zed/pull/53550

Threads in the sidebar are now filtered by remote connection in addition
to path list. Previously, two different machines with the same absolute
project paths (e.g. both at `/home/user/project`) would have their
threads merged into a single sidebar group. Now each remote host gets
its own group.

To support this, this PR introduces `RemoteConnectionIdentity`, a
normalized subset of `RemoteConnectionOptions` that includes only the
fields relevant for identity matching (e.g. SSH host + username + port,
but not nickname or connection timeout). All remote host comparisons in
the sidebar, thread metadata store, and workspace persistence now go
through `same_remote_connection_identity()` instead of raw `==` on
`RemoteConnectionOptions`.

#### Follow Up on remoting for sidebar

1. Make the neighbor in archive thread fallback to the main git worktree
instead of the next thread
2. Start implementing remote git operations that archive feature depends
on
3. Make remote connection pool equality use `RemoteConnectionIdentity`

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: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>

Soft-deprecates the `-r`/`--reuse` CLI flag by hiding it from `--help`
output. The flag remains fully functional for backward compatibility,
but new users will discover `-e`/`--existing` instead.

The change is a single `hide = true` addition to the clap arg attribute.

Release Notes:

- N/A

Release Notes:

- N/A

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>

When reopening a thread that is already visible in the agent panel,
`open_thread` could recreate the session instead of reusing the existing
visible thread. That left the UI holding a thread whose backend session
could be closed out from under it.

This change routes `AgentPanel::open_thread` through
`load_agent_thread`, which already handles the right behavior for
existing sessions:
- reuse the active thread when it already matches
- promote a retained thread when it matches
- only load when the session is not already present

The regression coverage is now a focused behavioral test at the
`AgentPanel::open_thread` boundary that verifies reopening an
already-visible session keeps the thread usable.

cc @bennetbo

Release Notes:

- Fixed reopening an already-visible agent thread so it reuses the
existing session instead of creating a broken duplicate.

- Change design a bit so that the separation between projects is clearer
- Add ability to cmd-click to focus most recent workspace
- Make hover and collapse/expand interactions unconditional, enabled by
adding a "No threads yet" empty state
- Improved keyboard nav by making cmd-n create a new thread in the
currently focused group


https://github.com/user-attachments/assets/e9cde153-d3f1-4945-9e45-db1597637a44

Release Notes:

- Agent: Improved the threads sidebar header by making the separation
between projects more distinct.