4aad57fd1f002f9feeea2b7fb6229ccbcd576cb1
39399
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Ben Kunkle
|
4aad57fd1f |
workspace: Return the created workspace when opening a remote project (#62028)
# Objective Fix the `fallback workspace must not be one of the workspaces being removed` panic. Fixes FR-148 Fixes ZED-AKR Fixes ZED-97M # Solution The remote path of `find_or_create_workspace` opened a project, then returned the window's *active* workspace instead of the one it created. The open awaits toolchain loading and item restoration, and a save prompt from a concurrent workspace removal can re-activate a workspace being removed during that wait; the stale return value then trips the assert in `MultiWorkspace::remove`. Return the created workspace from `open_remote_project_inner` and use it at the call sites instead of re-reading the active workspace after the await. # Testing Added `test_find_or_create_workspace_returns_the_created_remote_workspace`: opens a mock remote project and re-activates the previous workspace mid-open (standing in for the save prompt), then asserts the open returns the workspace it created. Verified it fails against the pre-fix behavior. ## 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 --- Release Notes: - Fixed a crash when a workspace was removed while a remote project was opening in the same window. |
||
|
Ben Kunkle
|
b5764581d2 |
project: Refresh MCP settings after worktree changes (#62026)
# Objective Prevent MCP servers from remaining unavailable when a project is created before its first worktree. ## Solution Refresh effective MCP settings before maintaining servers after worktree additions or removals. ## 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 --- Release Notes: - Agent: Fixed MCP servers missing from new project threads after a worktree opens. |
||
|
Ben Kunkle
|
41c0f28bf9 |
project: Fix branch diff with older servers (#62134)
# Objective Prevent branch diffs from failing when a server does not recognize worktree diff requests. ## Solution Send `HEAD` as a valid committed-only fallback for servers that ignore `includes_worktree`. ## 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: - N/A |
||
|
Joseph T. Lyons
|
7759e9f93a |
feature_flags: Remove unused auto-watch flag (#62122)
Release Notes: - N/A |
||
|
feeiyu
|
b036368ce9 |
Align agent sidebar headers with title bar (#62079)
# Objective Fix the Agent sidebar header being two pixels lower than the title bar on Linux. This only affects Linux with client-side decorations: the main title bar uses a negative one-pixel margin to overlap the client-drawn window border, while the sidebar previously used a positive one-pixel margin on every platform. Fixes #53739 ## Solution Match the sidebar header spacing to the window decoration mode: - Use `-1px` top margin for client-side decorations. - Preserve the existing spacing for server-side decorations. - Apply the fix to both the thread list and archive headers. ## Testing - Manually tested on Linux. This only affects Linux because its client-side window decorations require the adjusted title bar offset. ## 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)](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)](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 ## Showcase After this change： [2026-08-02 18-20-19.webm](https://github.com/user-attachments/assets/1ef13ff2-2036-442b-8bcc-74ebeb8436c7) --- Release Notes: - Fixed misaligned Agent sidebar headers on Linux. |
||
|
John Tur
|
be8c6f9fb3 |
Tweak renderer resource management (#62069)
Factoring some changes out of https://github.com/zed-industries/zed/pull/61461: - On Metal and wgpu, bulk-upload instance buffers at the start of the frame rather than uploading chunks as we draw them. The depth buffer patch needs this architecture since all opaque quads in the scene are painted before anything else. This also lets us get rid of the awkward retry loop when the GPU buffer is too small for the scene. - On Windows, use a constant buffer for the instance offset rather than creating SRVs with different `FirstElement`s. `FirstElement` is buggy on some vendors' drivers, and reusing the SRV object should reduce D3D runtime overhead. - Misc. refactoring: remove redundant parameters, deduplicate code, create fewer bind groups on wgpu, etc. Fixes https://github.com/zed-industries/zed/issues/49588 Fixes https://github.com/zed-industries/zed/issues/59192 Release Notes: - Fixed an issue where UI elements would flicker on some Windows devices. |
||
|
Dino
|
2d9680fc02 |
feature_flags: Enable project panel undo/redo on all release channels (#62104)
# Objective Ensure that the Project Panel's Undo/Redo system is enabled in Stable before this week's release, as it's enabled on all release channels except stable. Since, as far as I'm aware, there hasn't been any issue reported regarding last week's Preview release, I'm going to go ahead and enable this in stable. ## Solution Update `feature_flags::flags::ProjectPanelUndoRedoFeatureFlag::enabled_for_all` to `true`, we no longer need to match on the release channel. ## Testing N/A ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content 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 - [ ] Performance impact has been considered and is acceptable --- Release Notes: - N/A |
||
|
Cameron Mcloughlin
|
849ec5898a |
agent: Fix NTFS warning breaking terminal tool when WSL not available (#62049)
There is a bug on main and preview causes all terminal tool calls to fail when: - on windows - sandboxing is not available (i.e. no WSL) - sandboxing is enabled in settings (the default) - the "warn windows-drive grants" setting is enabled (the default) Example error: <img width="352" height="79" alt="image" src="https://github.com/user-attachments/assets/24affbec-f086-40eb-8827-ad74aabc6167" /> This PR fixes it by making sure we only show the check at the right time --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Evan VinciguerraandClaude Opus 4.8
|
35cb7558a9 |
editor: Add configurable git gutter width setting (#61304)
## Summary
Adds a `gutter.git_gutter_width` setting that lets users pin the width,
in pixels, of the git diff hunk indicators in the editor gutter.
Previously the width was always derived from the buffer font size
(`floor(0.275 * line_height)`), which can render too thin or too thick
depending on font family and display pixel density. This adds an
optional override:
```json
{
"gutter": {
"git_gutter_width": 6
}
}
```
When the setting is unset (`null`, the default), the width continues to
scale with the buffer font size, so existing behavior is unchanged.
## Motivation
Requested in [discussion
#27799](https://github.com/zed-industries/zed/discussions/27799). Beyond
the width itself, participants noted the git hunk hit target is
extremely narrow and hard to click. Because the hunk hitbox reuses the
painted strip bounds, setting a wider `git_gutter_width` also widens the
clickable area, addressing that complaint with the same setting.
## Changes
- `settings_content`: new `git_gutter_width: Option<f32>` on
`GutterContent`.
- `editor`: mirror field on the resolved `Gutter`; `gutter_strip_width`
now consults the setting, and the value flows through `diff_hunk_bounds`
(including the deleted-hunk marker) and the gutter layout anchors for
line numbers, folds, and expand toggles.
- `settings` (VS Code import): pass through the new field.
- Docs + `default.json`: document the new setting.
## Notes
- `Eq` was dropped from `GutterContent`/`Gutter` because `f32` is not
`Eq`; this matches the existing `EditorSettingsContent` convention for
float-bearing settings.
Release Notes:
- Added a `gutter.git_gutter_width` setting to configure the width of
git diff indicators in the editor gutter
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Nathan Sobo
|
8886dcb0d4 |
gpui: Expose threaded dispatcher for tests (#62096)
Some tests need real OS threading and timers rather than the deterministic, single-threaded behavior of `TestDispatcher`. The existing multithreaded dispatcher provides those production-like scheduling semantics, but it is named and gated as a benchmark-only facility, which unnecessarily pulls in Criterion and histogram dependencies. This renames `BenchDispatcher` to `ThreadedDispatcher` and exposes it through GPUI's `test-support` feature. Benchmark contexts continue using the same dispatcher, while Criterion and benchmark reporting remain isolated behind the `bench` feature. ### Testing - `cargo check -p gpui --features test-support` - `cargo check -p gpui --features bench` - `cargo nextest run -p gpui 'threaded_dispatcher::tests'` - `cargo fmt --all --check` Release Notes: - N/A |
||
|
Piotr Osiewicz
|
538a4a267b |
Add wezel scenario for an incremental editor build (#62016)
# Objective This PR codifies one of the scenarios I've used to measure build health of a codebase via [Wezel](https://wezel.build), a tool I've built for that purpose. ## Solution `wezel exp run incremental-editor` ## 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: - [ ] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] 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 - [ ] 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: - N/A or Added/Fixed/Improved ... |
||
|
Vlad GaevskyandDanilo Leal
|
66ed3027b8 |
agent_ui: Show the agent panel's full screen button as toggled (#62041)
The agent panel's full screen button and a pane's zoom button drive the same mechanism — both emit `PanelEvent::ZoomIn`/`ZoomOut`, and `Workspace::zoomed` holds a single entry, so at most one of them is active at a time. The pane's button reflects that state: it is rendered with `toggle_state(zoomed)`, so it is visibly active while zoomed (`crates/workspace/src/pane.rs`). The agent panel's button only swapped its icon, so while the panel was zoomed the button still looked like an inactive control. This makes the agent panel's button use the same `toggle_state` + `selected_icon` pattern as the pane's. Behavior is unchanged; the button now looks active while full screen is on. The element id is now stable across both states instead of changing with the icon. Unrelated to this change, but worth mentioning since it is the same button: the two controls also disagree on wording. The pane calls it "Zoom In"/"Zoom Out", the agent panel "Enable/Disable Full Screen". Because `Workspace::zoomed` is a single slot, activating any other panel's zoom drops the agent panel back out of full screen — which reads as surprising under the "full screen" name and unsurprising under "zoom". Happy to align the wording in a follow-up if you'd like, but I left it alone here since it is a naming call rather than a fix. Release Notes: - Fixed the agent panel's full screen button not appearing active while full screen was enabled. --------- Co-authored-by: Danilo Leal <daniloleal09@gmail.com> |
||
|
|
ce6f3af5f7 |
remote: Fix incorrect arguments passed to SCP & SFTP (#56080)
All arguments passed to the initial remote connection command were initially blindly passed to `scp` or `sftp` command line. This is an issue with some arguments like "-X" or "-Y" that either does not exist, or have a different semantic. This PR introduces a denylist of arguments before crafting the command to execute. Reproduce steps: 1. Create a new remote connection, e.g `ssh -X user@192.168.1.1` 2. Expect the upload of the remote server to fail with a message saying that '-X' is not a valid argument for `ssh` / `sftp` depending on your setup. 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: - Fixed wrong arguments that may be passed to scp or sftp command when pushing remote files. --------- Co-authored-by: Marshall Bowers <git@maxdeviant.com> Co-authored-by: Lukas Wirth <lukas@zed.dev> |
||
|
Kirill Bulatov
|
90d024b88a |
Fix the display point out of range panic due to wrong coordinate space used (#62055)
Closes ZED-AKV Closes ZED-ANB Follow-up to https://github.com/zed-industries/zed/pull/61153 The original PR mixed up the coordinate spaces, and the newly added methods used buffer rows (as the existing code did before that PR), but the new code uses `FoldMap` which expects a tab row instead of the buffer one. Release Notes: - Fixed a panic when selections are added by tab-expanded column |
||
|
Kirill Bulatov
|
21f16f7b5b |
Speed up cargo build -p zed compilation (#62059)
Splits the crate graph.
Before, the compilation graph: `editor → picker_preview → search →
project_panel → open_path_prompt → recent_projects → title_bar →
collab_ui → zed`
After, the compilation graph: `editor → picker_preview → search →
agent_ui → sidebar → zed`
With sccache disabled and project fully built, `touch
crates/editor/src/editor.rs` and `cargo build -p zed` took time
Before (
|
||
|
Mikayla MakiandBen Kunkle
|
5e1fd392f6 |
git: Add diff_base setting for showing changes since the default branch (#61501)
# Objective Let git indicators — the editor gutter, file colors, and `git::Diff` — show all changes on the current branch relative to its merge base with the default branch, instead of only uncommitted changes. Supersedes #60398; thanks to @samuelcolvin for the original implementation and motivation. Closes FR-135 ## Solution - New `git.diff_base` setting (`"head"` | `"default_branch"`), applied live and toggleable per session from the editor controls menu ("Diff Against Default Branch"). - Statuses come from a real merge-base-to-worktree tree diff (`git diff --merge-base`), so local edits that revert branch changes correctly show as unchanged. - `GitStore` shares one `DiffBufferList` per repository with the Branch Diff view; `repo_snapshots` and `project_path_git_status` keep returning index/worktree truth, while display surfaces use separate `display_*` APIs. - `BufferDiff` now records what its base is (`DiffBaseKind`); hunks whose base isn't HEAD are read-only in the gutter — stage/restore buttons and keybindings are inert, so committed work can't be silently rewritten. - `git::Diff` follows the setting; new `git::DiffHead` always opens the HEAD diff; `git::BranchDiff` is renamed `git::DiffBranch` (deprecated alias kept). Tradeoffs / known limitations: - Hunk-level staging is unavailable while in `default_branch` mode (whole-file staging via the git panel still works). Staging just the uncommitted sub-ranges of a branch hunk is a follow-up. - Remote hosts running an older server ignore the new `GetTreeDiff.includes_worktree` proto field and degrade to committed-changes-only branch diffs. - Repositories with no resolvable default branch fall back to HEAD-relative behavior; a failed first resolution retries on the next branch-list change. ## Testing - Real-git-repo tests for the merge-base-to-worktree diff's edge cases: files recreated after index deletion, committed deletions recreated on disk, and symlinks. - GPUI tests for status semantics (a branch change reverted on disk shows clean), `git::Diff` routing, live setting changes, and read-only hunk enforcement (restore/stage leave buffer and index untouched). ## 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 --- Release Notes: - Git: Added a `git.diff_base` setting (`"head"` or `"default_branch"`) that makes the editor gutter, file colors, and diff view show all changes on the current branch since its merge base with the default branch, instead of only uncommitted changes. --------- Co-authored-by: Ben Kunkle <ben@zed.dev> |
||
|
Sathwik Chirivelli
|
5e03f2d387 |
solo_diff_view: Hide multibuffer controls in solo diffs (#61998)
# Objective Remove the redundant expand/collapse-all-files control from solo diff views. A solo diff represents one file, so the multibuffer-wide control is not applicable and duplicates the per-file full-file/changes-only toggle. ## Solution Treat searchable items that intentionally hide their underlying splittable editor as ineligible for the generic multibuffer expand/collapse control. This keeps search bound to the focused side of a split diff while preserving the existing expand/collapse controls in Project Diff, Branch Diff, staged/unstaged diffs, Commit View, and other regular multibuffer views. ## Testing - `cargo -q test -p search test_uses_primary_left_when_in_multi_buffer -- --nocapture` - `cargo -q test -p search buffer_search -- --nocapture` (26 passed) - `git diff --check` - Manually verified the solo diff no longer shows the expand/collapse-all-files control and that the full-file/changes-only toggle remains available. Reviewers can open a file from Project Diff, use Option+Enter to switch between Project Diff and Solo Diff, and verify search follows the focused side in split diff mode. ## 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 ## Showcase Solo diff views now retain the full-file/changes-only toggle without showing the unrelated expand/collapse-all-files control. <details> <summary>Click to view showcase</summary> <img width="1120" height="724" alt="Screenshot 2026-07-31 at 6 44 50 PM" src="https://github.com/user-attachments/assets/58519dda-d77a-410e-bbe2-0aebfac93fbd" /> </details> --- Release Notes: - Fixed a redundant expand/collapse-all-files control appearing in solo diff views. |
||
|
Lena
|
98f39bfcca |
Duplicate Bot: Improve candidate retrieval (v6) (#62011)
Release Notes: - N/A |
||
|
Tai Nguyen
|
f56ff65c92 |
editor: Stop opt-left on the right side of punctuation between words (#61916)
Closes #61884 Release Notes: - Fixed Option+Left stopping to the left of punctuation between words Video URL: https://files.catbox.moe/8d5g2t.mp4 |
||
|
Danilo Leal
|
f99da3a491 |
Add dedicated icon for the GPT Subscription provider (#62009)
Just to make it easier to differentiate when using an OpenAI model coming from the GPT Subscription vs. from the API key. Release Notes: - N/A |
||
|
Tim VermeulenandMrSubidubi
|
779c35d256 |
acp_thread: Disable Git's configured pager in agent terminals (#61732)
Applies the same fix as #43277 to Zed's native agent, which indeed fixes this issue for me locally (which I could only reproduce when specifically telling the agent to not use `--no-pager`, FWIW). Closes #42943 ## 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 hang when the Zed Agent runs a `git` command with a pager configured. --------- Co-authored-by: MrSubidubi <finn@zed.dev> |
||
|
Matei Opreaanddino
|
2318f45f4c |
multi_workspace: Allow closing of currently selected project (#60602)
# Objective When working across multiple projects open in the same window, closing the **currently selected** project requried a two-step flow: switch to another project first then close the one that you initially wanted to. The project's close button was hidden on the active project, so the only way to remove the project was to navigate away first. ## Solution Always render the close button in the project picker, including for the active project. Closing the active project now removes it and switches to a neighboring project automatically. This worked well for local projects but broke for remote ones. For any remote neighbor it actually fell through to an empty workspace. There are 3 cases now: 1. Activate the neighbor's already open workspace when one exists (now either if its local or remote) 2. Load the neighbor through the host-aware **find_or_create_workspace** which connects and opens a remote neighbor when it isn't already open 3. Fallback to an empty workspace only when no neighbor remains ## 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 - [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 > 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> https://github.com/user-attachments/assets/6e1d1968-702a-4f13-9442-5e90fe7ae9f9 </details> --- Release Notes: - Improved the project switcher to allow closing the currently selected project, switching to a neighboring project (local or remote) automatically. --------- Co-authored-by: dino <dinojoaocosta@gmail.com> |
||
|
Lena
|
59cb143caf |
Fix triage queue board matching every open issue (#61993)
Our date filter used two qualifiers ("created:>START created:<=END"),
which isn't valid range syntax, so GitHub ignored it and returned every
open issue. Use a single "created:START..END" range. Also fix the window
math, which was a business day too recent and excluded its start day.
Release Notes:
- N/A
|
||
|
CarboFish
|
1ac840ab2f |
workspace: Fix dropping Windows files onto a WSL remote (#57146)
Dropping a local Windows file (e.g. `E:\foo\bar.md`) onto a Zed window connected to a WSL remote previously forwarded the path verbatim. On the remote Linux side `E:\foo\bar.md` isn't absolute, so it got joined with the worktree CWD, producing nonsense like `/home/user/E:\foo\bar.md` and a "failed to canonicalize root path" error from the worktree scanner. 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 #49915 before: <img width="1343" height="331" alt="before" src="https://github.com/user-attachments/assets/193cfbf6-d07e-4c5f-b941-75e4a0c62345" /> after: <img width="1181" height="288" alt="after" src="https://github.com/user-attachments/assets/7ad56e13-3723-4b48-aa3d-59eca6038a7f" /> Release Notes: - Fixed dragging local Windows files onto a Zed window connected to a WSL remote. |
||
|
Erik W
|
c7aea6cbbd |
gpui_linux: Add wl_data_source support for outbound drags on Wayland (#61947)
# Objective - Enable drag'n'drop from Zed in Wayland. - Partially addresses #13186 - Related to #58161, #61940 ## Solution - Implement wl_data_source support for outbound drags on Wayland ## Testing Tested on KDE Wayland, kwin 6.7.3 I dragged files to Firefox, to other Zed windows and into Dolphin. ## 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 Can try to record if requested Release Notes: - Added support for dragging files from the Project Panel to external Linux Wayland apps. |
||
|
Kirill Bulatov
|
56cf49bc1a |
Fix parameter colors for gruvbox themes (#61983)
Left before, right after: <img width="1728" height="370" alt="image" src="https://github.com/user-attachments/assets/3229ba26-18e6-415e-8df3-25fa5fea43aa" /> Closes https://github.com/zed-industries/zed/issues/61976 https://github.com/zed-industries/zed/pull/61134 picked a wrong color for `variable.parameter` that exactly matched `variable.special` and caused visual conflicts. Instead, use `variable` for such colors. Release Notes: - Fixed Gruvbox parameter colors |
||
|
Mohammad Adnaan
|
9c7a5c9485 |
docs: Document the --existing CLI option (#61979)
# Objective Fixes #61730. Document the `-e`, `--existing` CLI option, which was missing from the CLI reference. ## Solution - Added documentation for the `-e`, `--existing` CLI option. - Added a usage example. - Updated the default behavior note to include `-e`. ## Testing - Built the documentation locally using `mdbook`. - Verified that the new section renders correctly in the CLI Reference page. - Confirmed the example and updated default behavior note appear as expected. ## Self-Review Checklist - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [ ] The content adheres to Zed's UI standards (Not applicable) - [ ] Tests cover the new/changed behavior (Documentation change only) - [x] Performance impact has been considered and is acceptable ## Showcase The CLI Reference now includes documentation for the `-e`, `--existing` option. <details> <summary>Documentation Preview</summary> <img width="935" height="539" alt="Screenshot 2026-07-31 151714" src="https://github.com/user-attachments/assets/c2e4ad05-a961-4fe1-8c22-5e3a474e96ca" /> </details> --- Release Notes: - Improved CLI documentation by adding the missing `--existing` option. |
||
|
Ben Kunkle
|
4f047acc17 |
edit_prediction: Prevent v4 cursor marker leaks (#61957)
# Objective Prevent V4 cursor markers from appearing in edit prediction previews or accepted edits. ## Solution Replace the cursor marker with an internal sentinel before sub-line diffing, so matching source text cannot reconstruct the marker. ## 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 --- Release Notes: - N/A |
||
|
Yassen Damyanov
|
b209000d28 |
Make Install script reject 32-bit Linux architectures (#61919)
# Objective Prevent successful installations on 32-bit Linux architectures where the `zed` binary will **fail to execute** post-installation. Rather, fail at installation time with a proper verdict. `script/install.sh` maps `uname -m` onto the two architectures Zed publishes builds for. Two of the matchers named 32-bit userlands and mapped them onto a 64-bit tarball: - `linux-armhf` mapped to `aarch64` - `linux-i686*` mapped to `x86_64` Neither can execute the binary it selected. Tested on i386 Debian Trixie container: the installer downloaded, unpacked, symlinked and reported success, and the failure surfaced later as an exec error -- see [Showcase](##showcase). Thus the installer's correct behavior would be to reject the 32-bit architecture and terminate with an "unsupported" verdict. ## Solution Remove the case-statement-based mapping of `linux-armhf` to `aarch64`, and of `linux-i686*` to `x86_64`. ## Testing Tested in isolation, simulating supported and unsupported platforms, and supported and unsupported architectures: | Platform | `uname -m` | Outcome | | --- | --- | --- | | Linux | `x86_64` | ✅ Installed — resolves to `x86_64`, symlink created | | Linux | `i386` | ❌ Unsupported — `i386` doesn't match glob `x86*` (no case handles plain i386 anyway | | Linux | `i686` | ❌ Unsupported — same reason | | Linux | `aarch64` | ✅ Installed — resolves to `aarch64` | | Linux | `arm64` | ✅ Installed — resolves to `aarch64` | | Linux | `armv7l` | ❌ Unsupported — no 32-bit ARM case | | Linux | `riscv64` | ❌ Unsupported | | Darwin | `arm64` | ✅ Installed — resolves to `aarch64`, copied to real `/Applications/Zed.app`, symlink created; | | Darwin | `x86_64` | ✅ Installed — resolves to `x86_64`, copied to real `/Applications/Zed.app`, symlink created | | Darwin | `i386` | ❌ Unsupported — no case for macOS 32-bit | | FreeBSD | `x86_64` | ❌ Unsupported platform - expected | This is all correct behavior. Successful installations are expected to work. Unsupported architectures are detected and rejected as unsupported during installation. ## Showcase ```plaintext ~# file /usr/bin/dash # a sample executable showing the 32-bit arch /usr/bin/dash: ELF 32-bit LSB pie executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=7e2e8652114c8c2ae595b6f78798716a9ba07671, for GNU/Linux 3.2.0, stripped ~# file .local/zed.app/bin/zed .local/zed.app/bin/zed: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e550eeb1d97f0cdac2460de672bfa36e9e3f6e25, not stripped ~# .local/zed.app/bin/zed bash: .local/zed.app/bin/zed: cannot execute: required file not found # It cannot find ELF 64-bit interpreter /lib64/ld-linux-x86-64.so.2 -- this is # a 32-bit container on a 64-bit host. On a genuine 32-bit host it would fail with: # `Exec format error`. ``` ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Locally conducted tests cover the new/changed behavior --- Release Notes: - N/A |
||
|
Tai Nguyen
|
a5615f092d |
Reset panel saved size when default_size changes (#61855)
Closes #59235 When a panel's `default_size` changes (e.g. `git_panel.default_width` is edited in settings), the persisted per-workspace size is now cleared so the new default takes effect immediately. Previously the saved dragged size took precedence forever, making `default_width` effectively useless after the first manual resize. This fix is at the Dock level (`crates/workspace/src/dock.rs`), so it applies to all panels — Git Panel, Project Panel, Terminal Panel, etc. Release Notes: - Fixed panel `default_width` setting being ignored after manually resizing the panel https://github.com/user-attachments/assets/97ef69b2-387f-4e29-bc4c-0f336f24eb0b |
||
|
Tim Vermeulen
|
0b3621db47 |
terminal_view: Fix inline terminal clipping its first line of output (#61939)
Fixes #53518: | before | after | | --- | --- | | <img width="790" height="458" alt="before" src="https://github.com/user-attachments/assets/2314fb13-6782-4397-a022-0252c82bf7b9" /> | <img width="790" height="458" alt="after" src="https://github.com/user-attachments/assets/1058970c-ae0a-4a9f-8f14-84b810ddaba4" /> | `TerminalBounds::line_height` floors `height / line_height`, so `TerminalElement::request_layout` does the inverse logic to calculate the height for inline terminals with `displayed_lines * line_height`, but intermediate rounding in `to_taffy` could break this. Fixed by rounding up to the next integer device pixel in `TerminalElement::request_layout`. ## 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 --- Release Notes: - Fixed the first line of terminal output sometimes being hidden in the agent panel. |
||
|
Rabindra Kumar Meher
|
864ff0ba3f |
Run string-form dev container lifecycle commands in /bin/sh -c (#60792)
# Objective Fixes #60228. String-form dev container lifecycle commands are currently executed by splitting the command on spaces and running the first token directly. This means shell features such as variable expansion, pipes, redirection, and command chaining do not work. According to the Dev Container specification, string-form lifecycle commands should run through `/bin/sh -c`, while array-form commands should continue to execute directly. ## Solution - Added `LifecycleScript::shell_command()` to wrap string-form commands in `/bin/sh -c`. - Updated string deserialization to use `shell_command()` instead of splitting on spaces. - Kept array-form commands unchanged. ## Testing - Ran `cargo test -p dev_container` (107 tests passed). - Added a regression test to verify string-form commands run through `/bin/sh -c`. - Added a regression test to verify array-form commands still execute directly. - Updated the existing deserialization tests to match the expected behavior. ## 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 - [x] Tests cover the new behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed string-form dev container lifecycle commands so they execute through `/bin/sh -c` as required by the Dev Container specification. |
||
|
9rum
|
58a3c0fa0e |
docs: Fix mismatch of default dock position setting in project panel (#61971)
# Objective Fixes #56277, the document-source mismatch of the default dock position setting in project panel. I also have found that the visual customization guide has the same issue, so this PR fixes it too. ## Solution I have updated the corresponding markdown files. ## Testing I have tested the updated documents by rendering them in my local. ## 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 --- Release Notes: - N/A |
||
|
AidanVandLukas Wirth
|
5f180e06dc |
editor: Add multiple_selections key context (#60018)
# Objective - I would like to have the Vim command `z z` do different actions depending on if I have multiple selections. If I only have one selection I want `z z` to center my only selection (current behavior); however, if I have multiple selections I would like `z z` to run `editor::OpenSelectionsInMultibuffer`. This PR does not add this specific functionality (happy to be convinced otherwise), but it does let users add this type of functionality. ## Solution - Add a new key context field that is active only when there are multiple selections. ## Testing - Changes are quite small. A test on this would really be testing other parts of the code-base more than this change. ## 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 https://github.com/user-attachments/assets/2559e218-d6fa-492a-949b-f4ab8b880f28 This allows us to add something like the following to the `keymap.json`: ```json { "context": "VimControl && !menu && multiple_selections", "bindings": { "z z": "editor::OpenSelectionsInMultibuffer", }, }, ``` which lets us change the functionality of a keystroke based on if there are multiple selections. This video has the following keystroke sequence: `z z` (Center the cursor normally) `5 g l` (Select the 5 next occurrences of the word under the cursor) `z z` (Open selections in multi-buffer) (Previously `z z` in this context would just center the last selection) https://github.com/user-attachments/assets/a0dc1813-5420-4cda-a1ec-99e6681680e7 --- Release Notes: - Added `multiple_selections` keystroke context Co-authored-by: Lukas Wirth <lukas@zed.dev> |
||
|
aetos
|
2ec2997789 |
Honor window preference when opening remote projects (#61048)
# Objective Fixes #60873. `projects::OpenRemote` has two handling paths: - The remote-project picker handles `from_existing_connection: false`. - The active remote workspace handles `from_existing_connection: true`. The existing-connection path ignored the action’s `create_new_window` field. Consequently, selecting another project from an active SSH workspace always created a new OS window—even when: - the action explicitly specified `create_new_window: false`, or - `create_new_window` was omitted and `default_open_behavior` was set to `"existing_window"`. The expected behavior is: | `create_new_window` | `default_open_behavior` | Result | |---|---|---| | `true` | Any value | Open a new window | | `false` | Any value | Reuse the current window | | Not specified | `"new_window"` | Open a new window | | Not specified | `"existing_window"` | Reuse the current window | ## Root cause The `from_existing_connection: true` action handler forwarded the selected paths to `open_new_ssh_project_from_project` without reading `action.create_new_window`. That helper then called `open_remote_project` with: ```rust OpenOptions { workspace_matching: WorkspaceMatching::None, ..Default::default() } ``` This left `OpenOptions::requesting_window` as `None`. The remote-opening path interprets a missing requesting window as a request to create a new window, so the action always opened one regardless of the action payload or workspace setting. ## Solution The existing-connection action handler now resolves `create_new_window` before starting the asynchronous open operation. When the action does not provide an explicit value, it uses the same `WorkspaceSettings::default_open_behavior` fallback as the normal project-opening path: ```rust let create_new_window = action.create_new_window.unwrap_or_else(|| { matches!( WorkspaceSettings::get_global(cx).default_open_behavior, DefaultOpenBehavior::NewWindow ) }); ``` The resolved boolean is passed to `open_new_ssh_project_from_project`. The helper translates that policy into the existing `OpenOptions` API: - When `create_new_window` is `true`, `requesting_window` remains `None`. - When it is `false`, `requesting_window` is set to the current `MultiWorkspace` window handle. The existing `WorkspaceMatching::None` behavior is intentionally preserved. This PR changes only which OS window hosts the opened remote workspace; it does not change workspace matching, path selection, connection handling, telemetry, or error behavior. ### Why resolve the setting in the action handler? The action handler is where the explicit action value and the workspace setting are both available. Resolving the option there also matches the neighboring local and remote project-opening flows. Passing the resolved boolean keeps the helper’s input aligned with the user-facing policy while allowing the helper to translate it into the lower-level `requesting_window` representation. ### Why not change `open_remote_project`? `open_remote_project` is shared by several remote-opening flows. Inferring an active window inside that function would change the semantics of unrelated callers that deliberately omit `requesting_window` to create a new window. Keeping the change in the existing-connection action path limits the behavioral change to the reported issue. ### Dependency impact The regression test needs a real mock remote workspace so that it exercises the same action registration and remote-client checks as the application. The following test-support development dependencies were enabled for the `zed` crate: - `fs`, for `FakeFs` - `remote`, for the mock `RemoteClient` - `remote_server`, for `HeadlessProject` These are development-only dependencies and do not change Zed’s runtime dependency graph. The `Cargo.lock` change records `remote_server` as a dependency of the `zed` package under the test configuration. ## Testing Added an end-to-end GPUI regression test: ```text test_open_remote_from_existing_connection_reuses_window ``` The test: 1. Creates a fake remote filesystem with two project directories. 2. Starts a headless mock remote server. 3. Opens the initial project through `open_remote_project`. 4. Verifies that exactly one window exists. 5. Transitions the mock client to `ServerNotRunning`. 6. Injects `/other-project` as the path-prompt result. 7. Dispatches: ```rust zed_actions::OpenRemote { from_existing_connection: true, create_new_window: Some(false), } ``` 8. Verifies that the application still has exactly one window. 9. Answers the expected failed-reconnection prompt with `Cancel`, allowing the detached action task to terminate cleanly. The unavailable-server step keeps the test focused on window routing. It avoids requiring a second successful mock SSH lifecycle while still exercising the real action handler, path prompt, remote workspace, helper, and `open_remote_project` entry point. Before the production change, the test failed with: ```text create_new_window: false should reuse the current window left: 2 right: 1 ``` After the change, the test passes. ### Verification performed Focused regression test: ```sh cargo test -p zed test_open_remote_from_existing_connection_reuses_window ``` Result: ```text 1 passed; 0 failed ``` GPUI scheduler sweep: ```sh ITERATIONS=20 cargo test -q -p zed test_open_remote_from_existing_connection_reuses_window -- --nocapture ``` Result: ```text Seeds 0 through 19 passed ``` Complete `zed` test target, run serially because several existing tests share global session state: ```sh cargo test -q -p zed -- --test-threads=1 ``` Result: ```text 74 passed; 0 failed; 1 ignored ``` Formatting: ```sh cargo fmt -p zed --check ``` Repository-prescribed Clippy check: ```sh ./script/clippy -p zed ``` This ran the release, all-targets, all-features configuration with warnings denied and completed successfully. The change and test were run on Fedora Linux. ### Manual verification This can also be verified interactively: 1. Connect to a project over SSH. 2. Bind or dispatch: ```json [ "projects::OpenRemote", { "from_existing_connection": true, "create_new_window": false } ] ``` 3. Select another directory on the connected host. 4. Confirm that the project opens in the current Zed window. 5. Repeat with `create_new_window: true` and confirm that a new window is created. 6. Omit `create_new_window` and confirm that the result follows `default_open_behavior`. No screenshot is included because this does not change rendered UI; it changes which window contains the opened remote workspace. ## Scope and impact - No unsafe code was added. - No remote protocol or transport behavior changed. - No settings schema changed. - No action schema changed. - No user-facing strings changed. - No new runtime dependencies were introduced. - The added work is limited to resolving one optional boolean and downcasting the current window handle when reuse is requested. - The window-handle lookup occurs only when this action is dispatched and has no meaningful performance impact. ## 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 --- Release Notes: - Fixed opening a project from an existing remote connection to respect the configured window behavior. |
||
|
Xin Zhao
|
2610332077 |
path: Normalize Windows paths independently of the host platform (#61374)
# Objective Zed's `PathStyle` is designed to handle paths across platforms. Its behavior should depend only on the selected path style, not on the platform where Zed is running. This is essential for remote development, where the local and remote platforms may differ. While fixing bugs involving Windows remote targets, I found that `PathStyle::normalize` does not behave consistently across host platforms. For `PathStyle::Windows`, it delegates to `crate::normalize_path`: https://github.com/zed-industries/zed/blob/914e1c9873b6b85bfeedc5b58e8270885bdd532e/crates/path/src/path.rs#L237-L263 That function uses `Path::components()`, which interprets paths according to the host platform. As a result, when Zed runs on a Unix-like system and connects to a Windows remote, something maybe wrong here. `PathStyle::normalize` should instead interpret paths according to the selected `PathStyle`, independently of the host platform. ## Solution Implement Windows path normalization directly in `PathStyle::normalize` without relying on `std::path::Path` parsing. The new implementation: - Recognizes drive-letter, rooted, relative, and UNC paths. - Treats both `\` and `/` as Windows path separators. - Resolves `.` and `..` components lexically. - Uses `\` as the normalized Windows path separator. - Produces the same result regardless of the host platform. ## Testing New test is added and tested with `cargo test -p util`, this test would fail on current main branch. ## 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 --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Alan P John
|
b7de76402c |
dev_containers: Preserve Compose entrypoints by default (#61897)
# Objective Docker Compose-based dev containers do not run their image or service entrypoint when `overrideCommand` is omitted. The Dev Container specification defaults `overrideCommand` to `true` for image and Dockerfile configurations, but to `false` for Docker Compose configurations. Zed treated an omitted value as `true` for every build type and generated a Compose entrypoint override, preventing the configured entrypoint from running. Fixes #60456 ## Solution Resolve the effective value of `overrideCommand` based on the dev container build type: - Preserve the existing default of `true` for image and Dockerfile configurations. - Use the specification default of `false` for Docker Compose configurations. - Continue to give an explicitly configured `overrideCommand` precedence over the default. Use the resolved value when deciding whether to generate Zed's entrypoint script. Add regression tests covering the defaults for image, Dockerfile, and Docker Compose configurations, along with explicit overrides in both directions. ## Testing Automated testing: - `cargo fmt --check` - `cargo test -p dev_container override_command --lib` - `./script/clippy -p dev_container --lib` - `cargo build -p zed` All three focused tests pass, and Clippy passes with warnings denied. Manually tested on Linux using the Docker Compose reproduction from #60456: 1. Built an Alpine image with an `ENTRYPOINT` that writes `/tmp/entrypoint-marker.log`. 2. Configured the Compose service with `command: sleep infinity`. 3. Omitted `overrideCommand` from `devcontainer.json`. 4. Opened the project in the current stable release and confirmed that the marker file was not created. 5. Opened a fresh container using this branch's development build and confirmed that: - `/tmp/entrypoint-marker.log` was created. - The Compose `sleep infinity` command remained active. Testing was performed with Docker Compose on Linux. I did not manually test this change on macOS or Windows, but the default resolution is platform-independent. ## 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 ### Before Current stable Zed replaces the Compose entrypoint when `overrideCommand` is omitted, so `/tmp/entrypoint-marker.log` is not created. Zed 1.12.0 <img width="2827" height="1709" alt="image" src="https://github.com/user-attachments/assets/04dadd66-5e95-4ea8-8183-6156793f0654" /> ### After The development build preserves the Compose entrypoint by default. The marker file is created and the Compose service command remains active. <img width="2827" height="1709" alt="image" src="https://github.com/user-attachments/assets/cdd9808b-7867-42d8-bec7-97af9c170b0a" /> --- Release Notes: - Fixed Docker Compose dev containers not running their configured entrypoints by default. |
||
|
Mayank Verma
|
e99616cdd4 |
gpui: Add resizable and minimizable state to Window (#61473)
### Objective PR #36859 made native macOS and Windows controls respect `is_resizable` and `is_minimizable`, but custom window decorations cannot access those values from `Window`. Linux custom controls and client-side resize interactions remain active, macOS custom titlebar double-click does not check either option and custom Windows caption buttons still appear enabled even though the backend blocks their actions. ### Solution Expose `is_resizable` and `is_minimizable` on `Window`. Use them to disable custom window controls and titlebar actions and omit client-side resize cursors and hitboxes for non-resizable windows. ## 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) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A |
||
|
Ben Kunkle
|
ae394f3d47 |
edit_prediction: Disable jumps for staff (#61960)
# Objective - Stop enabling edit prediction jumps by default for Zed staff. ## Solution - Disable the staff default for the `edit_prediction_jumps` feature flag. ## 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: - N/A |
||
|
Ibrahim Khan
|
b6b2148bd0 |
grammars: Highlight class instantiations in JavaScript, TypeScript, and TSX (#61890)
## Why JavaScript, TypeScript, and TSX class declarations were captured as `type.class`, but the same class names in `new` expressions were captured as the generic `type`. Themes that define a distinct style for `type.class` therefore rendered declarations and instantiations inconsistently. ## What Update the three highlight queries so constructor identifiers in `new` expressions use `type.class`. Themes without a dedicated `type.class` style continue to fall back to their existing `type` style. Add a regression test that loads the real JavaScript, TypeScript, and TSX grammars with distinct colors for `type` and `type.class`, then verifies that both the declaration and instantiation receive the class-specific highlight. ## Testing - `cargo test -p languages test_class_instantiation_highlighting` - `cargo test -p languages` - `cargo fmt --all -- --check` - `./script/clippy -p languages` ## References Closes #55943 Release Notes: - Fixed inconsistent class instantiation highlighting in JavaScript, TypeScript, and TSX. |
||
|
Mikayla Maki
|
9a631e5461 |
Fix path's license (#61955)
Release Notes: - N/A |
||
|
Nitin Krishna MucheliandClaude Sonnet 5
|
5638be1fe5 |
language_models: Stop logging noisy ChatGPT Subscription auth errors on startup (#61949)
# Objective
- On every startup (and whenever the agent panel initializes), Zed
authenticates all visible language model providers in the background to
populate the model selector. For every other credential-based provider,
"not signed in yet" is reported as
`AuthenticateError::CredentialsNotFound`, which is explicitly treated as
expected and not logged. The ChatGPT Subscription provider instead
returned a generic `anyhow` error, so it logged an `ERROR [agent] Failed
to authenticate provider: ChatGPT Subscription: ...` on every launch,
even for users who have never configured or used it.
- Fixes #60237
> **AI disclosure:** I used Claude (Anthropic) to investigate this
error, write the fix, and draft this PR description, based on a `Failed
to authenticate provider: ChatGPT Subscription` line I noticed in my own
Zed logs. I reviewed the diff and the reasoning below, ran the tests
myself, and understand and take responsibility for the change, per Zed's
[AI
Policy](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#ai-policy).
## Solution
- `OpenAiSubscribedProvider::authenticate` now returns
`AuthenticateError::CredentialsNotFound` (instead of a generic
`anyhow!(...)` wrapped into `AuthenticateError::Other`) when no ChatGPT
credentials are found after the initial load, matching how every sibling
provider (e.g. Anthropic's `ApiKeyState::load_if_needed`) signals "not
configured."
- The user-facing sign-in prompt in the settings UI
(`SUBSCRIPTION_DESCRIPTION`) is unchanged — this only affects the
background authentication sweep's error handling, not what the user sees
when opening provider settings.
## Testing
- `cargo test -p language_models -p openai_subscribed` — all 108 tests
pass, including
`provider::openai_subscribed::tests::test_authenticate_awaits_initial_load`,
which exercises this exact code path.
- `cargo check -p language_models` — compiles cleanly.
- Manually confirmed the log line no longer appears when starting Zed
without ChatGPT Subscription configured.
## 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
Before (this fix): startup log ends with a spurious `ERROR` even though
ChatGPT Subscription was never configured.
```
2026-07-30T21:37:46+05:30 INFO [zed] ========== starting zed version 1.15.0+dev.b90735ff317b83c4ec62ab3d73dd5385bbe1624d, sha b90735f ==========
2026-07-30T21:37:48+05:30 WARN [zed::reliability::hang_detection] debug build, only reporting hangs longer then 5s
2026-07-30T21:37:48+05:30 WARN [zed::reliability] Minidump endpoint not set
2026-07-30T21:37:48+05:30 INFO [zed::reliability] memory usage: resident 98 MiB, virtual 426367 MiB
2026-07-30T21:37:48+05:30 INFO [extension_host] extensions updated. loading 2, reloading 0, unloading 0
2026-07-30T21:37:48+05:30 INFO [prompt_store::rules_to_skills_migration] Rules-to-skills migration already marked done; skipping startup migration
2026-07-30T21:37:49+05:30 INFO [zed::reliability] worktree diagnostics: stores 0, slots 0, live 0, visible 0, strong 0, dead weak 0, loading 0, entries 0, visible entries 0, largest none
2026-07-30T21:37:49+05:30 INFO [workspace] Rendered first frame
2026-07-30T21:37:50+05:30 ERROR [agent] Failed to authenticate provider: ChatGPT Subscription: Sign in with your ChatGPT Plus or Pro subscription to use this provider.
```
After this fix: the same startup sequence completes with no `ERROR`
line.
```
2026-07-30T22:11:38+05:30 INFO [zed] ========== starting zed version 1.15.0+dev.a8491e63b54bf1881e10fe78bb3e7b1f8a5a2cac, sha
|
||
|
Kunall Banerjee
|
9dc8880b2b |
file_finder: Fix path:line navigation when target file is already open (#55875)
Three pieces of state combined to break `path:line` queries when the target file was already open: - The `CreateNew` lookup ran against `query.raw_query.as_str()`, so a path with a row suffix never matched the existing file and a stray `Create file: foo.rs:3` row was always pushed. - `calculate_selected_index` applied `skip_focus_for_active_in_search` even when the query carried a row/column, jumping past the file the user was asking to navigate inside. - The preserved-selection path only invalidated on `path_query()` changes. Appending `:3` to a typed-out path therefore kept the previously skipped-to fuzzy neighbor selected, hiding the fix above when the query was built up character by character. 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 - [ ] Performance impact has been considered and is acceptable Closes #55551 Release Notes: - Fixed File Finder offering to create a file instead of navigating to a line when the target file is already open |
||
|
Ayush Patil
|
998fbf30ff |
Register Git submodules under their own project path (#61859)
Closes #61671 A submodule's `.git` is a file pointing into the superproject's `.git/modules/<name>`, which looks just like a linked worktree's `.git` file. The identity-path resolution used for recent projects and project grouping treated them the same, so submodules got registered under `.git/modules/<name>` instead of their own folder. The fix detects submodule git dirs (`is_submodule_git_dir`) and skips resolution for them, so a submodule keeps its own working directory as its identity. Linked worktrees and bare repos are unaffected. ### Current vs. Expected Current: opening submodule `Foo/Bar` registers the path as `Foo/.git/modules/Bar`. Expected: it registers as `Foo/Bar`, like any other project. ### Video https://github.com/user-attachments/assets/e2eee5e7-ef64-47ed-9780-6fcafda5ae30 ### Tests - `is_submodule_git_dir` unit test - `resolve_git_worktree_to_main_repo` returns `None` for a submodule - persistence test asserting the submodule identity stays at its own folder Release Notes: - Fixed Git submodules being registered under the parent repository's `.git/modules` directory instead of their own path |
||
|
AvoidTheKitchenandBen Kunkle
|
790dcefb01 |
edit_prediction: Support self-hosted Sweep Next Edit models (#51139)
This adds support for running self-hosted Sweep Next Edit edit prediction models through Zed's OpenAI-compatible provider. The target use case is a local deployment based on [sweepai/sweep-next-edit-1.5B](https://huggingface.co/sweepai/sweep-next-edit-1.5B), using the rewrite-window prompting approach described in [OSS Next Edit](https://blog.sweep.dev/posts/oss-next-edit). Personal user testing shows impressive quality from this small edit prediction model. This is valuable because it allows more flexibility for Zed users to self-host state of the art next edit prediction models! This PR addresses the self-hosted workflow discussed in https://github.com/zed-industries/zed/discussions/50929. Note that the self-hosted model path needed more than just a new dropdown value. Zed has to build the rewrite-window prompt shape the model expects, map the rewritten window back into anchored edits, and make `prompt_format: "infer"` work with the filename-style model identifiers that llama-server local server reports. The main changes are: - add a `Sweep` prompt format for OpenAI-compatible edit prediction providers and route it to a dedicated `SweepPrompt` model path - build Sweep rewrite-window prompts from the active cursor window, recent change history, and related file excerpts - convert rewrite responses back into anchored edits and suppress no-op rewrites - add fixed cursor-window extraction used by the Sweep rewrite prompt path - recognize `sweep-next-edit` model names during `infer`, including filename-style identifiers such as `sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf` - reject reserved Sweep prompt tokens before sending malformed requests to a self-hosted server - update the docs to describe the actual Sweep rewrite-window prompt format Local setup used for manual verification: ```sh llama-server \ --hf-repo sweepai/sweep-next-edit-1.5B \ --hf-file sweep-next-edit-1.5b.q8_0.v2.gguf \ --ctx-size 8192 \ --host 127.0.0.1 \ --port 8080 ``` ```json { "edit_predictions": { "provider": "open_ai_compatible_api", "open_ai_compatible_api": { "api_url": "http://127.0.0.1:8080/v1/completions", "model": "sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf", "prompt_format": "infer", "max_output_tokens": 512 } } } ``` The request that produced this PR included screenshots of the OpenAI-compatible provider configuration and the prompt format dropdown with `Sweep` selected. Tests added in this branch: - `test_sweep_prompt_format_routes_to_sweep_prompt_model` - `test_fixed_line_window_around_cursor_start_middle_and_end` - `test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits` - `test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite` - `test_original_window_for_current_window_uses_latest_pre_edit_snapshot` - `test_original_window_for_current_window_returns_none_without_matching_history` - `test_recent_change_block_from_event_formats_original_and_updated_sections` Verification run locally: - `cargo test -p zed sweep_prompt_format_routes` - `cargo test -p zed subscribe_uses_stale_provider_config` - `cargo test -p edit_prediction sweep_prompt` - `cargo test -p edit_prediction fixed_line_window_around_cursor_start_middle_and_end` - `cargo test -p edit_prediction test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits` - `cargo test -p edit_prediction test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite` - `./script/clippy -p zed -p edit_prediction -p settings_content` Release Notes: - Added support for self-hosted Sweep Next Edit models in OpenAI-compatible edit predictions, including the `sweep` prompt format and `infer` detection for `sweep-next-edit` model names. --------- Co-authored-by: Ben Kunkle <ben@zed.dev> |
||
|
Remco Smits
|
08994c411c |
zed: Wait for session restore before handling CLI open requests (#61814)
Closes #61346 # Objective At startup, a synchronous `try_recv` decides whether to restore the session. On a macOS cold launch the CLI request arrives via `application:openURLs:`, which AppKit dispatches only *after* the startup closure returns, so the check finds nothing, session restore begins, and the request lands moments later on the post-startup path. Both behaviors are individually correct: a user with `restore_on_startup: "last_session"` wants their session back, and the requested file should open. The defect is that they race, the CLI open runs its existing-window matching before restore has placed any windows, finds nothing to reuse, and opens a redundant window. ## Solution Make the post-startup open loop wait for restore to settle before handling a request, so `find_existing_workspace` sees the restored windows and honors `cli_default_open_behavior`. The wait races full restore completion against the first window being placed, so a slow or hung remote-workspace restore can't block a local open. No timeouts involved, the fix is ordering, not delay :). ## Testing **Steps**: 1. disable & enable the setting `close windows when quiting an application` in macos itself in `desktop & dock` section 2. create a bundled Zed app 3. install cli binary to actually test the change 4. Follow any of the steps inside the before/after video's to test all the cases we have I tested this with a manual prod build using a custom script that bundles Zed as a preview app. So I could actually test the cli baviour since it works different for non-bundled builds. So the easiest way to test this would be to run bundling on this PR and install the cli binary to actually test it with the fix included. ## 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 ## Showcase <details> <summary>**Disabled** Close windows when quiting an application</summary> **before** (disabled apps on close & `add to existing window` cli bahavior) https://github.com/user-attachments/assets/b497130b-3432-4fa8-9fbe-70c6f63d165e **After** (disabled apps on close & `add to existing window` cli bahavior) https://github.com/user-attachments/assets/354657f7-8dfe-4beb-9dd4-2bb615cb912c **After** (disabled apps on close & `open a new window` cli bahavior) https://github.com/user-attachments/assets/07fc3062-89a3-4e2a-811e-296533feaad7 </details> <details> <summary>**Enabled** Close windows when quiting an application (unchanged)</summary> **After** (enabled** apps on close & `add to existing window` cli bahavior (**unchanged**)) https://github.com/user-attachments/assets/445f1d3a-2987-46b1-9bfb-b2d61894ddec **After** (enabled apps on close & `open a new window` cli bahavior (**unchanged**)) https://github.com/user-attachments/assets/c3078b0d-7fb4-42db-9dea-095439e23830 </details> --- Release Notes: - Fixed an extra window opening on macOS when launching Zed from the CLI with session restore enabled |
||
|
Lena
|
5786fee55a |
Duplicate Bot: Discussions, second critic, more context (v5) (#61948)
Release Notes: - N/A |
||
|
mTvare
|
ae99a867d7 |
x11: Request repaint after exposure instead of within blocked loop (#61162)
# Objective Closes #61054 This PR fixes Zed window not repainting after they are uncovered on X11. When an X11 window becomes visible after being covered, X11 sends an `Expose` event to tell the application that the window contents need to be presented again. Previously, Zed stored this event and waited for the periodic refresh loop to request a presentation but, the refresh loop is stopped while a window is fully hidden to avoid unnecessary rendering. This meant there might be no refresh tick to handle the pending exposure. window is fully hidden -> periodic refresh loop stops window is uncovered -> expose event -> waits for refresh loop -> window may remain blank This change requests one presentation directly after processing the pending X11 events. Multiple `Expose` events for the same window are coalesced, and unmapped windows are ignored. ## Solution window is uncovered -> expose event -> presentation is requested -> window contents are displayed Required presentations are also excluded from inactive-window frame throttling, so the request is not dropped when Zed is unfocused. Regular rendering for unfocused or fully obscured windows remains throttled. ## Testing Check the issue being closed on steps to reproduction. ## 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 Zed windows sometimes not repainting after being uncovered on X11 |
||
|
Finn Eitreim
|
79cc17c216 |
gpui: Give divs (the option for) a better scrolling experience (#61797)
# Objective Closes #56127 Right now there is an issue where in certain contexts, specifically GPUI div elements, horizontal scrolling w/ a trackpad works very poorly, even when trying to scroll sideways, vertical scrolling will happen. This happens with both a trackpad and scrollwheel. The showcase video also shows the broken behavior. ## Solution The way that scrolling works in the editor is really nice, scrolls are locked to the axis they started on but with enough force can change axis. so by taking the ongoing scroll handler from the editor and moving it up into GPUI, we can get that same functionality for GPUI. I somewhat "take over" the functionality of the existing `restrict_scroll_to_axis` property, because it seems like its purpose was basically trying to fix this problem already, just unsuccessfully. The alternative, and would make things overall nicer to look at, would be to tie this to `allow_concurrent_scroll`, but the effect radius tied to that option is way bigger, so im holding off on that atleast right now. ## Testing Theres a good number of scroll related tests generally, so I don't think i've perturbed any common existing behaviors. attach the functionality to `restrict_scroll_to_axis` really limits the surface. There are also some new tests for the ongoing_scroll behaviors. Tested on my mac w/ both trackpad and mouse. ## 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 Video show casing all the behaviors: broken w/ trackpad working w/ trackpad broken w/ scroll working w/ scroll https://github.com/user-attachments/assets/1935cd2d-a255-4a77-81d5-daa9f72470a6 --- Release Notes: - markdown_preview: Fix horizontal scrolling inside certain elements |
||
|
Smit Barmase
|
a8491e63b5 |
gpui: Restore file drags when re-entering the source window on macOS (#61940)
Follow-up to #58161, which handed file drags to AppKit once the pointer left the window but left the handoff one-way. Re-entering the source window and dropping was not possible. GPUI now suspends the original drag when handing it to the platform and restores it when the drag re-enters the source window, so drop targets receive the original typed payload instead of the synthetic external-paths payload. No release notes this hasn't shipped yet. Release Notes: - N/A |