The ChatGPT Codex backend and the OpenAI API both report an exhausted
usage allowance as HTTP 429, with a body distinguishing it from an
ordinary short-lived rate limit (usage_limit_reached, usage_not_included,
insufficient_quota). from_http_status previously mapped every 429 to
RateLimitExceeded, so the agent retried requests that could not succeed
until the usage window reset, then surfaced a generic rate limit message.
Parse those bodies into a new UsageLimitReached completion error carrying
the provider's message and the reset delay, skip automatic retries for it,
and render a dedicated callout in the agent panel.
Closes#46522
Release Notes:
- Added inline values support for C and C++ when debugging with CodeLLDB
or GDB
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Zed's hang telemetry could say a hang happened, but not what the app was
doing. This PR adds a foreground journal to gpui (behind the `profiler`
feature): the main thread records task polls, action handlers, input
dispatches, window draws, and frame presentations into a fixed-size
ring, and boundary entries — a newly drawn frame's presentation, or the
foreground going idle — partition that stream into activity intervals.
Recording is designed to be cheap enough to ship enabled: sub-threshold
task polls fold into a counter instead of individual entries, and the
ring is drained in bounded chunks off the main thread.
A `HangDetector` drains the journal and reports an incident for any
interval containing a single event at or above the hang threshold (100ms
in release), or whose cumulative foreground spend reaches a frame budget
(8ms in release) — catching both one long stall and many small pieces of
work that together drop a frame. Incidents serialize with phase
(startup/steady), stall and active durations, busy fraction,
dirty-to-present time, and up to 8 contributors in start order with
nesting depth: task polls carry their spawn location, actions their
names, inputs their kind. Zed batches the top 10 incidents by stall per
30 minutes plus a total incident count into a "Hang Incidents" telemetry
event, flushes the remainder on quit, and drops the old per-location
"Hang Report" histograms this replaces.
Release Notes:
- N/A
`ShapedLine` is nearly 3KB by value because it inlines a
`SmallVec<[DecorationRun; 32]>`. A consumer that builds wrapped lines
out of many small uniformly styled fragments only needs the shaped
glyphs plus a single decoration run it can track itself, but it ends up
moving and reallocating that mostly dead capacity constantly because
splitting and painting are only reachable through `ShapedLine`.
This moves the glyph-partitioning half of `ShapedLine::split_at` down to
a new `LineLayout::split_at`, and adds
`LineLayout::paint`/`paint_background` methods that take explicit
decoration runs. Together with the already-public `layout_line`, callers
can now hold a bare `Arc<LineLayout>` and their own decorations.
`ShapedLine::split_at` delegates to the new method and behaves the same.
## 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
Allows configuring the Bash LSP.
Tested with the following config:
```json
"bash-language-server": {
"binary": {
"path": "bash-language-server",
"arguments": ["start"]
},
"settings": {
"bashIde": {
"shfmt": {
"binaryNextLine": true,
"caseIndent": true,
"spaceRedirects": true,
"simplifyCode": true
}
}
}
}
```
Config options [defined
here](https://github.com/bash-lsp/bash-language-server/blob/main/server/src/config.ts),
all prefixed with `bashIde`.
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:
- Added support for configuring the Bash LSP adapter.
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes#55728
## Summary
The Windows installer writes the localized Windows 11 Explorer context
menu title to `HKCU\Software\Classes\{RegValueName}ContextMenu`, where
the release channels use `Zed`, `ZedPreview`, and `ZedNightly` as the
registry value names.
`explorer_command_injector.dll` was reading from `ZedEditor*ContextMenu`
instead, so the registry lookup failed and Explorer always received the
hardcoded `Open with Zed` fallback. This aligns the DLL registry paths
with the installer-written keys for stable, preview, and nightly.
## Tests
- `cargo check --package explorer_command_injector --no-default-features
--features stable`
- `cargo check --package explorer_command_injector --no-default-features
--features preview`
- `cargo check --package explorer_command_injector`
- `cargo check --package explorer_command_injector --all-features`
- `cargo fmt --check --package explorer_command_injector`
- `git diff --check`
Release Notes:
- Fixed localized Windows Explorer context menu titles falling back to
English.
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Refactors our query loading to instead have an enum of supported queries
and load the query files themselves in parallel, where possible.
We will use this to warn extension authors when unsupported queries are
present, as we no longer want to ship those as part of the extension.
It also now enforces one file per supported query - only one extension
currently utilizes this feature and was undocumented previously, so I
decided in favor of removing it here, since this will help with
enforcing extensions to just ship query files we actually support in the
future. The extension has also been migrated so that it does not break
with this effort
Side-effect of this change is that we now load both embedded and
external languages up to at least 10%/5% faster, since the files are now
read in parallel as opposed to sequentially one by one.
Release Notes:
- N/A
# Objective
Fixes#60922
The remote development documentation references action names as
hardcoded strings (`projects: open in wsl`, `projects: open wsl`). These
can drift out of sync with the actual action definitions in code and
don't benefit from the docs preprocessor's auto-rendering.
## Solution
Replaced hardcoded action name strings with the `{#action ...}`
preprocessor template syntax in `docs/src/remote-development.md`:
- `{#action projects::OpenFolderInWsl}` for "Opening a local folder in
WSL"
- `{#action projects::OpenWsl}` for "Opening a folder already in WSL"
This ensures the docs auto-resolve the human-readable action name from
the code definition, preventing future drift.
## Testing
- Verified the `{#action ...}` syntax is documented in
`docs/README.md:78-82` and implemented in
`crates/docs_preprocessor/src/main.rs`.
- Reviewed the action definitions in `crates/zed_actions/src/lib.rs:843`
(`OpenFolderInWsl`) and `lib.rs:852` (`OpenWsl`) to confirm correct
namespace and struct names.
- No code changes, docs only — no build or test required.
## 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/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
N/A — documentation-only change.
---
Release Notes:
- N/A
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Co-authored-by: Finn Evers <finn.evers@outlook.de>
# Objective
Closes#62624
Recently, Pyright and BasedPyright changed how they retrieve analysis
settings through `workspace/configuration` in microsoft/pyright#11480
and DetachHead/basedpyright#1847, respectively. Older versions requested
the dotted `python.analysis` and `basedpyright.analysis` sections
directly. Recent versions instead request the parent `python` or
`basedpyright` section and read its nested `analysis` object. Because
Zed stores many existing configurations under the dotted top-level keys,
those settings are not included in its responses to the new
parent-section requests and are therefore silently ignored.
Zed's documentation and many users' settings still use configurations
like this:
9bde578ef5/docs/src/languages/python.md (L131-L148)
all the configrations in `basedpyright.analysis` won't work now.
## Solution
To maintain compatibility with both old and new servers, we need to
support both configuration formats. This PR introduces
`normalize_pyright_analysis_configuration`, which copies the analysis
settings into both the dotted and nested formats. This ensures that the
settings are available regardless of which format the language server
requests.
The documentation, however, has been updated to use the nested
structure.
## Testing
New unit tests have been added, and the changes have also been built and
tested locally.
## 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 some Pyright and BasedPyright settings not being applied
properly.
# Objective
- Fixes#25905
- Regex search-and-replace silently does nothing when a same-line
pattern contains a lookahead or lookbehind. Searching highlights the
correct hits, but Replace All or `:s` in Vim mode leaves the buffer
untouched.
Reproduce with `316227766016837933199`, search `(\d)(?=(\d{4})+$)` in
regex mode, and replace with `$1,`. Expected:
`3,1622,7766,0168,3793,3199`. Actual before this change: nothing
changes. The same problem affects `(?<=foo: )bar` replaced with `BAZ`.
`SearchQuery::replacement_for` expanded the replacement by re-running
the whole pattern against the matched text alone. Lookaround assertions
inspect text outside the match, so the isolated hit no longer matched
and the edit replaced the hit with itself.
## Solution
- `replacement_for` now expands from captures located at the exact hit
range within its source context.
- Single-line regex hits use the complete source line, so lookahead,
lookbehind, and line anchors see the same surrounding text used by
search.
- Literal and escaped-regex searches bypass context reconstruction
because their replacements do not use captures.
- Multi-line hits retain the exact matched text, preserving the prior
cross-line behavior.
- If selection boundaries prevent the pattern from matching the
reconstructed line, replacement falls back to the isolated hit,
preserving prior behavior.
- Replace All caches the source line across hits on the same line.
Cross-line lookaround remains unchanged: assertions that need text
outside a multi-line hit still produce a no-op replacement.
Search-within-selection can also retain the prior no-op behavior when
the selection boundary changes assertion context.
## Testing
- `cargo test -p search test_replace_with_lookaround` (2 passed)
- `cargo fmt --all -- --check`
- `./script/clippy -p editor -p project -p search`
- Tested on Linux arm64. The change is platform independent.
## Self-Review Checklist:
- [x] I have reviewed the diff for quality, security, and reliability
- [x] Unsafe blocks, if any, have justifying comments
- [x] The content adheres to Zed UI standards
- [x] Tests cover the changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed same-line regex replacements that use lookahead or lookbehind
# Objective
- Fixes#54158
## Solution
- The root cause is in `FileFinderDelegate::set_selected_index`: it
always sets `has_changed_selected_index = true`, regardless of whether
the selection change was triggered by keyboard navigation or mouse
hover.
- Fix: Added a separate `set_hovered_index` hook to the `PickerDelegate`
trait with a default implementation that delegates to
`set_selected_index`. The hover handler in Picker now calls
`set_hovered_index` instead of `set_selected_index`. FileFinderDelegate
overrides `set_hovered_index` to update `selected_index` without setting
`has_changed_selected_index`, so hover-triggered selection changes no
longer interfere with the `Cmd+P` auto-confirm logic.
## Testing
- Added `test_hover_does_not_set_has_changed_selected_index` in
`file_finder_tests.rs`
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content 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 file finder auto-jumping to the wrong file when the mouse
hovered over a different entry after pressing `Cmd+P`
# Objective
Ensure that the "Discard Tracked Changes" option shown in the context
menu that can be opened in the Git Panel's "Changes" tab is only
displayed when it can actually be used. Currently, it is also shown when
the "Unstaged" section has tracked files, even though clicking will not
actually do anything.
Besides fixing that, the changes in this Pull Request also update how
the "Discard Tracked Changes" action works when picked from a subfolder,
with only changes in that subfolder being discarded.
Closes#62535
## Solution
- Update `git_ui::git_panel::git_panel_context_menu` to now accept a
`has_staged_tracked_changes` boolean, in order to be able to
differentiate between the panel having tracked changes, be it unstaged
or staged, and specifically staged tracked changes, as we only want the
"Discard Tracked Changes" to be enabled and affect staged changes.
- Add `git_ui::git_panel::GitPanel::directory_context_descendants` in
order to be able to obtain the list of entries under the directory where
the context menu was deployed, if any.
- Update `git_ui::git_panel::GitPanel::restored_tracked_files` to
leverage the new `directory_context_descendants` method, ensuring that
only the entries under the context menu's directory are restored,
instead of all staged tracked files
## Testing
Tested both manually, as shown in the "Showcase" section, as well as
introduced a new test for these changes –
`git_ui::git_panel::tests::test_directory_discard_tracked_changes`.
## 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
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/24bbb23c-78fb-4fe3-82da-d8bcaec0d79c
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/70db9189-9122-4ee4-b03f-648935c4f0a4
</details>
---
Release Notes:
- Fixed the "Discard Tracked Changes" option being enabled for files in
the "Unstaged" section in the Git Panel
- Updated the "Discard Tracked Changes" option to only affects files in
the directory where the context menu was deployed
Follow-up to #60020.
- Fixes simple fullscreen preventing fullscreen from working on Linux
and Windows (since I use shared dotfiles).
- Fixes quitting Zed in simple fullscreen not correctly restoring the
previous window bounds, causing it to reopen maximized. We are not
handling opening it back in simple fullscreen yet.
Release Notes:
- N/A
# Objective
Fixes#57701.
When Zed is launched with `--user-data-dir`, a Zed-initiated
restart—such as `workspace: clear trusted worktrees` or Restart to
Update—can relaunch Zed without that argument. The restarted process
then uses the default data directory instead of the directory selected
by the user.
## Solution
- Store the resolved custom data directory as GPUI restart arguments
alongside the existing optional restart executable path.
- Forward those arguments when relaunching on Linux, macOS, and Windows.
- Preserve argument boundaries and native `OsString` values, including
paths containing spaces.
- On Windows updates, carry the arguments through
`auto_update_helper.exe` when it launches the updated `Zed.exe`.
Normal launches without `--user-data-dir` continue to restart without
additional arguments. This does not attempt to preserve unrelated CLI
arguments or general launch state.
## Testing
- `cargo fmt --all -- --check`
- `cargo test -p gpui`
- `cargo test -p auto_update --features workspace/test-support`
- `cargo check -p auto_update_helper --tests --target
x86_64-pc-windows-msvc`
- `./script/clippy -p gpui -p gpui_macos -p auto_update -p zed`
- `./script/clippy -p auto_update_helper --target
x86_64-pc-windows-msvc`
The regression tests cover simultaneous restart executable and argument
forwarding, Windows paths containing spaces and trailing backslashes,
updater-helper argument parsing, and the final `Zed.exe` command.
Compilation and unit tests were run on macOS. Linux and Windows runtime
behavior was reviewed but not run locally. A full `gpui_windows`
cross-target check was attempted, but its `psm` dependency requires the
MSVC `lib.exe` tool, which is not available on this macOS host; the
standalone Windows updater helper and its tests compile successfully for
the Windows target.
## 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 (no UI changes)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed Zed forgetting an explicitly passed `--user-data-dir` argument
after restarting (e.g. clicking "Restart to Update")
---------
Co-authored-by: Tom Houlé <tom@tomhoule.com>
# Objective
While working on something else, I noticed that I sometimes get this
warning about a foreground hang:
```
2026-08-19T11:25:45+02:00 INFO [zed::reliability::hang_detection::logging] New foreground hang detected: Tasks(s) that ran too long 215.24375ms - crates/cloud_api_client/src/websocket/native.rs:34:23
```
That I believe can just be safely moved to the background, unless I'm
missing something here.
## Solution
Spawn the websocket task on the background instead of on the foreground,
so that we can't hang the foreground thread anymore for **~200ms**.
## Testing
I have tested that I can still connect to the websocket, not sure what
else to 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
# Objective
Search in the markdown preview matches against the raw markdown source,
including text that never renders. Searching a README for a common word
reports more matches than are visible: the count says 2 when only 1 is
on screen, and navigating to the phantom match appears to do nothing.
Badge-heavy READMEs make this worse, since every badge URL contributes
searchable words (`github`, `build`, `main`, `svg`) that the reader
never sees.
## Solution
Track which source ranges produce no on-screen text and filter matches
against them:
- Link destinations (`[label](url)`, where only `label` renders)
- Images, including alt text and destination, since an image renders as
an image
- Link reference definitions, which `pulldown-cmark` consumes and never
emits events for
Ranges are returned sorted and disjoint so the preview can binary search
them. Search results also derive from the parsed markdown, which lags
the source during a background parse, so `MatchesInvalidated` now fires
once the parse lands.
## Testing
`cargo test -p markdown -p markdown_preview`. Eight new tests cover link
destinations, reference definitions, standalone images, linked images,
images between link text, parse-in-flight, and match-order independence.
Note:
`follow_preview_serialized_path_updates_when_followed_editor_changes`
fails on `main` independently of this change (sqlite `FOREIGN KEY
constraint failed` in `save_preview`, passes in isolation).
## 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
Markdown preview search on the same document, installed Zed versus this
branch:
Before:
<img width="1090" height="1235"
alt="warya_wayne_zed_fix_miscounted_search_in_Markdown_preview_current"
src="https://github.com/user-attachments/assets/d2e59e12-b43e-4fea-ac9c-12631845653b"
/>
After:
<img width="1090" height="1235"
alt="warya_wayne_zed_fix_miscounted_search_in_Markdown_preview_new"
src="https://github.com/user-attachments/assets/9f681fa4-f141-41c9-af9f-675cf3a2f0bd"
/>
---
Release Notes:
- Fixed markdown preview search matching text that isn't rendered, such
as link and image destinations
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
# Objective
Follow-up of #61374.
Zed now supports Windows as a remote target, but when connecting from a
Unix platform to Windows, some path handling still uses the native
client's path style (Unix) to construct paths, which causes weird path
displays in different areas.
One of them is the project path stored in the `settings.json` file,
which is related to the open path picker in the codebase:
5e1fd392f6/crates/open_path_prompt/src/open_path_prompt.rs (L668-L679)
For example, if I have a remote project at `D:\code\test_python` and
want to open it in remote development, I usually use path completions,
with `D:\code\` as the parent path and `test_python` as the selected
candidate. Zed directly joins them using `Path::join` on the Unix
platform, which results in `D:\code\/test_python`.
A second thing I found is the displayed name for the git repo. The
related source code is:
5e1fd392f6/crates/title_bar/src/title_bar.rs (L262-L268)
Also taking `D:\code\test_python` as an example: the passed-in
`common_dir_abs_path` is `D:\code\test_python\.git`, and
`repo_identity_path()` directly uses `Path::file_name()` and
`Path::parent()` from the standard library to handle this:
5e1fd392f6/crates/project/src/git_store.rs (L9956-L9965)
Ideally, this function should return `D:\code\test_python`. But due to
the platform mismatch, `D:\code\test_python\.git` is returned; after
further processing in the title bar, we get `D:\code\test_python\` as
the displayed name, while the expected display name is `test_python`.
In the past, only Unix-like systems could serve as remote servers, and
their path separator (`/`) is valid on Windows, so everything looked
fine. But Unix does not support `\` as a valid separator — that's the
root cause. We need to use `PathStyle`, which is designed for processing
paths across platforms, to deal with these cases.
## Solution
- Added new APIs `PathStyle::parent()` and `PathStyle::file_name()`,
which serve as replacements for `Path::parent()` and `Path::file_name()`
to process paths cross-platform.
- Adopted the new APIs in `repo_identity_path()`, and updated the
relevant call sites.
- For the open path picker, use `PathStyle::join_path()` instead of
`Path::join`.
## Testing
The added `PathStyle::parent()` and `PathStyle::file_name()` are covered
by detailed unit tests. These tests verify that the behavior matches the
corresponding methods in `Path`, just independent of the host platform.
For the path display issues, I built and tested manually; a comparison
is attached in the Showcase section.
## 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>Click to view showcase</summary>
| Content | Before | After |
|:--:|:--:|:--:|
|title bar|<img width="486" height="272" alt="title_bar_before"
src="https://github.com/user-attachments/assets/d14d0e37-a1b8-43ab-b51b-fe9dd1b977eb"
/> | <img width="406" height="274" alt="title_bar_after"
src="https://github.com/user-attachments/assets/fc9193f4-d42c-47a8-a254-4ed08c806a11"
/> |
|path storage| <img width="337" height="264" alt="project_path_before"
src="https://github.com/user-attachments/assets/3352add3-20df-43b9-8a20-10ee7d96e703"
/>| <img width="319" height="262" alt="project_path_after"
src="https://github.com/user-attachments/assets/fa3d7feb-f393-416a-868d-85eb0af5cfb8"
/>|
|open remote| <img width="554" height="135" alt="open_remote_before"
src="https://github.com/user-attachments/assets/62983eca-22ad-472f-8333-8561cfc17357"
/>|<img width="562" height="176" alt="open_remote_after"
src="https://github.com/user-attachments/assets/22528a6b-0e73-4a12-a825-673ba57a63da"
/> |
</details>
## Other things to note
This PR also did a little refactoring: it moved the `PathStyle`-related
tests from the `util` crate to the `path` crate, and updated the
documentation to reflect that Windows can serve as a remote platform.
The recent project picker also suffers from the same cross-platform bug,
but it is not fixed here, because a clean fix requires dealing with
database storage, unlike the direct API changes made here. I will
address it in a follow-up PR.
This PR looks very large, but most of the changes are the test migration
and the new API implementation. I hope the unit tests and comments can
offload some of the burden for reviewers.
---
Release Notes:
- Fixed project paths being built incorrectly when connecting from Unix
machines to Windows remote servers.
Deliver the DOM paste event as a full ClipboardItem (text and image
files) through a new InputHandler::paste hook instead of inserting only
plain text, and add Platform::read_from_clipboard_async so app-initiated
paste (e.g. a custom context menu) can use the browser's asynchronous,
permission-gated clipboard API. Desktop platforms are unaffected: the
async read defaults to a ready task wrapping the synchronous read, and
the paste hook defaults to plain-text insertion.
Release Notes:
- N/A
Adds streaming support to the web `FetchHttpClient`: response bodies are
now read incrementally via the Fetch `ReadableStream` API instead of
being buffered whole with `arrayBuffer()`, enabling streaming responses
(e.g. LLM completions) on web. A bounded channel propagates
backpressure, and dropping the body cancels the browser-side stream.
Release Notes:
- N/A
# Objective
Standardize the behavior of collapsing/expanding entries between Project
Panel and Git Panel. At the time of writing, using `left` or `right` on
the Project Panel would find the nearest parent directory and collapse
it while, on the Git Panel, that will only happen if the directory is
already selected, otherwise it'll select the previous entry instead.
## Solution
Update `git_ui::git_panel::GitPanel::collapse_selected_entry` in order
to always try to find the nearest expanded directory, regardless of the
selected entry, and then collapse it and select it.
The default keymap for Vim/Helix has also been updated to ensure that
`h` and `l` work for collapsing or expanding entries, similar to what
already happens in Project Panel.
## Testing
Tested both manually, as can be seen in the "Showcase" section as well
as added a new test for these changes,
`git_ui::git_panel::tests::test_collapse_selected_entry` .
## 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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/2fd8db03-155a-4406-a190-17a1958dda11
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/f64bd584-a3c2-4a33-b95a-2547c8b721d2
</details>
---
Release Notes:
- Improved `git panel: collapse selected entry` in order to find and
collapse the nearest parent directory, similar to the Project Panel.
- Added support for using `h` and `l`, in Vim/Helix mode, to collapse
and expand entries in the Git Panel.
# Objective
Prevent long worktree and directory paths from shrinking filenames until
they become difficult to read in file finder results.
## Solution
Give the filename label non-shrinking flex sizing, and let the path
label use the remaining space. When the path does not fit, it truncates
from the beginning so the directories nearest the file remain visible.
## Testing
- Ran `cargo fmt --all --check`.
- Ran `cargo test -p file_finder --lib` — 79 tests passed.
- Ran `./script/clippy -p file_finder`.
- To verify manually, open a project with a long root name, search for
files, and resize the file finder. Confirm that filenames remain visible
while paths truncate from the beginning.
## 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 long project paths obscuring file names in the file finder.
Follow-up to #60301, which was reverted in #60321.
I removed the reqwest part of the fix because it crashed. reqwest's
`read_timeout` relies on a tokio timer, but Zed polls HTTP responses on
gpui's executor instead of a tokio runtime, so it panicked when the
response body was awaited. I'll follow up later by patching our reqwest
fork to support the poll behavior we wanted.
This fixes the download being stalled since we restart it when the
system wakes.
I also changed `App::on_system_wake` to return a `gpui::Subscription` to
be consistent with gpui's other on-system-event handlers like
`on_keyboard_layout_change` and `on_thermal_state_change`.
Release Notes:
- Fixed Zed update downloads stalling after the system wakes from sleep
Closes#58145
Remove the `tabular-data-preview` feature flag and register CSV preview
actions and the quick action bar button for every user. Also remove the
now-unused `feature_flags` dependency from the CSV preview crate.
Release Notes:
- Added CSV preview access for all users
@SomeoneToIgnore this is the follow up you asked for in #62692, done as
discussed.
`deserialize_to` keeps a `None` in `items` for every item that failed to
deserialize, and those are never added to the pane. Any later tab
therefore sits at a lower index in the pane than the one it was
serialized with, so activating and previewing by serialized index lands
on the tab that shifted into that slot. When the failing item is the
last one, the index points past the end of the pane and nothing is
activated or previewed.
The serialized index is now mapped to the pane's index by counting the
items before it that actually restored, and an index whose own item
failed to restore is skipped.
Closes#62843
Release Notes:
- Fixed the wrong tab being activated when restoring a workspace
containing items that fail to open
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Pinned tabs are the leading tabs of a pane, and that is persisted as a
plain count. Both sides of workspace serialization could leave the count
out of step with the tabs it is meant to describe:
- When serializing, `serialize_pane_handle` drops items that cannot be
serialized (a pinned diagnostics or project search tab, for example)
from the pane's children, but still stored the pane's raw pinned count.
- When restoring, `SerializedPane::deserialize_to` keeps a `None` in
`items` for every item that failed to deserialize. Those are never added
to the pane, but `self.pinned_count.min(items.len())` counted them
anyway.
In both cases the count ends up pointing past the tabs that were
actually pinned, so the tabs that shift into those slots come back
pinned even though they never were. This also explains the `Pinned tab
count (N) exceeds actual tab count (M)` warning from #33342.
Now the serialized count shrinks with each dropped pinned item, and on
restore only the pinned items that were actually restored are counted.
Closes#62003
Release Notes:
- Fixed tabs being wrongly marked as pinned after reloading a workspace
or updating Zed
# Objective
Opening a file laods it twice. `decode_file_text` builds the whole file
as a `String`, and that `String` stays alive alongside the finished rope
while `text::Buffer::new` copies it in. The `Vec` behind it grows by
doubling, so it also commits up to nearly the file's size again in
capacity it never uses.
Partially addresses #27283.
## Solution
Add `decode_file_text_to_rope`, which streams the file in 1 MB blocks
straight into a `Rope`, validating UTF-8 and normalizing line endings as
it goes. The file is never fully held as a `String`.
`LoadedFile::text` becomes a `Rope` carrying the `LineEnding` detected
before normalizing, so `buffer_store` calls `Buffer::new_normalized`.
## Testing
On a 729 MB SQL dump, peak memory fell 25% and CPU fell around 28%.
tested on 5950x, win11.
Release Notes:
- Improved memory use when opening large files, reducing peak memory
during load by roughly the size of the file itself.
Bumps the treesitter version to include
https://github.com/tree-sitter/tree-sitter/pull/5851
Also makes some changes to `cx.spawn_dedicated` to make it work on web:
- remove the blocking `recv` on the main thread
- adds a new variant `TaskState::Rendezvous` to allow this code to
synchronously return a task
`TaskState::Rendezvous` is needed because of how
`spawn_dedicated_thread` works:
- the caller provides a callback that produces a non-`Send` `Future` on
the dedicated thread
- the callback is sent to the dedicated thread, executed, and the
resulting `Task` is sent back to the main thread
- this all happens synchronously, so that `spawn_dedicated_thread`
returns a synchronous `Task`
However, the blocking `recv` on the main thread traps on the main worker
in the browser.
This PR replaces that with a call to `recv_async`, but this requires a
new `Rendezvous` variant on `TaskState` which represents "a task that it
still waiting to receive the underlying handle from the dedicated
thread".
It also enables the `flume/spin` feature on the web, which is needed to
avoid a synchronous lock acquisition in `send` (it's replaced with a
spinlock). Note that `send_async` wouldn't work here because it acquires
the same lock, and it's unnecessary because `send` only blocks when the
channel is full, but it's an unbounded channel.
---
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
- Fixes#62528
- Code blocks in rendered markdown ignored the `buffer_line_height`
setting. With the line height left unset, they fell back to the ambient
default of ~1.618, so the same code was spaced more loosely in markdown
than it was in an editor or the terminal.
- The extra leading is most obvious with box-drawing characters — the
ASCII-art box from the issue renders as disconnected stripes instead of
continuous vertical rules.
- The issue also notes that the preview font "seems bigger". That part
is working as intended and is not changed here: preview code blocks size
from `markdown_preview_font_size`, which falls back to `ui_font_size`
rather than `buffer_font_size` so that temporary UI zoom doesn't resize
the preview. Users who want it to match the editor can set
`markdown_preview_font_size` explicitly.
## Solution
- Set `line_height` on the code block text style in
`MarkdownStyle::themed_with_overrides`, derived from
`theme_settings.buffer_line_height`.
- The value is `relative(...)` rather than absolute pixels so it tracks
the code font size, which some callers override after building the style
(e.g. the agent panel sets `code_block.text.font_size` downstream). An
absolute value computed from the theme's font size would be wrong for
those callers.
- Scope: this applies to every `MarkdownFont` variant — preview, agent
panel, and editor — since the code block style is shared and
`with_preview_overrides` doesn't touch line height.
- Prose leading is deliberately unchanged. It stays a per-element
typographic choice, independent of the buffer setting.
## Testing
- `cargo test -p markdown` — 145 passed, 0 failed.
- Added
`test_code_block_line_height_follows_buffer_line_height_setting`:
renders a paragraph plus a fenced code block at `buffer_line_height` 1.2
and 1.8, asserts the code block's rendered line height tracks the
setting, and asserts prose leading does *not* move.
- Added `test_code_block_line_height_tracks_overridden_code_font_size`:
overrides `code_block.text.font_size` after building the style and
asserts the line height follows the override. This is what pins the
`relative` vs. absolute choice.
- To reproduce manually, set `"buffer_line_height": { "custom": 1.2 }`
and open a markdown preview containing the ASCII-art box from #62528.
The vertical rules should join into continuous lines, matching how the
same block renders in an editor, and should visibly separate again at
`"comfortable"`.
## 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
<img width="927" height="912" alt="Screenshot 2026-08-17 at 5 06 41 PM"
src="https://github.com/user-attachments/assets/be6213bf-f3aa-42fb-8784-1985b5379d74"
/>
After
<img width="915" height="994" alt="Screenshot 2026-08-17 at 5 06 54 PM"
src="https://github.com/user-attachments/assets/c9c7f395-50cb-437b-a423-2030da88e4f4"
/>
---
Release Notes:
- Fixed markdown code blocks not respecting the `buffer_line_height`
setting
Closes#62796. Follow-up to #62110.
# Objective
The range of a diagnostic entry is anchored when it is ingested, so it
follows edits. The ranges in the related information kept on the
diagnostic were the ones the server published. A code action request
carried both and reported the same note at two different lines: the
entry Zed flattened that note into had followed the edit, the related
information had not.
The distance does not correct itself either. When diagnostics are merged
rather than replaced, the existing entries are re-collected from their
anchors while the payload is cloned as it is, so the two positions drift
further apart with every edit that passes.
`mlir-lsp-server` shows what this costs. `MLIRTextFile::getCodeActions`
takes the line number out of `relatedInformation`, and
`getCodeActionForDiagnostic` resolves it against its own current
document, reading that line to copy its indentation before inserting the
`expected-note` check.
## Solution
The related information moves from `Diagnostic` onto
`DiagnosticEntry<T>`, next to the range it belongs with. The locations
of the diagnostic's own file are then in the same coordinate space as
that range: anchors inside the buffer, points in the worktree's store.
`Diagnostic` carries no coordinates again, so nothing that is only
meaningful inside one buffer travels with a payload that outlives it.
Every transition goes through `DiagnosticEntry::map_coordinates`: the
unsaved-edit adjustment and the clipping when diagnostics are ingested,
the anchoring in `DiagnosticSet::new`, and the conversion back to points
in `merge_diagnostic_entries`. Only the diagnostic's own range is
widened when it is empty, since that is for how it is rendered, while
the related locations are reported back as the server framed them.
Locations in another file have nothing here to anchor to and are kept as
published, which is also what `mlir-lsp-server` expects, since it skips
them.
`DiagnosticEntryRef` is left alone. It is what the rendering path
iterates, down to the scrollbar markers that walk every diagnostic of
the buffer on each frame, so nothing there converts or allocates. The
entries are read through `diagnostic_entries_in_range` where the request
is built, and `diagnostics_in_range` is now implemented on top of it.
The field is an `Option`, as an empty `Arc<[_]>` still allocates and
most diagnostics carry no related information.
`data` has the same staleness and cannot be anchored, as it is opaque.
## Commits
The third commit is mechanical: it introduces `DiagnosticEntry::new` and
rewrites the literals at its call sites, so that the last commit holds
only the change of behaviour.
## Testing
Three tests, all failing before this change. The first two are added as
separate commits, so that they can be run against `main`:
- `test_code_actions_related_information_follows_edits` edits above the
note and requests code actions, where the two positions for it used to
disagree.
- `test_code_actions_related_information_drifts_across_merges` edits and
pulls diagnostics twice, where the distance used to be every line
inserted since the diagnostic was published rather than the last edit
alone.
- `test_code_actions_related_information_of_disk_based_diagnostics`
publishes a diagnostic computed against the file on disk while the
buffer holds an unsaved edit, covering the adjustment the two positions
share.
- `cargo test -p project`
- `cargo test -p language -p diagnostics -p editor`
- `cargo fmt --all -- --check`
- `./script/clippy -p project -p language`
## 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 language servers receiving outdated positions for the related
information of a diagnostic when code actions are requested.
This switches to `async-tar` to point to our fork, which has a fix for a
bug that is causing the Cursor ACP agent fail to download in Zed, due to
Pax attributes.
We will switch back as soon as
https://github.com/dignifiedquire/async-tar/pull/73 is merged.
Closes#62655
Release Notes:
- Fixed an issue where the Cursor ACP agent would fail to start
# Objective
#62768 renamed `crates/csv_preview` to `crates/tabular_data_preview`,
but left the CSV-specific names inside it untouched (on purpose, to
reduce prev PR scope & git diff noise)
## Solution
Finished the generalization, one mechanical rename per commit for easier
review:
1. `CsvPreviewView` -> `TabularDataPreviewPane`
2. `CsvPreviewSettings` -> `TabularDataPreviewSettings`
3. Methods/vars
4. Test helpers/fn names
5. User-facing strings and element ids: tab title fallback:
- `"CSV Preview"` -> `"Tabular Data Preview"`,
- empty state `"No CSV content to display"` -> `"No data to display"`,
- dev tooltip, and element ids
`csv-filter-*`/`csv-col-header-*`/`csv-table`/`csv-display-cell-*` ->
`table-*`/`tabular-data-table`
6. Doc comments that implied CSV-only behavior, reworded to be
format-agnostic
> NOTE: PR is split into commits by change type for ease of review)
## Testing
`cargo check -p tabular_data_preview -p zed` builds clean after each
commit; `cargo test -p tabular_data_preview --lib` passes (10/10).
## 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
Release Notes:
- N/A
# Objective
#60768 renamed the feature (action names, icon, TSV/PSV/SSV support)
from CSV-only to generic tabular data preview, but left the crate itself
named `csv_preview` — no longer accurate now that it handles any
delimited format.
## Solution
Renamed `crates/csv_preview` to `crates/tabular_data_preview` and
updated all references (workspace `Cargo.toml` members/dependencies,
`crates/zed/Cargo.toml`, `crates/zed/src/main.rs`,
`crates/zed/src/zed/quick_action_bar/preview.rs`). No behavior change.
> NOTE: Mechanical changes. Internal structs not renamed on purpose to
reduce git diff noise. Follow-up PRs will do the cleanup (also
mechanical changes)
## Testing
`cargo check -p tabular_data_preview` and `cargo check -p zed` build
clean; preview still opens for csv/tsv/psv/ssv files.
Zed still runs, everything still opens.
## 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
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
# Objective
Fixes#47623
- When authenticating git commands using a security key through
`askpass`. The modal which asks for user presence does not get dismissed
even after the git command finishes successfully.
## Solution
Add a cancellation task to the `AskPassModal`, which gets dropped when
the requested operation completes. This cancellation task then dismisses
the modal.
## Testing
- I've tried authentication through `askpass` using my own security key.
Testing both successful and failed authentication.
- I've added tests which confirm that the modal gets dismissed when a
task is cancelled, and that the cancellation is triggered when
`ask_password` Task gets dropped.
Willing to pair on review, message me on Slack. Showcase video left out
because it would leak private information.
## 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 authentication prompts not dismissing automatically when using
security keys with ssh
# Objective
Fix Markdown preview task list checkboxes not rendering for task items
in
loose or nested lists.
For example, this Markdown should render all three items with
checkboxes:
```markdown
- [ ] test
- [x] test
- [x] test
```
Before this change, the items after blank lines could fall back to ordinary
list bullets instead of task checkboxes.
## Solution
Update Markdown list item rendering to detect task list markers in both tight
and loose list event shapes emitted by pulldown-cmark.
The previous renderer only handled:
Item -> TaskListMarker
Loose lists can emit:
Item -> Paragraph -> TaskListMarker
This PR adds a small helper to find task markers for both forms, then reuses
the existing checkbox rendering and toggle behavior.
## Testing
Tested on macOS with:
rustup run 1.95.0 cargo test -p markdown
test_task_marker_lookup_handles_loose_and_nested_lists
rustup run 1.95.0 cargo test -p markdown test_table_checkbox
The first test covers loose and nested task list items. The table checkbox
tests verify that [x] and [ ] inside tables still remain text and are not
treated as task list checkboxes.
## 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
<img width="927" height="275" alt="image" src="https://github.com/user-attachments/assets/a36f0b9f-8759-4593-99a9-8a256396e89e" />
after
<img width="963" height="322" alt="Snipaste_2026-07-09_12-27-05" src="https://github.com/user-attachments/assets/972fa7a7-274a-4b0a-a13c-c7e1aec27622" />
---
Release Notes:
- Fixed Markdown Preview for loose list item markers
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
## Objective
`file_scan_exclusions` replaces the defaults instead of adding to them,
so excluding one extra directory means restating all eleven default
globs and never picking up defaults added in later Zed releases.
## Solution
`file_scan_exclusions` now accepts the `"..."` entry, which expands to
the value it overrides, so `["**/node_modules", "..."]` adds to the
inherited globs instead of replacing them. Entries listed by name keep
their position, and leaving `"..."` out still replaces the list
outright, so existing settings behave exactly as they do today.
## Testing
- Four unit tests in `crates/settings_content/src/project.rs` cover
splicing versus replacing, accumulation across successive layers, and
edge cases: a repeated `"..."`, an empty list clearing the value, and a
bare `["..."]` leaving it unchanged.
- To check by hand: set `"file_scan_exclusions": ["**/node_modules",
"..."]` in user settings and confirm `node_modules` disappears from the
project panel and file finder while `.git` and `.DS_Store` stay
excluded. Remove `"..."` and confirm only `node_modules` is excluded.
Repeat in a project's `.zed/settings.json` to confirm it splices the
resolved user settings rather than the defaults.
- Tested on macOS. This is platform-independent settings-merge logic
with no OS-specific code paths, so I did not test Linux or Windows.
## 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:
- Added support for the `"..."` entry in `file_scan_exclusions`. Custom
exclusions can now extend the defaults instead of replacing them.
# Objective
npm tasks in VS Code support a `path` property which works like
`options.cwd` but it's always relative to the workspace folder.
## Solution
`cwd` is being set based on `path` of npm tasks. If `options.cwd` is
also set, it wins over the `path` property. This matches the behavior of
VS Code.
## Testing
A new test case has been added, testing deserialization of `path` and
`options.cwd`.
## 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)
- [x] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
---
Release Notes:
- Added support for `path` property on VS Code npm tasks
Closes#60013
# Objective
Right now Zed can go full screen but it does not allow you to fix the
hole screen,
by that I mean that Zed can go behind the notch so you don't have extra
useless room left.
## Solution
You can now use the `fullscreen_mode` = `simple` setting to use the new
simple full screen feature, that lives besides the normal full screen
feature. But allows you to have an option to go 100% full screen without
losing any useless space on your macbook screen.
**Note** this is mostly usefull when you have a macbook that has a notch
whitch is kinda in the way of your work flow.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content 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**
<img width="5712" height="4284" alt="IMG_0339"
src="https://github.com/user-attachments/assets/9f908ffd-7cef-4999-a454-c80f72c40dc8"
/>
**After** (Note now Zed is behind your notch when using the simple full
screen feature)
<img width="5712" height="4284" alt="IMG_0360"
src="https://github.com/user-attachments/assets/5917ed4d-2a64-4464-a794-bc46fd034521"
/>
---
Release Notes:
- Added support for simple fullscreen mode using the `fullscreen_mode`
setting, set it to `simple` to try it out.
# Objective
Closes#62252
The Git Panel could only stash *everything* — `Stash All` runs
`git stash push --include-untracked`, sweeping tracked edits and
untracked files
into a single entry. There was no way to stash a subset, so the common
workflows
of "park my tracked edits but keep my new scratch files" and "park what
I've
staged and keep working on the rest" required dropping to the terminal.
## Images
<img width="389" height="358" alt="Screenshot 2026-08-10 at 3 10 50 PM"
src="https://github.com/user-attachments/assets/18e4c943-e320-4802-ada8-59e54bf4cefd"
/>
<img width="504" height="462" alt="Screenshot 2026-08-10 at 3 10 37 PM"
src="https://github.com/user-attachments/assets/783237eb-980d-47bc-a0f5-17b03a23a60c"
/>
## Solution
Add two stash variants alongside `Stash All`, surfaced in the Git
Panel's
overflow menu based on how the list is currently grouped, so the menu
mirrors the
sections the user can actually see:
| Group By | Stash entries offered |
| --- | --- |
| None | Stash All |
| Tracked & Untracked | Stash All, **Stash Tracked** |
| Staged & Unstaged | Stash All, **Stash Staged** |
- **`git::StashTracked`** stashes tracked changes and leaves untracked
files in
place. It reuses the existing pathspec plumbing
(`Repository::stash_entries`),
filtering the status list down to the paths to stash.
- **`git::StashStaged`** stashes the index only, leaving unstaged
changes in
place. This *cannot* be expressed as a pathspec — a partially staged
file would
have its unstaged hunks stashed too — so it needs git's own `--staged`
flag.
That meant a new `GitRepository::stash_staged` backend method and an
`optional bool staged` field on `proto::Stash` so remote projects work
too.
Both actions are unbound by default and are dispatchable from the
command palette
when the panel is focused.
One subtlety worth calling out for review: `Stash Tracked` filters on
`FileStatus::is_created()`, not `is_untracked()`. Staging a new file
flips it from
`Untracked` to `Tracked { Added }`, but the panel still lists it under
**Untracked** — using `is_untracked()` meant staged-new files were
silently
stashed. `is_created()` is the same predicate the panel uses to build
that section
(`git_panel.rs`), so the menu item and the list can no longer disagree.
This branch also includes a separate commit adding **per-section
staging**
(`git::StageSection` / `git::UnstageSection`) — right-click a file to
stage or
unstage every entry in its section. Happy to split that into its own PR
if
preferred.
## Testing
Manually tested on macOS against a scratch repo with a mix of states:
modified
tracked files, untracked files, and untracked files that had been
staged.
- `Stash Tracked` with tracked edits + untracked files → only tracked
edits
stashed; untracked files remain.
- `Stash Tracked` with untracked files **staged** → they remain, staged.
This was
broken in an earlier revision and drove the `is_created()` fix above.
- `Stash Staged` with one file staged and another modified-but-unstaged
→ only the
staged file is stashed; the unstaged edit and untracked files survive.
- `Stash Pop` round-trips both cases back to the original state, with no
conflicts.
- Menu contents and disabled states verified in all three Group By
modes.
- Per-section staging covered by a new unit test,
`test_stage_section_scopes_to_selected_section`.
Not covered by automated tests: the stash actions themselves.
`FakeGitRepository`
leaves every stash method `unimplemented!()`, so stash behavior isn't
reachable
from GPUI tests today — consistent with the existing untested
`StashAll`. Adding
fake-repo stash support looks like a worthwhile follow-up but felt out
of scope here.
Reviewers on non-macOS platforms: nothing here is platform-specific.
Note that
`Stash Staged` requires **git 2.35+** (Jan 2022) for `git stash push
--staged`;
older git surfaces a clear error toast rather than failing opaquely. The
remote
path (`proto::Stash.staged`) has not been exercised against a live
collab session.
## 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
Release Notes:
- Added `Stash Tracked` and `Stash Staged` options to the Git Panel,
letting you stash only tracked changes or only staged changes.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
Anthropic model-list requests currently flatten request, transport,
response, and API failures into `anyhow` strings. Callers therefore
cannot distinguish an invalid API key from connectivity or provider
failures, even though Anthropic returns a structured error payload.
This changes `list_models` to return `AnthropicError`, maps each request
stage to its existing typed variant, and routes unsuccessful responses
through the same structured response handler used by completion
requests. The language model provider converts that error at its
existing `LanguageModelCompletionError` boundary. A regression test
verifies that an authentication response retains both its error category
and Anthropic's human-readable message.
Testing performed:
- `cargo fmt --check`
- `cargo nextest run -p anthropic -p language_models`
- `./script/clippy -p anthropic -p language_models`
Release Notes:
- Fixed Anthropic API key errors being reported as generic model-list
failures.
OpenAI Responses API send failures were being converted into the
catch-all `Other` error before they reached the language model layer. A
DNS failure from the ChatGPT Subscription provider could therefore
appear as an unexpected model error instead of using the existing
transport-aware messaging and retry behavior.
The shared Chat Completions transport already preserves this
distinction. This change applies the same `RequestError::HttpSend`
classification to Responses API streaming and compaction requests,
allowing the existing conversion to produce
`LanguageModelCompletionError::HttpSend` with the provider and
underlying cause intact. Separate regression tests cover send failures
in both request paths.
Testing performed:
- `cargo test -p open_ai reports_http_send_errors -- --nocapture`
- `cargo test -p open_ai`
- `cargo check -p openai_subscribed`
- `cargo fmt --all --check`
- `git diff --check`
- `./script/clippy -p open_ai`
Release Notes:
- Fixed ChatGPT Subscription connection failures showing a generic error
instead of a network-specific message.
Also disables them by default because it makes autofixes for the average
case very slow.
Note that this does not yet change anything for the Zippy /autofix
command here.
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/62262
## Solution
Identical hover responses from multiple language servers should be
displayed only once.
Different hover responses should still all be preserved, since multiple
language servers may provide complementary information.
## Showcase
https://github.com/user-attachments/assets/67246d9f-ed1c-4f5a-98f5-f10548b7fc6d
---
Release Notes:
- Deduplicated identical language server hover responses
---------
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Closes https://github.com/zed-industries/zed/issues/61806
Follow-up to #58791 and #61265.
# Objective
Since Zed started injecting its own gpg wrapper for commit signing, the
wrapper's "silent first attempt" used `--pinentry-mode error`, which
forbids gpg-agent from launching *any* pinentry. That was meant to avoid
the `gpg: signing failed: Inappropriate ioctl for device` failure from
TTY-based pinentries, but it also blocked **GUI** pinentries like
pinentry-mac, which need no TTY and can supply the passphrase silently
from the macOS Keychain. For users with that setup (and gpg-agent's
in-memory cache disabled via `default-cache-ttl 0`), the first attempt
always failed and Zed's passphrase modal appeared on **every commit**,
even though terminal git signed silently.
This also makes the setting proposed in #61533 unnecessary: instead of
asking users to choose between Zed's prompt and the system pinentry, the
wrapper now tries the system pinentry automatically and only falls back
to Zed's askpass modal when gpg genuinely cannot obtain the passphrase
on its own.
## Solution
Restructure the wrapper script to sign in three stages, most silent
first, so every pinentry configuration self-selects the right behavior
without any detection or settings:
1. **`--pinentry-mode error`**: succeeds only via gpg-agent's passphrase
cache or an unprotected key; guaranteed to never prompt anywhere. This
keeps the #61265 behavior byte-identical.
2. **Default pinentry mode**: lets the configured pinentry run, exactly
like terminal git. GUI pinentries (e.g. pinentry-mac reading the macOS
Keychain) need no TTY and sign silently or show their native dialog; TTY
pinentries fail fast with `Inappropriate ioctl for device` because git
spawns gpg without a TTY.
3. **Loopback mode**: asks for the passphrase via Zed's askpass modal
and hands it to gpg on fd 3, for setups where gpg cannot prompt at all
(e.g. when gpg-agent's `pinentry-program` is not configured).
## Testing
Initial steps:
1. Run `security delete-generic-password -s GnuPG` to remove the GnuPG
keychain entry, forcing you to re-enter your passphrase (start from the
initial state of issue)
2. (**optional for a few test cases**) Configure your
`~/.gnupg/gpg-agent.conf` with `pinentry-program
/opt/homebrew/bin/pinentry-mac`
3. Run `gpgconf --kill gpg-agent` to force reset/kill the gpg agent
cache
Cases to test:
1. Have no existing gpg key and you can still commit without needing to
enter a passphrase
2. Have a gpg key configured in git but no `~/.gnupg/gpg-agent.conf`
config that configures the `pinentry-program`
This should still request your passphrase via Zed's askpass modal, even
though no `pinentry-program` is configured and committing via the
terminal throws an error `gpg: signing failed: Inappropriate ioctl for
device`
3. Have a gpg key configured in git and a `~/.gnupg/gpg-agent.conf`
config that configures the `pinentry-program`, and cancel the native
pinentry program → Zed should fall back to requesting your passphrase
via the askpass modal
4. Have a gpg key configured in git and a `~/.gnupg/gpg-agent.conf`
config that configures the `pinentry-program`, and fill in your
passphrase via the native pinentry program with storing your passphrase
in the keychain **disabled**
5. Have a gpg key configured in git and a `~/.gnupg/gpg-agent.conf`
config that configures the `pinentry-program`, and fill in your
passphrase via the native pinentry program with storing your passphrase
in the keychain **enabled** → subsequent commits sign silently, matching
terminal git
## 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
**After: (Testing that the system pinentry program is used and works
without needing to reenter your passphrase everytime only when you
remove it from your keychain)**
https://github.com/user-attachments/assets/0c8cdd11-957d-443a-ab10-1579bbf3b49e
---
Release Notes:
- Git: Fixed the GPG passphrase modal appearing on every commit for
users whose configured pinentry (e.g. pinentry-mac with the macOS
Keychain) can supply the passphrase without Zed's help. Zed now only
prompts when gpg cannot obtain the passphrase on its own.
---------
Co-authored-by: Eric Holk <eric@zed.dev>
Closes#57388.
When a dock is listed in `resize_all_panels_in_dock`, reset its
compatible panels to the active panel's default size. This applies to
the reset actions and resize-handle double-clicks. Docks not listed in
the setting continue to reset only the active panel.
Adds regression coverage for fixed panels with different defaults,
flexible panels, and active-panel-only resets.
Release Notes:
- Fixed dock size reset commands only resetting the active panel when
`resize_all_panels_in_dock` is enabled.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
