This is necessary to remove some `util` dependencies from crates, as
well as better sharing for our projects. This also includes the WIP
AbsPath abstraction as well as some bug fixes from internal tooling.
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
Closes#55925Closes#59094
When a Python project is opened and a toolchain is selected, Zed
stores/persists this choice in the database. When the project is
reopened later, that saved toolchain should be automatically selected.
However, this recovery mechanism requires the associated worktree to be
loaded first.
In local development, the worktrees are loaded first, after which the
toolchain is restored and activated:
https://github.com/zed-industries/zed/blob/4083fc859288fdbc11a94c0b19c359350098e252/crates/workspace/src/workspace.rs#L1916-L1955
But in remote development, the toolchain restoration block runs at the
very beginning of initialization, before any worktrees are loaded:
https://github.com/zed-industries/zed/blob/4083fc859288fdbc11a94c0b19c359350098e252/crates/workspace/src/workspace.rs#L10381-L10413
Because the worktree does not exist yet when the toolchain is processed,
`find_worktree` always returns `None`, and the saved toolchain is never
activated. This breaks toolchain persistence for remote workspaces.
## Solution
Move the toolchain activation block in `open_remote_project_inner` so it
runs after the worktrees have been loaded, matching the sequence used in
`new_local`. This ensures the worktree is present in the project when we
perform the ID lookup and activate the toolchain.
## Testing
Tested locally with a Windows client connecting to a remote Linux
server, verifying that the previously selected virtual environment is
correctly restored upon reopening the workspace.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed Python virtual environments not automatically restoring when
reopening a remote development workspace.
Co-authored-by: Lukas Wirth <lukas@zed.dev>
VS Code has a command called "Toggle Maximize Editor Group" (`Cmd+K
Cmd+M`) that expands the active editor pane to fill the entire center
area, hiding editor split panes, but leaving docks and panels visible.
Zed's existing `ToggleZoom` hides all panels and is closer to VS Code's
Zen Mode. VS Code has both — it would be useful for Zed to as well.
This is particularly useful for people working on laptops, and has been
raised before (#32715, #4897, #32860), but the addition of the project
panel alongside the agent panel has made it more relevant. I work with
the editor split vertically, but with the project and agent panels both
visible, on a laptop screen there's really only room for a single editor
pane. This command makes it easy to switch to and from that mode.
**Behavior:**
- New action: `workspace::ToggleEditorZoom`
- When activated, the active editor pane expands to fill 100% of the
center/editor area, hiding sibling split panes
- Docks and panels remain visible and unaffected
- Toggling again restores the previous split layout
- If `ToggleZoom` is active, it unzooms first, then maximizes
Here's a demo:
https://github.com/user-attachments/assets/fcf6748e-6c45-4c4a-8d9f-f106c6cd58ea
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#32715
Release Notes:
- Added `workspace::ToggleEditorZoom` action to maximize the active
editor pane within the center area while keeping panels visible.
Fixes menu a11y, and adds landmarks with `F6`-navigation.
Also fixes a GPUI bug, and adds debug actions for dumping a11y tree
info.
Since `F6` was already in use by the pause debugger keybind, also
tightens up the debugger keybind context so they require an active
debugger session. When there is one active, `F6` stays as pause
debugger. `ctrl-F6` always works to go to the next landmark.
Also adds an "accessible mode" setting. Currently, this only controls
whether we show all menus all the time, but I suspect it will expand
significantly in the future.
Also adds `.aria_keyshortcuts()` API, but it's not wired up within
accesskit adapters, so is not yet reported to screen readers.
---
Release Notes:
- N/A or Added/Fixed/Improved ...
This allows us to build powerful and flexible Input and TextArea
components
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: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Resolves https://github.com/zed-industries/zed/issues/55600
This diff fixes `pane::ReopenClosedItem` getting stuck when the
closed-item stack contains entries that cannot be reopened, such as
Project Search, untitled buffers, or Default Settings. Previously,
`Workspace::navigate_history_impl` would pop the newest closed entry and
stop if that item was no longer present in the pane and had no path
recorded for reopening. That made `cmd- shift-t` appear to do nothing
until enough attempts had consumed those unreopenable entries.
With this change, closed-item navigation keeps scanning when it
encounters an entry that cannot be activated or reopened by path. This
preserves the current path-based reopening behavior for normal files,
while avoiding no-op shortcuts caused by non-file items in the closed
stack.
This made me wonder whether or not we'd eventually want full reopen
support for non-traditional items like Project Search or bundled
settings editors. Supporting that properly would require storing
item-specific restoration state, such as search query/options for
Project Search or a bundled-file descriptor for Default Settings, and
teaching closed-item navigation how to recreate those items from that
state. Something definitely out of scope for this PR.
| Before | After |
| --- | --- |
| <video
src="https://github.com/user-attachments/assets/c7044423-4531-4857-84f2-4e9651826c6a"
controls width="500" title="Before"></video> | <video
src="https://github.com/user-attachments/assets/c89dcefb-1796-4cdf-bb21-f165145e678e"
controls width="500" title="After"></video> |
Release Notes:
- Fixed reopening closed tabs getting stuck on closed items that cannot
be reopened.
Summary
- Track whether a worktree root is itself a linked Git worktree.
- Use that metadata when computing project group keys so bare checkout
worktrees group under the repository identity path.
- Propagate the metadata through remote worktree protocols and add
local/remote regression coverage.
Background
Bare checkout layouts can place linked worktrees under the repository
identity directory, e.g. `/monty/.bare` with worktrees like
`/monty/feature-a`. We were treating those linked worktree paths as
separate project identities, which caused the sidebar to move agent
threads under the active worktree instead of the shared repository
group.
We also exclude adding this to collab intentionally, we can open a
different PR for that if we need to.
Closes#59910
Closes AI-431
Test Plan
- `cargo fmt --package project --package worktree --package
remote_server --package workspace --package collab --package proto`
- `git --no-pager diff --check`
- `cargo test -p project test_project_group_key -- --nocapture`
- `cargo test -p remote_server test_remote_root_repo_common_dir --
--nocapture`
- `cargo test -p worktree remote_worktree -- --nocapture`
- `cargo test -p workspace
test_remote_project_root_dir_changes_update_groups -- --nocapture`
- `cargo check -p collab`
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
Release Notes:
- Fixed agent thread/sidebar grouping for Git worktrees backed by bare
checkouts.
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
To reproduce:
1. Open a git project with the agent sidebar, ideally with no other
threads in the sidebar.
2. Create a thread in a new git worktree and type into it without
sending.
3. While still in that worktree workspace, hit New Thread. The parked
draft must now be the last activatable entry in the sidebar.
4. Hover the parked draft → click Discard Draft
5. 💥
Release Notes:
- Fixed a panic when discarding a draft workspace.
# Objective
Zed supports trusting all projects under a given directory. However,
when a local Windows client connects to a remote Linux server, the trust
scope input rejects valid directories with the error "Enter an absolute
folder path", even though the path is correct.
<img width="681" height="374" alt="image"
src="https://github.com/user-attachments/assets/87f084fb-1213-4594-96cb-3de81f4789aa"
/>
The root cause is in the `validate_trust_scope` function:
https://github.com/zed-industries/zed/blob/970e93e88132737477e0ab5dc618faa29d1040ff/crates/workspace/src/security_modal.rs#L497-L519
which uses `Path::is_absolute()` to check whether the entered path is
absolute. On Windows, this method only considers paths with a drive
letter as absolute, so Unix-style paths like `/home/user` are never
recognized. When doing cross-platform remote development, valid trust
scopes are incorrectly rejected.
## Solution
The `util::paths` crate already provides a helper for this situation:
https://github.com/zed-industries/zed/blob/970e93e88132737477e0ab5dc618faa29d1040ff/crates/util/src/paths.rs#L575-L586
The fix
- Adds a `path_style: PathStyle` parameter to `validate_trust_scope` and
uses `util::paths::is_absolute()` in place of `Path::is_absolute()`.
- The call site in `edited_trust_scope` retrieves the path style from
the worktree store, which already tracks whether a connection is local
or remote and the remote host's path convention.
The associated unit tests were updated for the new function signature.
## Testing
Built and tested locally; `cargo test -p workspace` passed.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed the "Folder to trust" input rejecting valid folder paths when
connecting to a remote host that uses a different path style than the
local machine.
This makes sure that the behaviour of the CLI matches that of the UI.
In Zed itself we always open a new window (e.g. when clicking on Open
Project in new window in the recent projects picker), but in the CLI we
where re-using existing windows even when specifying
"cli_default_open_behavior": "new_window".
This caused confusion, so this PR ensures that we always open a new
window, even if that folder is already open. We still focus the active
window in the case where the path is a subpath of a project that is
already open.
Can be tested with
```
cd crates/cli
cargo run -- --zed ../../target/debug/zed somefolder
```
Release Notes:
- cli: Ensure `zed somefolder` always opens a new window, even when
`cli_default_open_behavior` is set to `new_window` and the project is
already open
Closes#39159
## Summary
• resolve remote terminal path candidates outside known worktrees
through `Project::resolve_abs_path`
• keep the local filesystem backed resolution path unchanged
• preserve the existing preference for direct in-worktree matches when
the terminal cwd is already inside a worktree
• add regression coverage for both absolute and cwd-relative remote
external paths
### Why
The hyperlink parser wasn't the bug. `terminal_path_like_target` already
knew how to parse these paths. The actual problem was that remote
projects had no equivalent of the local background existence check.
After worktree lookup failed, remote projects only fell back to worktree
traversal, so cmd-click on `/tmp/a.txt` in an SSH remote terminal
no-op'd.
The project layer already has remote absolute-path resolution via
`Project::resolve_abs_path`, so the right fix is to use that existing
path for remote candidates instead of pretending remote projects cannot
resolve paths outside their worktrees.
## Verification
• `cargo test -p terminal_view terminal_path_like_target --quiet`
• `cargo test -p terminal_view --quiet`
## Manual
• Verified locally on my MBP w/ a stateless Zed build using SSH to self
(`localhost`)
• Opened `/tmp/zed-39159-project` as a remote project
• Confirmed cmd-click opens `/tmp/zed-39159-external/a.txt`
• Confirmed cmd-click opens `zed-39159-external/b.txt` from `cwd=/tmp`
• Confirmed in-worktree paths still open correctly
• Confirmed nonexistent external paths do not open bogus targets
Release Notes:
- Fixed remote terminal path opening so cmd-click can open files outside
the project worktree.
# Objective
Telemetry events generated **on a remote server** were silently dropped,
and all remote telemetry that *was* reported got attributed to the local
client's OS.
## Solution
This PR makes server-originated events flow to the telemetry pipeline
and attributes them to the actual remote host (connection type, OS,
version, architecture), plus adds a transport-agnostic connection event.
## Additional Notes
This removes the "SSH Project Opened" event and replaces it with a
"Remote Connection Established" one that has more structured info and is
also more useful in where it gets invoked.
The server unconditionally sends back telemetry to the client, the
client is then responsible for filtering on whether telemetry is enabled
by the user or not as the server does not have knowledge of those
settings itself.
Release Notes:
- N/A
Adds support for named bookmarks while preserving the existing unnamed
bookmark workflow.
Main changes:
- Keeps `ToggleBookmark` as the quick unnamed bookmark action.
- Adds `ToggleNamedBookmark`, which prompts for a bookmark name when
adding a new bookmark and removes an existing bookmark on the same line,
including unnamed ones.
- Adds `EditBookmark` support for renaming existing bookmarks.
- Persists bookmark names in workspace storage.
- Adds a project bookmarks picker that supports filtering by bookmark
name and relative path, with highlighted matches.
- Updates bookmark storage and tests to carry bookmark names through
serialization, restoration, navigation, and project-level listing.
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
Video
toggle:
https://github.com/user-attachments/assets/a725b9cf-ac37-4ebc-85cc-ee820452c043
rename:
https://github.com/user-attachments/assets/a6d0d0c1-511b-4fb7-ae5d-22c55d1a075f
Release Notes:
- Add named bookmark support
---------
Co-authored-by: Yara 🏳️⚧️ <git@yara.blue>
This allows one to "bless" arbitrary parent path, without making
assumptions about the structure of the project storage on users machine.
## Testing
- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- When opening a project for the first time, you can now auto-trust
arbitrary parent path; previously Zed offered affordance for
auto-trusting a parent of a parent only.
The work introduced in https://github.com/zed-industries/zed/pull/54496
updated the `command_aliases` schema, adding support for auto-completion
action names when editing the settings file. However, it didn't take
into consideration the case where the user is simply creating an alias
to an arbitrary string.
These changes introduce a new `CommandAliasTarget` newtype for which the
json schema is either a registered action name, from `ActionName` or any
arbitrary string, as those are supported by the `command_aliases`
setting.
Updating the `ActionName` schema to accept any arbitrary string would
break the guarantees we have on the keymap binding schema, so that's why
a new schema was introduced.
Lastly, trying to set `CommandAliasTarget::json_schema` to a simply
`anyOf` with either the registered action name or a string that is not a
registered action name, like shown below, broke deprecation warnings,
hence why we're still doing the approach of only building
`CommandAliasTarget` at runtime.
```json
{
"anyOf": [
{ "$ref": "#/$defs/ActionName" },
{ "type": "string", "not": {
"$ref": "#/$defs/ActionName"
}},
]
}
```
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 validation of `command_aliases` setting to avoid showing
warnings when aliasing to an arbitrary string
For the extension devs:
Adds a `RebuildDevExtension` action that triggers a rebuild of an
installed dev extension.
- If no dev extensions are installed, shows an error notification.
- If exactly one dev extension is installed, rebuilds it immediately.
- If multiple dev extensions are installed, opens a fuzzy picker to
select which one to rebuild.
Makes it easy for devs to trigger a rebuild with a keymap once an action
is defined with this PR.
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)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- Added `RebuildDevExtension` action to rebuild installed dev extensions
from the command palette
<img width="675" height="310" alt="Screenshot 2026-04-29 at 1 49 54 AM"
src="https://github.com/user-attachments/assets/dbf618f7-f590-40aa-bc5c-580eea9f0001"
/>
<img width="623" height="329" alt="Screenshot 2026-04-29 at 1 50 16 AM"
src="https://github.com/user-attachments/assets/b4bb4131-924f-442b-8351-528a87698399"
/>
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
# Objective
Fixes#54882:
When selecting a project group that has a remote host (SSH, WSL, Docker)
from the window project picker, or when closing/removing a workspace
with a remote neighbor group, the code was unconditionally calling
find_or_create_local_workspace. This created a local project with the
remote server's paths, producing a 'ghost' project where language
servers and file watchers fail trying to access paths that don't exist
locally.
## Solution
Three locations fixed:
1. RecentProjectsDelegate::confirm (recent_projects.rs) - window project
picker selecting a ProjectGroup entry. Routes to
find_or_create_workspace with connect_with_modal for remote hosts.
2. MultiWorkspace::close_workspace (multi_workspace.rs) - closing a
workspace whose neighboring group is remote. Falls through to the empty
workspace fallback instead of creating a ghost project.
3. MultiWorkspace::remove_project_group (multi_workspace.rs) - removing
a project group whose neighbor is remote. Same fallback.
All three detect remoteness via key.host().is_some() and skip
find_or_create_local_workspace when set.
Includes regression tests for all three paths using mock remote
connections.
## Testing
- Not yet tested with a custom build
- Unit tests added
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
---
Release Notes:
- Fixed ghost project appearing in the window project picker and sidebar
when switching between local and remote projects.
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Release Notes:
- Fixed an issue where the close button could overflow within a
workspace error popup.
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Replaces the verbose struct-literal construction of `gpui::BoxShadow`
with a builder API:
- `BoxShadow::new(offset_x, offset_y, color)` takes the required fields,
with arguments ordered to match the CSS `box-shadow` property.
- `.blur_radius(_)`, `.spread_radius(_)`, and `.inset()` set the
optional fields.
All in-tree call sites are migrated, including the Tailwind-style
`shadow_xs`..`shadow_2xl` helpers in `gpui_macros`, the `ElevationIndex`
shadows in `ui`, and various widgets across `editor`, `workspace`,
`agent_ui`, and `ai_onboarding`. The fields on `BoxShadow` remain
public, so external code using struct-literal construction continues to
work.
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
## Summary
Exposes the existing recursive pane-size reset as a command-palette
action, so it can be invoked outside of vim mode.
The center pane grid's sizes can already be evened out by
double-clicking a divider, or via `vim::ResetPaneSizes` (`ctrl-w =`)
when vim mode is on, but there is no general action for it — so users
not in vim mode have no discoverable way to undo a drifted split layout
in one step.
## How it works
`workspace::ResetPaneSizes` (palette: "workspace: reset pane sizes")
calls the existing `Workspace::reset_pane_sizes`, which resets every
`PaneAxis` in the center pane group to equal flexes, recursing into
nested splits. The split structure is preserved — no panes are added,
removed, or rearranged, only their sizes are equalized. This is the same
path the vim `ctrl-w =` binding and the divider double-click already
use.
## Out of scope
- Docks (left/right/bottom panels) — they keep their existing `Reset
Active Dock Size` / `Reset Open Docks Size` actions.
- The terminal panel's internal splits — it is a separate panel, not
part of the center pane group.
- No default keybinding (palette-only); vim users keep `ctrl-w =`.
## Testing
Added `test_reset_pane_sizes`: builds a nested split (a horizontal axis
of three panes whose last child is a vertical split), skews every axis's
flexes, dispatches the action, and asserts every axis returns to uniform
sizes.
Release Notes:
- Added a `workspace: reset pane sizes` command that equalizes the sizes
of all panes in the center group
## Context
This follow-up was inspired by Christopher’s suggestion in the review
comment on #58483: long filenames should truncate in the middle so both
the beginning and the suffix/extension remain visible.
Previously, very long filenames in picker rows could still be clipped or
end-truncated, making files with shared prefixes hard to distinguish.
This adds middle-truncation support to GPUI text overflow and applies it
to filename-focused picker surfaces: the tab switcher and the Ctrl-P
file finder. Normal editor tab bar behavior remains unchanged and
continues to use the existing title length cap.
## How to Review
- **`crates/gpui/src/style.rs`, `crates/gpui/src/styled.rs`,
`crates/gpui/src/elements/text.rs`,
`crates/gpui/src/text_system/line_wrapper.rs`**: Adds
`TextOverflow::TruncateMiddle`, wires it through text layout, and
implements middle truncation while preserving valid text runs. Very
narrow widths now show the truncation affix instead of falling back to
the abruptly clipped original text.
- **`crates/ui/src/components/label/label_like.rs`,
`crates/ui/src/components/label/label.rs`,
`crates/ui/src/components/label/highlighted_label.rs`**: Exposes middle
truncation through the shared label components.
- **`crates/workspace/src/item.rs`, `crates/editor/src/items.rs`,
`crates/workspace/src/pane.rs`,
`crates/tab_switcher/src/tab_switcher.rs`**: Adds an explicit
tab-content opt-in for middle truncation. The tab switcher enables it,
while the normal tab bar and dragged tabs keep their existing behavior.
- **`crates/file_finder/src/file_finder.rs`**: Applies middle truncation
to Ctrl-P file finder filenames and lets the path shrink from the start
so long paths do not hide important filename suffixes.
Manual test before change :
[Screencast from 2026-06-10
22-59-28.webm](https://github.com/user-attachments/assets/5e032646-a48c-45f2-8fe2-0424507fd576)
Manual test after change :
[Screencast from 2026-06-10
22-54-48.webm](https://github.com/user-attachments/assets/4b9253da-f169-4ed1-bdd5-ee71dcf49a83)
## 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:
- Improved long filename truncation in the tab switcher and file finder
so extensions remain visible.
Adds `default_open_behavior` which let's users control which action
should be the default (add to existing window/open a new window)
TODO:
- [x] Use sensible icon (not `IconName::Screen`) when
`default_open_behavior` is set to `new_window`
- [x] Tweak wording for actions in recent projects menu
<img width="420" height="59" alt="image"
src="https://github.com/user-attachments/assets/69ef112e-bf20-4dd1-9994-e4442266ef87"
/>
Release Notes:
- Added `default_open_behavior` which controls which action (add to
sidebar/open in new window) should be the default when selecting a
project from the recent projects menu
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior (visual difference only)
- [x] Performance impact has been considered and is acceptable
I was unable to find a specific issue or PR that mentions this.
As Linux installations always use built-in prompts and ignore the `Use
System Prompts` setting (as far as I'm aware) all users using Zed (with
client-side decorations) are affected. The darkened prompt backdrop was
drawn across the full window boundary, including the transparent
decoration/shadow inset, causing it to overlap.
This PR fixes the backdrop to respect the client-side decoration inset
and only applies rounded corners on non-tiled edges. Tiled edges remain
flush, matching the rest of the client-side window decoration behavior.
I've verified it works on Wayland, X11 and causes no regressions on
macOS or Windows (with `Use System Prompts` off).
Notice the screenshots below on a white background showing the before
and after, where the faint overlap is shown broken and fixed (sorry if
you have to squint).
Before:
After:
Release Notes:
- Fixed prompt darkened backdrop/background rendering outside
client-decorated window boundaries on Linux.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](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#58543 and extends to all instances of "Ok" button labels.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This migrates the `Workspace::show_error` method to take a generic type
that implements `WorkspaceError` instead. That trait containts methods
to show a proper error message but most importantly means to help with
providing actions given certain errors.
The intention for this is rather easy: Whenever we show an error to the
user on the workspace level, that error should be
- actionable to a degree, even if that is only opening logs or whatnot
- show a message that is understandable to the user
- for not-too-critical errors, should hide after a certain delay and not
force the user to dismiss it using their mouse.
For now, there exist trait implementations for string error types and
anyhow errors. The long term goal here is to get rid of these altogether
and migrate everything to be strongly typed and especially actionable
instead.
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] 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: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
In a multi-workspace window several workspaces share one platform
window. Switching the active workspace did not update the window title
or edited indicator, and background workspaces could clobber the active
workspace's title via their still-live project/item event subscriptions.
Track the active workspace id in a shared Rc<Cell<EntityId>> owned by
the MultiWorkspace and read by each member workspace, so a workspace
only writes the shared window's title/edited state when it is the active
one. The newly active workspace re-applies its title and edited
indicator on activation. We use a Rc-cell here to avoid double lease
issues as we cannot tell whether we are inside a running MultiWorkspace
lease or not in the given codepaths.
Release Notes:
- Fixed the window title not updating when switching between workspaces
in a multi-workspace window
---------
Co-authored-by: Eric Holk <eric@theincredibleholk.org>
Closes https://github.com/zed-industries/zed/issues/54840
There are likely more places we can use this new workspace function in,
but these are the known ones to me right now
Release Notes:
- Fixed file hyperlinks in the agent panel not opening files when
clicked
Co-authored-by: saberoueslati <saberoueslati12@gmail.com>
On quit, the handler activates every workspace in each window to surface
save prompts. Activating re-serializes the multi-workspace state, so the
persisted active_workspace_id ended up pointing at whichever workspace
was iterated last rather than the one the user had focused. On the next
launch the wrong (or empty) workspace was restored as active, even
though all projects still appeared in Open Recent.
Re-activate the originally-focused workspace after the close-prompt loop
(and on the cancel-quit path) so it is the one serialized as active.
Also harden read_serialized_multi_workspaces to prefer a workspace with
paths over a scratch/empty one when the persisted active workspace can't
be matched.
Release Notes:
- Fixed a workspace restoration issue where zed would restore a window
with none of its projects opened by default
TypeId is effectively already a hash, so re-hashing it with fxhash is
unnecessary.
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
## Context
The tab switcher was truncating file names at the same 24-character
limit (`MAX_TAB_TITLE_LEN`) used by the narrow tab bar. This made files
that share a long common prefix, like `test_cpp_file_long_name.h` and
`test_cpp_file_long_name.cpp`, render identically, with both becoming
`test_cpp_file_long_name.…`.
The fix adds a `max_title_len: Option<usize>` field to
`TabContentParams`. When `None` (the default, used by the tab bar),
`Editor::tab_content` falls back to `MAX_TAB_TITLE_LEN` as before. The
tab switcher passes `Some(usize::MAX)`, which skips truncation entirely
and lets the UI container constrain the displayed text naturally.
Closes#58461
## How to Review
- **`crates/workspace/src/item.rs`** : Adds `max_title_len:
Option<usize>` to `TabContentParams`. Derives `Default` so `None` is the
zero-cost default; two existing struct literals in `pane.rs` that
couldn't use `..Default::default()` were updated to be explicit.
- **`crates/editor/src/items.rs`** : In `Editor::tab_content`, both the
title label and the description path now use
`params.max_title_len.unwrap_or(MAX_TAB_TITLE_LEN)` instead of the
hardcoded constant.
- **`crates/workspace/src/pane.rs`** : Two `TabContentParams` struct
literals updated to include `max_title_len: None`, preserving the
existing 24-char tab bar behaviour.
- **`crates/tab_switcher/src/tab_switcher.rs`** : Sets `max_title_len:
Some(usize::MAX)` in `render_match`, opting the tab switcher out of
truncation.
Video of the manual test below :
Used the same names of the files in the issue but also longer ones to
showcase the behavior in different file lengths :
[Screencast from 2026-06-04
00-08-02.webm](https://github.com/user-attachments/assets/5f388257-2f3d-494c-ab50-bf46496dbd38)
I'm obviously open to discussing this further specially the new
truncation behavior of the file with the longest name in the manual
test.
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the UI/UX checklist
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed tab switcher truncating long file names, making files with a
shared prefix indistinguishable
Adds two built-in agent tools, behind the staff-only
`create-thread-tool` feature flag, that let the agent spawn independent
sibling threads:
- **`create_thread`** creates a new thread with a title and initial
prompt. It runs on the user's behalf and shows up in the agent sidebar
like a thread the user started themselves, but it runs in the background
— the active thread is never interrupted — and it does **not** report
results back to the caller. (Use `spawn_agent` when you want the
results.)
- **`list_agents_and_models`** enumerates the configured agents and, for
the native agent, the available models, so the agent can pick a
cheaper/faster model for bulk work. The motivating stress test was
"spawn 100 threads that each write a haiku, using Haiku instead of
Opus."
By default the sibling shares the parent's project and worktree. If
`use_new_worktree` is set, `create_thread` instead opens a new
background workspace backed by fresh linked git worktrees of the
project's repos — the same flow you get from the worktree picker's
"Create worktree" — and starts the thread there. The new workspace opens
as a background tab so it doesn't pull you away from what you're doing.
A few notes on the design:
- The `agent` crate can't depend on the UI, so there's a
`SiblingThreadHost` trait that `agent_ui::AgentPanel` implements and
installs on the `NativeAgent`. Tool calls in a native-agent thread route
through it.
- Sibling threads go through the same `create_agent_thread` →
`ConversationView` path as the user-facing "new thread" action, so
eviction, persistence, and sidebar rendering match user-created threads.
- An explicit `agent`/`model` override doesn't clobber the panel's
selected agent or the last-used-agent preference — those are snapshotted
and restored around the call.
- The worktree path reuses the existing "Create worktree" machinery
rather than reimplementing it; the agent flow just opens the new
workspace in the background instead of activating it.
A couple of things I left out or want to call out:
- There's no tool to operate on an already-created sibling by session
id. The success payload deliberately omits it, since the session is
populated asynchronously and nothing consumes it yet.
- When a project has multiple worktrees that are linked worktrees of the
*same* underlying repo, they collapse into a single new worktree (they
resolve to the same target path). The tool returns a warning in that
case rather than failing — and this also fixes a latent collision the
manual "Create worktree" flow would hit in the same situation.
Release Notes:
- N/A
## Summary
- Add a regression test covering reopening an already-open remote
workspace root inside the reused workspace path
- Use the resolved worktree entry instead of the local filesystem when
`Workspace::open_paths` decides whether a reused path is a directory
- This fixes the follow-on case where reopening an already-open SSH
workspace root could show `Error: opening project path ...` because the
remote root was being treated like a local file open
I kept this fix in `Workspace::open_paths` rather than adding another
remote-specific branch higher up, because the bug was specifically in
the generic reused-workspace directory check.
## Testing
- `cargo test -p recent_projects
test_reopen_existing_remote_root_treats_root_as_directory --
--nocapture`
- `cargo test -p recent_projects
test_reuse_existing_remote_workspace_window_with_tilde_path --
--nocapture`
- `cargo test -p recent_projects
test_reuse_existing_remote_workspace_window -- --nocapture`
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] Tests cover the new/changed behaviour
- [x] Performance impact has been considered and is acceptable
Related to #30829
Release Notes:
- Fixed reopening an already-open SSH workspace root showing an `opening
project path` error instead of treating the root as a directory
This primarily
- requires components to have a description as well as a preview
(especially having no preview makes no sense)
- implements some basic previews where missing
- adds a scrollbar to the preview navigation
with a sadly large diff due to reformatting (less indentation 🎉 ), but
very little changes at its core.
Release Notes:
- N/A
This PR adds support for inset shadows in the box shadow through the
`inset: true` field. It includes support for both the macOS as well WGSL
shaders. For now, there is no immediate application of it in Zed, so
nothing should change in the app.
<img width="600" alt="Screenshot 2026-05-25 at 8 46@2x"
src="https://github.com/user-attachments/assets/db564a6b-8af5-491a-a573-17c060a3647c"
/>
Run the example above with `cargo run --example shadow -p gpui`.
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Fixed width mode wouldn't reliably take the sidebar width into account
when laying out the content of the agent panel. This fixes it
Release Notes:
- N/A or Added/Fixed/Improved ...
When the agent mentions a file path inside `backticks` (e.g. ``
`src/main.rs` `` or `` `src/main.rs:42` ``), the rendered code span now
becomes a clickable link in the agent panel. Clicking opens the
referenced file in the workspace, jumping to the right line and column
when present.
## How it works
- **Shared path resolution.** Extracted `OpenTarget` and the
workspace/worktree resolution logic out of
`terminal_view::terminal_path_like_target` into a new
`workspace::path_link` module so both the terminal and the agent panel
can use the same code. Includes a `sanitize_path_text` helper ported
from the terminal's URL/punctuation handling. Pure refactor — terminal
behavior is unchanged.
- **`markdown` crate hook.** Added
`MarkdownElement::on_code_span_link(callback)`. When the callback
returns `Some(url)` for a given code span's contents, the existing
`push_link` machinery wires up cmd-hover, hit testing, and the existing
`on_url_click` callback. When it returns `None`, the code span renders
as before. The hook is opt-in, so `markdown` stays workspace-agnostic.
- **Agent panel wiring.** `render_agent_markdown` constructs an
`AgentCodeSpanResolver` that snapshots the project's visible worktree
entries plus their file extensions. `try_resolve` does a cheap
synchronous heuristic check (path must contain `/`/`\` or end in an
extension present in the workspace, can't be a URL, can't be all digits,
etc.) and then looks the candidate up in the per-worktree
`HashSet<Arc<RelPath>>`. On a hit it returns a `MentionUri::File` or
`MentionUri::Selection` URI, which the existing `thread_view::open_link`
already knows how to open at the right line.
## Edge cases handled
- Code spans inside fenced code blocks stay plain (gated on
`builder.code_block_stack.is_empty()`, matching how regular markdown
links behave).
- Trailing prose punctuation (`` `src/main.rs.` ``) is stripped before
lookup.
- Identifiers like `` `String` ``, `` `await` ``, `` `npm run dev` ``
stay plain — they don't pass the path-like heuristic.
- Cross-platform path separators handled via the per-worktree
`PathStyle`.
## Tests
- `crates/markdown` — unit test asserting code spans become links when
the callback returns `Some`, and stay plain when it doesn't.
- `crates/agent_ui` — unit test for `AgentCodeSpanResolver::try_resolve`
covering hits with and without a `:line` suffix, misses, identifiers,
and trailing punctuation.
- Existing `terminal_view` tests cover the moved resolution code
(unchanged behavior).
## Notes
- There's currently a temporary `log::info!` in
`AgentCodeSpanResolver::try_resolve` that reports per-call worktree-walk
timing and a cumulative total. Kept in for now to verify the feature
isn't being called excessively during streaming renders. Can be removed
before merge.
- Resolution is sync-only against worktree entries; absolute paths
outside the workspace are not resolved (would require an async re-render
path).
Closes AI-277
Release Notes:
- Made file paths in `backticks` clickable in the agent panel; clicking
opens the referenced file at the given line when present.
Closes AI-298
This PR adds the first step towards allowing to reorganize the threads
sidebar. Drag and drop should be supported in the near future, maybe
even replacing this entirely:
<img width="700" alt="Screenshot 2026-05-21 at 6 44@2x"
src="https://github.com/user-attachments/assets/db420466-2323-474b-ba41-17eb4da2cf84"
/>
Release Notes:
- Sidebar: Added the ability to reorder projects by moving them up and
down through the ellipsis menu.
This PR adds an icon button to Markdown codeblocks allowing to control
whether or not the content should be wrapped. At the moment, this is not
hard-persisted, meaning that 1) wrapping text in one codeblock instance
does not affect others, and 2) the codeblock will be reset every time
its view is recreated (i.e., closing and opening a Markdown Preview tab,
an agent thread, etc.). I intentionally kept it simple just to see how
it feels, but we can certainly consider a setting later on.
| Unwrapping | Wrapping |
|--------|--------|
| <img width="782" height="658" alt="Screenshot 2026-05-20 at 5 09
2@2x"
src="https://github.com/user-attachments/assets/e9151e91-32ba-40d4-9c65-535dec309291"
/> | <img width="736" height="604" alt="Screenshot 2026-05-20 at 5
09@2x"
src="https://github.com/user-attachments/assets/157db6fd-ec4c-4c96-b44a-119273cbd0f9"
/> |
Release Notes:
- Added the ability to control codeblock content wrapping through the
UI.
Auto watch's lifespan should be tied to that of the call and it should
not be assumed the user wants to have this on indefinitely (until app
restart), as it's more of a niche feature. This PR disables it when the
user leaves a call.
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
Follow up to https://github.com/zed-industries/zed/pull/57056 — This PR
ensures we're refreshing the security modal so that it consumes the
trust given to the main worktree when creating a new linked (Git)
worktree.
Release Notes:
- N/A
Closes TRA-150
This PR makes the restricted mode more obvious by:
- Immediately opening the restricted mode modal upon opening an
untrusted project
- Disabling dismissing the modal on escape or click away to force
choosing one of the two options (and avoid accidentally staying in
restricted mode by simply dismissing it)
- Showing the LSP button but with communication about language servers
being disabled for untrusted projects
- Showing a banner in the project settings with the same communication
The motivation for this change was that we tried to be minimal with how
we communicate a project is untrusted, but it was so minimal that people
were confused as to why language servers and other settings weren't
working. It was easy to miss the title bar button, for some reason. The
changes in this PR makes it so acting on this decision (trust or not a
project) is mandatory in order to even start to interact with the
project. I appreciate changes here are more aggressive, but I think it's
better to make you think about this decision vs. letting you be confused
as to why you don't see LS completions or formatting.
Release Notes:
- Made restricted mode more obvious, demanding immediate action when
opening an untrusted project.
Lukas Wirth