Follow-up to #63195.
# Objective
When `cursor_animation` is enabled, moving a block cursor (e.g. in Vim
mode) leaves the character underneath hidden until the spring animation
fully finishes, after which the letter pops in.
This happens because `CursorLayout::paint` returned early while
animating, skipping `block_text`.
## Solution
Paint `block_text` upon the animated cursor's arrival at the target
cell, rather than waiting for the entire spring settling phase to
complete:
- Check if any animated corner has reached the target bounds
(`bounds.dilate(...)`).
- If the cursor is still in mid-air, return early so we don't draw the
destination letter prematurely.
- Once it touches the target cell, fall through and paint `block_text`
over the cursor polygon.
## 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
Left: before, Right: after
https://github.com/user-attachments/assets/7057f40a-64a7-4035-b8e2-7c0b7dc40069
---
Release Notes:
- Fixed an issue where the block cursor hid the character underneath
until cursor animation completed.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
# Objective
Zed on X11 could crash with `index out of bounds: the len is 0 but the
index is 0` in `WgpuAtlas::get_texture_info` right after recovering from
a lost GPU device (Sentry ZED-BVQ, Linear FR-488).
## Solution
When the device is lost, `X11Window::draw` recreates the renderer, which
clears the sprite atlas, and sets `force_render_after_recovery` so the
next frame rebuilds the scene instead of replaying the cached one. Only
the periodic refresh timer consumed that flag though. An `Expose` event
handled in the same event loop turn (a compositor repainting after the
same GPU reset, for example) requested a presentation-only frame with
`force_render: false`, so GPUI presented the previously rendered scene,
whose sprites still pointed at atlas textures that no longer exist.
We now consume the flag in `X11WindowStatePtr::refresh`, so every frame
request, Expose or timer, forces a full render after recovery. The field
is private now so a caller can't bypass it again.
## 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 a crash on Linux (X11) that could occur when a window was
redrawn immediately after recovering from a lost GPU device.
- [GPUI] Fixed a crash on Linux (X11) when an `Expose` event presented a
cached frame immediately after GPU device recovery.
# Objective
Fixes#63835.
Nearby related diagnostics omitted the link back to their primary
diagnostic.
## Solution
Always include the existing back link on related diagnostic blocks,
regardless of line distance. The primary diagnostic still suppresses
nearby related hints as before.
## 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
---
Release Notes:
- Improved diagnostic navigation by showing back links to the primary
diagnostic even for nearby related diagnostics.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Previously, we created texture atlas bind groups every frame (once per
sprite group). This showed up in delta web mobile profiling.
This PR reuses them across frames, which saved ~5% frame time on the
delta web thread view on a pixel 10 pro.
---
Release Notes:
- [GPUI]: Improved performance on wgpu by caching atlas bind groups
## Objective
Allow custom terminal path regexes to extend inherited entries without
copying them. This PR also corrects the existing mismatch between the
documented and shipped default regexes.
This is the last submission in the #64399 series, following #62769,
#64222, #64440, #64484, and #64540.
## Solution
The `"..."` entry is intentionally supported at the top level only. A
`"..."` line inside a multiline entry remains regex text. Existing
configurations that use bare `...` as a three-character regex can
preserve that behavior by writing `["..."]` as an entry instead.
The shipped regexes and hyperlink matching behavior are unchanged.
## Testing
All focused tests and all hyperlink tests pass on macOS. The documented
default expressions were checked against the shipped values.
## Self-Review Checklist:
- [x] I’ve reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content 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 `"..."` in `terminal.path_hyperlink_regexes` to
extend inherited regexes without repeating them.
Make provider-owned terminal cards read-only for user input while
preserving local inspection. This builds on the explicit terminal
ownership introduced in #64544.
- Add a construction-time `TerminalView::with_read_only` option,
selected from ACP process ownership rather than PTY presence. Existing
views remain interactive by default, including client-owned headless
terminals.
- Reject typing, send actions, paste, file/path drops, IME input,
clear/rerun actions, and focus reports in read-only views.
- Preserve selection, copying, links, scrolling, search, and local Vi
navigation. Leaving Vi mode does not enable terminal input.
- Pass an explicit mouse-routing policy to the existing lower terminal
handlers so provider-requested mouse and alternate-scroll modes cannot
consume inspection gestures. Real modifiers remain unchanged, and
Linux/FreeBSD middle-click paste is suppressed.
Release Notes:
- N/A
## Objective
Group the threads sidebar settings together in JSON and the Settings
Editor, using consistent “Threads Sidebar” terminology.
This follows up on #63452 now that #62883 has added configurable default
width, and includes the auto-open setting added since then.
## Solution
- Group `position`, `default_width`, and `auto_open` under
`agent.threads_sidebar`, and display their controls together in
Settings.
- Automatically migrate `agent.sidebar_side`,
`agent.threads_sidebar_default_width`, and
`agent.threads_sidebar_auto_open` across supported settings scopes,
preserving existing nested values.
- Apply changes to the default width immediately, including when the
sidebar was manually resized, and clear the saved width override.
Unrelated settings changes preserve manual sizing.
- Document all three settings, including the previously missing position
entry.
## Testing
The following targeted checks passed on the local changes:
- `cargo test -p migrator nest_agent_threads_sidebar_settings` — 7 tests
passed.
- `cargo test -p sidebar -p workspace -p agent_settings -p gpui_platform
--features gpui_platform/runtime_shaders --lib -- width
threads_sidebar_settings test_open_directory_in_existing_window` — 9
tests passed.
- `cargo fmt --all` completed successfully.
- `git diff --check` passed.
- From `docs`: `npx prettier --check src/reference/all-settings.md
src/ai/parallel-agents.md` passed.
Coverage includes migration precedence and supported scopes, settings
defaults and width limits, manual sizing and resets, persisted widths,
and auto-open behavior.
Full application tests and manual UI testing were not run. Clippy was
not rerun after the final terminology changes.
## 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:
- Improved threads sidebar settings by grouping position, default width,
and auto-open together, and applying default-width changes even after
manual resizing.
Fixes the git panel's active repository being silently overridden by the
cursor position in `ProjectDiff`.
Closes#58792Closes#61530
## Summary
When a multi-buffer item (e.g. `ProjectDiff`) gains focus, the workspace
calls `set_active_repo_for_path` with the cursor's project path to
automatically switch the active git repository. This was safe when
multi-buffer items returned `None` from `active_project_path`, but PR
#57236 changed `ProjectDiff` to return the cursor-based path (for
project panel highlighting), inadvertently allowing the cursor position
to override the user's explicit repository selection.
Fix the issue by restoring the `Singleton` guard that was removed in PR
#57236: only call `set_active_repo_for_path` when the active item is
backed by a single buffer.
## Changes
- **`workspace.rs`**: Only call `set_active_repo_for_path` when the
active item's `buffer_kind` is `Singleton`. Multi-buffer items (e.g.
`ProjectDiff`, diagnostics, search results) span multiple repositories,
so their cursor position should not trigger an automatic repository
switch.
## Before
https://github.com/user-attachments/assets/6ca4fa61-b42a-447b-9de7-8b6ec1f1181a
## After
https://github.com/user-attachments/assets/9b045ad9-2bb5-4862-ac45-41e9fdd3dc96Closes#58792
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed the Git panel unexpectedly switching repositories when viewing
changes in multi-repository projects.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: dino <dinojoaocosta@gmail.com>
## Objective
Let projects and language-specific settings add scopes where edit
predictions are disabled without repeating inherited scopes.
Part of #64399.
## Solution
Extend the `"..."` convention from #62769, #64222, #64440, #64484, and
#64540 to `edit_predictions_disabled_in`. For example, a global
`["comment"]` and a language override of `["string", "..."]` disable
predictions in both scopes.
Inherited scopes are inserted at `"..."`, and duplicates keep their
first occurrence. Omitting the marker replaces the list, `[]` clears it,
and omitting the setting preserves inheritance. The default remains
`[]`.
## Testing
Tested on macOS through settings loading, covering project and
language-specific overrides, inheritance, replacement, and clearing. The
language settings tests passed. Live editor behavior has not been
checked manually.
To check manually, configure global `["comment"]` and a language
override of `["string", "..."]`. Confirm predictions are disabled in
both scopes, then remove `"..."` and repeat with `[]` to check
replacement and clearing.
## 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 `"..."` in `edit_predictions_disabled_in` so project
and language-specific settings can extend inherited scopes.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
## Objective
Let users and projects add edit prediction exclusion patterns without
repeating defaults or inherited patterns.
Part of #64399.
## Solution
Extend the `"..."` convention from #62769, #64222, #64440, and #64484 to
`edit_predictions.disabled_globs` using `SplicingVec`. Inherited
patterns are inserted at `"..."`, and duplicates retain their first
occurrence. Omitting the marker replaces the list, `[]` clears it, and
omitting the setting preserves inheritance.
Opening an absent setting now initializes it with `["..."]` instead of
clearing inherited patterns, and the selection is located by parsing the
JSON instead of a regex, so a commented-out or nested `"disabled_globs"`
can no longer capture it. Cursor imports append `"..."` like the
`files.exclude` import does, so Zed's sensitive-file defaults survive an
import; empty lists and empty or literal `"..."` entries are dropped,
matching `enabled_patterns`.
## Testing
Tested on macOS with settings merge and loading tests, Cursor import
tests, the UI settings update and selection path (including
commented-out and nested decoy keys), the new `settings_json` key-path
lookup, and Copilot integration coverage.
To check manually, configure custom disabled patterns alongside `"..."`
and confirm that both custom patterns and inherited sensitive-file
patterns remain disabled. Repeat without `"..."` and with `[]` to verify
replacement and clearing. Opening the setting when it is absent should
preserve inherited patterns.
## 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 `"..."` in `edit_predictions.disabled_globs` so
custom patterns can extend inherited exclusions, and fixed "Configure
Excluded Files" selecting the wrong list when a commented-out
`disabled_globs` precedes it.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Provider terminal metadata creates a display buffer, not a client-owned
process. These terminals previously entered the process-completion path,
which completed immediately when no local task existed and cached empty
output. Provider exit status was also discarded.
- Distinguish client-owned processes from provider-owned display
terminals, including headless processes that use the same lower-level
display renderer.
- Complete display terminals on provider exit and retain ACP exit
codes/signals. Duplicate creation and exit events preserve identity and
completion; late output refreshes cached content without changing exit
time or status.
- Refresh tool-card metadata when provider completion arrives without
another tool update.
- Show Stop only for client-owned processes and avoid treating display
terminals as background processes when their tool completes.
- Preserve the full unsigned exit-code range without manufacturing `-1`
for signal-only exits.
Process wait/kill behavior, PTY release, and sandbox cleanup remain
intact. Header rendering continues to use cached metadata rather than
extracting terminal contents.
Release Notes:
- acp: Fixed premature completion and incorrect exit-status reporting
for external-agent terminals, and removed Stop controls from terminals
managed by the agent.
# Objective
- This PR enables users to switch between unified/split diff views when
comparing buffers.
- Fixes#64419 .
## Solution
- The unified/split toggle (`DiffStyleControls`) is normally surfaced
automatically by `BufferSearchBar`, which detects any active item
exposing a `SplittableEditor`. That auto-detection is gated to
multi-buffer views, since it's paired with an expand/collapse-all-hunks
control that only makes sense across multiple files. `FileDiffView`
(used by `zed --diff <old> <new>`) is a singleton buffer, so it's
intentionally excluded from that generic path.
- Git's own single-file diff view,
[`SoloDiffView`](https://github.com/zed-industries/zed/blob/f2e33599724432f329f9e23b353a8fb28cd6ece3/crates/git_ui/src/solo_diff_view.rs#L52),
hits the same limitation and works around it with a small, dedicated
`ToolbarItemView` (`SoloDiffStyleToolbar`) that renders
`DiffStyleControls` directly, independent of `BufferSearchBar`.
- This PR follows the same pattern: a new `FileDiffStyleToolbar` (in
`git_ui_core::file_diff_view`) activates whenever a `FileDiffView` is
the focused pane item, and renders just the unified/split toggle, no
expand/collapse or file-status controls, since neither concept applies
to a plain two-file diff. It's registered in `initialize_pane` alongside
the existing git toolbars.
## Testing
- Did you test these changes? If so, how?
Ran `cargo test -p git_ui_core`, all passed. I've also attached the
results of manual testing in the Showcase section below.
- Are there any parts that need more testing?
I think more tests can be added.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
Adds a unified/split toggle to the diff view opened via `zed --diff
<old> <new>`, matching the toggle already available in git's diff views.
<details>
<summary>Click to view before/after</summary>
**Before**:
<img width="1920" height="1080" alt="screenshot_20260921_020610"
src="https://github.com/user-attachments/assets/92cbcf75-0cac-4555-8d2d-ce927064515f"
/>
**After**:
<img width="1920" height="1080" alt="screenshot_20260921_020355"
src="https://github.com/user-attachments/assets/56f9ebc6-11df-41cc-a44d-99bfa8caa130"
/>
</details>
---
Release Notes:
- Added a unified/split toggle to the diff view opened via `zed --diff
<old> <new>` command.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Preserve ordered mixed content in agent messages without disrupting text
streaming for existing native/v1 agents. The previous single-block
reduction could replace images with placeholders or lose non-text
content as subsequent chunks arrived.
- Introduce [ordered message display
content](https://github.com/zed-industries/zed/blob/929fba3e16f7a378eb1dca3d85ac2f1df2b902c6/crates/acp_thread/src/acp_thread.rs#L1500),
reusing adjacent text entities while retaining image/resource-preview
boundaries.
- Update rendering, text search, response copy/export, Mermaid cache
invalidation, and CLI output to visit the collection.
- Use block-local context menus and existing Markdown getters so copy
commands target the clicked part rather than another part's cached
state.
- Keep existing link/mention formatting, resource-button and blob-label
search behavior, compact prompt mentions, and original user-message
chunks.
- Preserve the separator between a leading resource link and subsequent
direct or streamed text.
Release Notes:
- N/A
# Objective
- Fix PowerShell discovery when Scoop is installed outside the default
`%USERPROFILE%\scoop` directory.
- Zed currently ignores Scoop's `SCOOP` environment variable, so it can
miss `pwsh.exe` and fall back to another shell.
## Solution
- Use the `SCOOP` environment variable as the Scoop root when it is set.
- Fall back to `%USERPROFILE%\scoop` when `SCOOP` is unset.
- Preserve the PowerShell discovery order and file validation from the
current `main` branch.
The original change also covered Git Bash. That is no longer needed
after #63339 changed Git Bash discovery to follow the active Git
installation.
## Testing
- `cargo fmt --all --check`
- `cargo test -p gpui_util` — 2 passed, 0 failed.
- `cargo check -p gpui_util --tests --target x86_64-pc-windows-msvc` —
passed.
- Did not runtime-test the Windows-specific path on this macOS host
because Windows test binaries cannot run natively here.
- To test manually on Windows, set `SCOOP` to a custom Scoop root
containing `shims\pwsh.exe`, launch Zed, and verify that PowerShell is
selected.
## 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 PowerShell installed by Scoop not being detected when Scoop uses
a custom installation directory.
- [GPUI] Fixed PowerShell discovery for custom Scoop installations on
Windows.
Signed-off-by: jliu666 <jliu666@hotmail.com>
Opening a file like `zed "\\server\share\file.txt"` leaves it with no
language servers attached, and the tab shows the ugly `\\?\UNC\...`
path.
The problem is the verbatim `\\?\UNC\` prefix Windows adds during path
canonicalization. We rely on dunce to strip these prefixes, but it
doesn't handle the UNC case, so the path stays in a form that breaks LSP
URL conversion.
Fixed by stripping the prefix ourselves in `SanitizedPath` before
handing off to dunce.
Before:
<img width="446" height="257" alt="Screenshot 2026-06-12 075128"
src="https://github.com/user-attachments/assets/4177e8de-8d13-42f1-a19b-d7dd52c10b32"
/>
After: (note the correct tooltip and the syntax error highlighting)
<img width="423" height="268" alt="Screenshot 2026-06-12 083651"
src="https://github.com/user-attachments/assets/83e98200-6bed-4a9e-b463-abbc067f6a5d"
/>
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)
— N/A, no UI changes
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable — one
extra string-prefix check per worktree creation
Release Notes:
- Fixed: language servers now run when opening files via UNC paths on
Windows (e.g. `\\server\share\file.txt`).
---------
Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com>
## Objective
Import VS Code’s `files.exclude` into `file_scan_exclusions`.
The previous `files.watcherExclude` mapping was dead code: it expected
an array, while VS Code stores an object of `pattern: bool`.
`files.watcherExclude` only stops watching, and the files stay visible
in VS Code, so it is not a match for `file_scan_exclusions`.
`files.exclude` hides files from the explorer and search, which matches
`file_scan_exclusions`, and its default set is nearly identical to
Zed's.
Related to #62769, reported during the review of #64484. A meta
follow-up to #64399.
## Solution
Import nonempty `files.exclude` patterns enabled with `true`, ignoring
disabled and malformed entries, including VS Code's `{"when": ...}`
form.
Append `"..."` so the imported list extends inherited exclusions instead
of replacing them.
Inputs with no usable patterns leave the inherited list unchanged.
`files.watcherExclude` is no longer imported.
## Testing
The new regression tests reproduce the bug and verify the fix.
To check manually, import
`{"files.exclude":{"**/build/**":true,"**/cache/**":false}}` and verify
that `file_scan_exclusions` becomes `["**/build/**", "..."]`, and that
`.git` stays hidden in the project panel.
## 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 importing VS Code `files.exclude` into `file_scan_exclusions`.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
## Objective
Prevent one invalid file pattern from discarding valid patterns or
causing settings loading to panic.
The pre-existing exclusion-matcher bug was reported during review of
#64492 (part of #64399).
## Solution
Ignore invalid entries individually and log their errors in
`file_scan_exclusions`, `file_scan_inclusions`, `file_types`,
`hidden_files`, `private_files`, and `read_only_files`.
Preserve valid inherited entries without changing `"..."`, replacement,
or empty list behavior. Valid brace inclusion patterns remain usable,
including when an alternative spans multiple directories.
## Testing
Reproduced matcher loss and inclusion and file type panic paths before
fixing them. Targeted tests pass on macOS for mixed, inherited,
replacement, empty, and all-invalid lists, including inherited `.git`
exclusions, private file protections, and inclusion rescans with brace
patterns.
Windows and Linux execution remains untested.
## 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 invalid file patterns discarding valid exclusions, hidden file
rules, or read-only rules, or causing inclusion settings to panic. Also
fixed invalid private file patterns discarding valid protections and
invalid file type patterns causing settings loading to panic.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
## Objective
Closing a GPUI window on macOS does not release that window's native
view tree, so every
open/close cycle leaves a `GPUIView`, its `CAMetalLayer` and the
renderer's command queue
alive in the process. A long-running app that opens and closes windows
grows without bound;
this is the mechanism described in #50737.
The reason is a retain cycle:
```
MacWindowState
-> accesskit_adapter (crates/gpui_macos/src/window.rs:710)
-> NSWindow.contentView (strongly retained by accesskit_macos)
-> GPUIView (a subview of that content view)
-> Arc<Mutex<MacWindowState>> in its ivar (back to the start)
```
`accesskit_macos::SubclassingAdapter::for_window` keeps a strong
`Id<NSView>` of the
window's content view, and both the `NSWindow` and the `GPUIView` store
an
`Arc<Mutex<MacWindowState>>` in their `windowState` ivar.
`MacWindow::drop` resets the
delegate and tears down the frame source and the visibility callback,
but nothing drops the
adapter, so the native view tree outlives the window.
Worth noting while reading the existing teardown:
`gpui_apple::metal_renderer::destroy()`
is currently a no-op (`crates/gpui_apple/src/metal_renderer.rs`), so the
`renderer.destroy()`
call that is already there is not evidence that GPU-side resources were
released — what
matters is whether the state that owns the renderer can run its
destructor at all.
## Solution
One line in `MacWindow::drop`:
```rust
let mut this = self.0.lock();
drop(this.accesskit_adapter.take());
this.renderer.destroy();
```
Nothing else in the teardown changes:
- `frame_source.take()` stays. `WindowFrameSource`'s `Drop` cancels
`frame_requests`, and
that dispatch source's context points at the native view, so it has to
be cancelled while
the view is still valid.
- `visibility_callback.take()` stays, as do the sheet handling and the
delegate reset.
- No view or layer is released by hand. The native view is already
handed to its parent view
via `autorelease`; the problem is the cycle, not the ownership.
## Testing
Done locally on macOS (aarch64), with `stable`:
- `cargo fmt -p gpui_macos -- --check` — clean.
- `cargo test -p gpui_macos --lib` — 7 passed, 0 failed.
- `cargo clippy -p gpui_macos --release --all-targets --all-features --
--deny warnings` — clean.
Note: the adapter is only created when Zed runs with
`ZED_EXPERIMENTAL_A11Y=1`, so the leak
only affects that path and the fix is a no-op otherwise.
What isn't covered:
- **No automated test.** The cycle needs a real `NSWindow`/`contentView`
pair, and the change
is a `Drop` impl; a unit test here would be testing `NSView` ownership
rather than this
crate's logic. `gpui_macos` has no window-lifecycle test harness today,
and adding one is
more than this fix should carry.
- **No memory measurement by me.** I did not run
Instruments/`Allocations` against this
change, and the minimal-repro numbers quoted in #50737 were measured on
a different fork
revision, not this one. So the leak here is established from the
ownership graph above
rather than from a footprint curve I produced. The follow-up that would
settle it is a
before/after count of live `GPUIView` / `CAMetalLayer` / command-queue
objects after closing
a window, with accessibility enabled and disabled; I have not run that,
and I am not
claiming this explains every memory-growth report.
- Only the macOS backend is touched, so there is nothing
Windows/Linux-specific here.
## 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 (UI/UX and icon
guidelines) — no UI change
- [ ] Tests cover the new/changed behavior — not applicable, see "What
isn't covered"
- [x] Performance impact has been considered and is acceptable
## AI disclosure
Built with substantial LLM assistance: I had help reading the
`accesskit_macos` and
`gpui_macos` ownership graph and drafting this description, and I
reviewed every line of the
diff myself. The change is one line plus a comment. English isn't my
first language, so the
prose here was machine-polished; happy to restate anything in plain
terms.
---
Release Notes:
- [GPUI] Fixed a memory leak on macOS where closing a window with
accessibility enabled left its native view, `CAMetalLayer` and the
renderer's resources alive.
- Fixed a memory leak on macOS where closing a window left its native
view, `CAMetalLayer` and the renderer's resources alive.
## Objective
Let projects add hidden file patterns without repeating defaults or
patterns inherited from user settings.
Part of
[#64399](https://github.com/zed-industries/zed/discussions/64399).
## Solution
Extend the `"..."` behavior from #62769, #64222, and #64440 to
`hidden_files`. `"..."` includes the resolved inherited list, omitting
it replaces the list, and `[]` clears it. Duplicate entries retain their
first occurrence.
The default remains `["**/.*"]`, and `project_panel.hide_hidden` still
controls visibility.
## Testing
Tested on macOS with settings merge, worktree integration, and Settings
Editor metadata tests.
To check manually, configure different user and project hidden file
patterns and enable `project_panel.hide_hidden`. Include `"..."` to
retain inherited patterns, then repeat without it and with `[]` to
verify replacement and clearing.
## 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 `"..."` in `hidden_files` so project settings can
extend inherited hidden-file patterns.
Following #41842, this is an extension to that contribution and it
enables `MicaBackdrop` and `MicaAltBackdrop` for
`"background.appearance"`
Release Notes:
- Add `MicaBackdrop` and `MicaAltBackdrop` to be selectable on themes
Additional Notes:
If PR is merged, theme schema should be updated to 0.2.1 or higher
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
## Summary
Fixes task variable resolution and Windows shell argument handling when
`$ZED_WORKTREE_ROOT` contains spaces or when tasks are spawned while the
global `tasks.json` buffer is focused.
## Problem
`$ZED_WORKTREE_ROOT` could resolve from the active editor item even when
that item was outside every visible project worktree, such as the global
`tasks.json` file under the Zed config directory. On Windows, paths with
spaces also need to remain one logical argument when terminal shell
commands are constructed.
## Changes
- Only let the active editor item provide the active task context when
it belongs to a visible project worktree.
- Fall back to the selected or first visible project worktree when the
active editor item is external/global.
- Preserve project-file-specific task variables for normal project
buffers.
- Add regression coverage for `$ZED_WORKTREE_ROOT` in `args` and `cwd`
with synthetic Windows-style paths containing spaces.
- Add regression coverage for PowerShell and cmd shell command
construction so a spaced path remains quoted as one shell argument.
## Testing
Ran on Windows with Rust 1.95.0, Visual Studio Build Tools 2022, and
Windows SDK 10.0.26100.0:
- `cargo fmt --all --check`
- `cargo test -p util
shell_builder::test::windows_powershell_preserves_spaced_arg_as_single_shell_argument
-- --exact`
- `cargo test -p util
shell_builder::test::windows_cmd_preserves_spaced_arg_as_single_shell_argument
-- --exact`
- `cargo test -p task
task_template::tests::test_worktree_root_with_spaces_stays_atomic_in_args_and_cwd
-- --exact`
- `cargo test -p tasks_ui
tests::test_non_project_active_editor_uses_visible_worktree_context --
--exact`
- `cargo test -p task`
- `cargo test -p tasks_ui`
- `cargo test -p workspace`
Release Notes:
- Fix Windows task path handling for worktree variables with spaces
- [GPUI] N/A
Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com>
# Objective
Opening a diff against a heavily drifted branch sits on a spinner until
every changed file has loaded. Blob reads were serialized through the
git job queue and enqueued in `open_buffer` completion order rather than
path order, so the blob for the first excerpt could be hundreds of jobs
deep.
## Solution
1. `load_blob_content` skips the job queue — blobs are
content-addressed, so the read doesn't depend on the status snapshot.
2. `DiffBuffer::load` is a lazy future instead of an eagerly-spawned
`Task`, so the consumer picks the concurrency.
3. `DiffMultibuffer` drives those loads through `buffered(16)`.
All three are needed: dropping the queue without bounding forks
thousands of `cat-file` processes, and bounding without dropping it
still serializes.
Trust handling is unaffected, since the untrusted-repo flags are applied
in `GitBinary::build_command` rather than by the queue.
Worth noting that `handle_get_blob_content` is remote-reachable, so a
guest can now put up to 16 `cat-file` processes on the host instead of
queueing them.
## Testing
Added `project_diff::tests::test_excerpts_are_ordered_by_path`, which
pins excerpt order to `PathKey` rather than to load completion order,
using more files than the concurrency limit and several executor seeds.
Green: `cargo test -p git_ui --lib` (131), `cargo test -p project --lib
git_store` (11), `./script/clippy`.
Not tested against a remote or collab project, which is where the
`handle_get_blob_content` change actually matters.
### Numbers
Zed repo against a base ~3000 commits back: 2346 changed files, 1794
with a blob at the merge base. Warm cache, one `cat-file` process per
blob, best of two runs at each concurrency.
| concurrency | total | per blob | speedup |
|---|---|---|---|
| 1 (previous behaviour) | 77.25s | 43.1ms | 1.00x |
| 2 | 17.74s | 9.9ms | 4.35x |
| 4 | 10.05s | 5.6ms | 7.69x |
| 8 | 7.34s | 4.1ms | 10.52x |
| 16 (this change) | 6.63s | 3.7ms | 11.65x |
| 32 | 6.59s | 3.7ms | 11.73x |
| 64 | 7.14s | 4.0ms | 10.82x |
16 is where the curve flattens: 32 buys another 0.7% and 64 regresses,
so there's nothing above it worth the extra in-flight buffers or the
extra concurrent processes on a host serving a remote peer.
At one blob at a time the first excerpt waits at an arbitrary position
in a 1794-deep queue, so roughly 38s on average, which lines up with the
45s full load in the recording below. It's now in the first batch.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments — none added
- [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
## Showcase
Opening a branch diff against a base ~3000 commits back, 2346 changed
files. Both clips are cut to 15s to keep the file size down — the before
run took 45s to finish loading.
**Before**
https://github.com/user-attachments/assets/d9475de8-ddd3-48a0-99e2-042a2f655b42
**After**
https://github.com/user-attachments/assets/0bf0e73d-0fac-4c2a-9749-71fee376f260
---
Release Notes:
- Improved how quickly a branch diff shows its first changes when the
branch has drifted a long way from its base
## Objective
Make the `"..."` convention easier to understand across the settings
that support it.
This is a meta follow-up to
[#64399](https://github.com/zed-industries/zed/discussions/64399),
establishing a documentation pattern that subsequent PRs can follow.
## Solution
Give each setting a succinct, self-contained explanation of `"..."`,
with matching wording and examples in its Rust doc comment and settings
reference:
- `file_scan_exclusions` • #62769
- `file_scan_inclusions` • #64440
- `read_only_files` • #64222
This keeps the explanation consistent across both surfaces and aligns
the content for future documentation generated from Rust comments.
## Testing
Built the docs locally on macOS and verified the examples, links, and
anchors. The existing settings merge tests pass.
## 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
## Objective
Related conversations can’t share an OpenAI cache key without also
sharing a thread ID. We currently derive `prompt_cache_key` directly
from `thread_id`, tying cache reuse to conversation identity.
## Solution
Add an optional `prompt_cache_key` to `LanguageModelRequest` and use it
in both OpenAI Chat Completions and Responses conversions. We still fall
back to `thread_id` when no key is supplied, so existing callers keep
their current behavior.
This lets callers share a cache key across parent and child
conversations while keeping their conversation and transport identities
separate.
## Testing
Added regression coverage for explicit keys, legacy fallback, provider
capability gating, and serialization compatibility.
## 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
Release Notes:
- N/A
# Objective
Fix memory a terminal never gives back after its command finishes.
Each `terminal::Terminal` constructed a `vte::ansi::Processor`, and
`Processor::new` reserves `SYNC_BUFFER_SIZE` (2 MiB) up front for
synchronized updates. `Terminal::release_pty_resources` tore the PTY
down once the command exited but left that reservation in place, so it
lived exactly as long as the terminal did.
That matters because the terminal outlives the command: the agent panel
keeps each tool call's terminal so it can keep rendering the finished
command's output (`ToolCallContent::Terminal(Entity<..>)`,
`acp_thread.rs:2014`), and the panel's own terminal map is only cleared
through `TerminalEvent::CloseTerminal`, which a task terminal never
emits because `SpawnInTerminal::default()` sets `hide =
HideStrategy::Never`.
Measured on a release build running 50 agent commands (`ls`): peak heap
205.34 MB, 200.52 MB still retained at exit, and the heap grew in a
staircase that never came back down (75 MB to 192 MB between 288s and
300s, then flat). heaptrack attributed the largest share, 104.00 MiB, to
exactly 52 of these reservations (109,051,904 bytes = 52 x 2,097,152),
all allocated from `TerminalBuilder::new`
(`crates/terminal/src/terminal.rs:1309`) and never freed.
So this costs roughly 2 MB per command for as long as its terminal is
kept around.
## Solution
- `output_processor` is only used by `Terminal::write_output`, which
parses bytes *injected* into the terminal (init commands, terminal
providers, the REPL). PTY output goes through the `alacritty_terminal`
event loop's own parser, not this one.
- Make the field an `Option`, create it on the first injected byte
instead of at construction, and drop it in `release_pty_resources`,
right after the PTY is torn down.
- It is recreated if something injects bytes again, so `write_output`
semantics do not change for terminal providers or init-command
injection.
As a side effect, terminals that never receive injected bytes no longer
reserve the parser at all, even while they are live.
## Testing
Added
`tests::test_release_pty_resources_drops_an_allocated_parse_buffer` in
`crates/terminal/src/terminal.rs`. It runs `echo` to completion in a
task terminal the way an agent tool call does, and asserts the parse
buffer's lifecycle directly on the terminal:
- a terminal that received no injected bytes holds no parse buffer;
- `write_output` builds one;
- `release_pty_resources` drops it, while the output the terminal
already captured is still readable;
- injecting again after the release builds a new one.
Asserting on the terminal's own state instead of on process-wide heap
keeps PTY reader threads out of the measurement: they reserve parse
buffers of their own and are torn down asynchronously, so a heap-based
assertion would depend on a timing the test cannot synchronize with.
Removing `self.output_processor = None` from `release_pty_resources`
fails the test with `releasing the PTY should drop the parse buffer`.
- `cargo test -p terminal`: 107 tests, all green.
- `./script/clippy -p terminal`: clean.
Tested on Linux. The fix and the test are platform-independent Rust
(neither is behind a `cfg`, and Windows takes the same
`TerminalType::Pty` branch), so I expect the same behaviour on macOS and
Windows, but I have not verified it.
## 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
## Suggested .rules additions
Found while working on this, proposed rather than edited inline, per the
rules-hygiene section.
- `webrtc-sys`'s build script never reuses its prebuilt download: on
every run it deletes the extracted package and re-downloads 131 MB from
the GitHub release, and every distinct unit gets its own `OUT_DIR` and
therefore its own copy (a debug build, a release build, and
rust-analyzer's `cargo check --all-targets` are at least three). A build
that appears to hang indefinitely at `webrtc-sys(build)` with no output
is this. Avoid it by extracting the release asset once outside `target/`
and setting `LK_CUSTOM_WEBRTC` to that directory through the user-level
cargo config, so rust-analyzer's background checks inherit it too:
```toml
# ~/.cargo/config.toml
[env]
LK_CUSTOM_WEBRTC = "/home/<user>/.local/share/libwebrtc/webrtc-0001d84-4/linux-x64-release"
```
`webrtc_sys_build::download_webrtc` returns early whenever that variable
is set. If the path goes stale (the prebuilt is tagged, e.g.
`webrtc-0001d84-4`), the build fails to link, so the variable has to be
updated when the tag changes.
---
Release Notes:
- Fixed terminals retaining about 2 MB of memory per command after the
command had finished
Move GPUI window/entity updates, view rendering, listener adapters,
arena allocation, and scheduler task setup into shared implementations.
Keep the generic entry points as thin adapters.
Uses pretty much the same technique prior PRs did, but this time on
`gpui` which I am not too confident about — can close it if seems
dangerous, but the binary strip win looks good to try.
`cargo llvm-lines --locked -p gpui`:
Before (bec63dee23): 934803 lines, 33225 copies
After: 926925 lines (-0.8%), 33454 copies (+0.7%)
With compiler wrappers disabled, `cargo clean --target-dir
target/binary-size-split-build` and `cargo build --locked -p zed`:
Before: 135.6s wall, 1569.8s CPU, zed binary 1175563800 bytes
After: 142.5s wall (+5.1%), 1589.0s CPU (+1.2%), zed binary 1144068952
bytes (-2.7%, -31.5MB)
Release Notes:
- N/A
- [GPUI] Shared GPUI and scheduler implementations to reduce the final
binary size of the app
## Objective
Let projects add inclusion patterns without repeating defaults or
patterns inherited from user settings.
Part of #64399.
## Solution
Extend the `"..."` behavior from #62769 and #64222 to
`file_scan_inclusions` using the shared merge implementation. `"..."`
includes the resolved inherited list, omitting it replaces the list, and
`[]` clears it. Duplicate entries retain their first occurrence.
Stop importing VS Code’s `files.watcherInclude` as inclusion patterns
because it configures additional watch roots rather than overriding Git
ignores.
## Testing
Tested on macOS with settings merge, VS Code import, and worktree
integration tests. Coverage includes preservation of the `.env*`
default, layered inheritance, replacement, clearing, and deduplication.
The worktree test verifies that inherited and project-specific patterns
include Git-ignored files while exclusions still take precedence.
To check manually, configure different user and project inclusion
patterns and add ignored files matching each. Include `"..."` to retain
inherited patterns, then repeat without it and with `[]` to verify
replacement and clearing. Confirm that excluded files remain absent.
## 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 `"..."` in `file_scan_inclusions` so project
settings can extend inherited inclusion patterns.
# Objective
- This PR fixes#63760. According to git docs "Patterns read from
$GIT_DIR/info/exclude".
## Solution
- We were reading the directory's absolute path instead of reading the
absolute path to the repository's common .git directory.
## 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:
- Fixed "Add to .git/info/exclude" not working when used from a
secondary git worktree
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Clear keyboard selection when clicking a terminal thread, as we already
do for agent threads.
The old test cleared selection itself instead of clicking a row. Replace
it with seven scoped tests:
| Test | Action | Expected result |
|---|---|---|
| Different terminal | Terminal A → click Terminal B | B active,
selection cleared |
| Same terminal | Terminal A → click Terminal A | A still active,
selection cleared |
| Different thread | Thread A → click Thread B | B active, selection
cleared |
| Confirm terminal | B active, A selected → Confirm | A active, A still
selected |
| Confirm thread | Thread A selected → Confirm | A active, A still
selected |
| Refocus without selection | Focus outside → sidebar | Search focused,
selection still empty |
| Refocus with selection | Focus outside → sidebar | List focused,
selection preserved |
Each click test starts with the source item active and
keyboard-selected, with the sidebar list focused so the keyboard
highlight is visible.
Before:
https://github.com/user-attachments/assets/eee8bc47-e962-402f-9268-8134dc20ba5b
After:
https://github.com/user-attachments/assets/a437f4c8-b2c0-47d8-99c6-c4600b49c359
Release Notes:
- Fixed the selection highlight flickering in the sidebar when clicking
terminal threads.
# Objective
Starting a new terminal thread from the agent sidebar creates **two**
terminals instead of one, in a project that has no terminals yet. With
terminals already open, only one is created.
## Solution
`Sidebar::create_new_terminal` calls `AgentPanel::new_terminal` and then
focuses the panel. The spawn is async, so when `focus_panel` activates
the panel, `base_view` is still `Uninitialized` — and
`ensure_thread_initialized` reads that as an empty panel and spawns its
own "initial" terminal on top of the one already in flight.
Once terminals exist they are restored at panel load, so `base_view` is
already `Terminal` and the second spawn never happens. That's why the
bug only appears on a project with no terminals.
`restore_terminal` already guarded against this by marking the spawn
pending before calling `spawn_terminal`. This moves that marker into
`spawn_terminal` itself, so every spawn path arms it, and drops the
now-redundant assignment in `restore_terminal`. The marker is cleared
exactly where it already was: when the terminal lands, when the spawn
fails, and when the terminal is closed.
## Testing
- Added `test_new_terminal_prevents_initial_terminal_creation`, which
reproduces the sidebar's spawn-then-focus sequence. It fails without the
fix (the panel ends up with two terminals) and passes with it.
- `cargo test -p agent_ui --lib` — 405 passed.
- `cargo test -p sidebar --lib` — 142 passed.
- `./script/clippy -p agent_ui` — clean.
- Tested on macOS only. The race is platform-independent, but I can't
exercise the Linux/Windows terminal spawn paths.
## 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 agent panel creating two terminals when starting a new
terminal thread in a project with no existing terminals
---------
Co-authored-by: Claude Opus 5 <claude-opus-5@claude-cli>
## Objective
Make GPT-6 Astra selectable through the OpenAI API-key provider. The
built-in catalog omitted it, even though it was available through the
separately fetched ChatGPT subscription catalog.
## Solution
Add `gpt-6-astra` with its documented context/output limits, reasoning
efforts, image support, and Responses capabilities. Existing model
defaults remain unchanged.
Handle two API compatibility differences found during review: Astra
rejects `temperature`, and its Fast-mode responses return `service_tier:
"fast"` even when requested as `"priority"`. Both request converters now
omit Astra's temperature, and response decoding accepts the new spelling
while preserving legacy serialization. Two focused regressions cover
these failures without duplicating the catalog declaration.
References: [Astra
model](https://developers.openai.com/api/docs/models/gpt-6-astra),
[migration
guide](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6-astra),
[Fast mode](https://developers.openai.com/api/docs/guides/fast-mode).
## Testing
- `corgi test -p open_ai --lib`: 88 passed.
- `corgi check -p language_models --lib`: passed.
- `corgi fmt -p open_ai -p language_models -- --check` and `git diff
--check`: passed.
- Live API probes confirmed model availability, a successful Responses
function-tool call with parallel calls enabled, the `fast` response
spelling, and rejection of configured temperature.
- During development, Delta's existing API-key catalog test passed with
a temporary local dependency override and an Astra frontier expectation.
The override was removed; Delta's dependency bump is separate.
- Validation was on macOS. No interactive picker, browser, or Cloud
Runner workflow was exercised; image input, compaction, and Fast-mode
regional availability were checked against the docs rather than live
workflows.
## Before merge
The README contains the repository-required human-review confirmation
marker. The author must remove it after reviewing. Delta will need a
separate dependency bump after this change lands. Cache-preserving
reasoning-effort updates are outside this change.
Release Notes:
- Added GPT-6 Astra to the OpenAI API-key model picker.
# Objective
Fixes#62522
`cargo xwin` fails to find the GPUI Windows manifest because `llvm-rc`
resolves the path from the resource directory.
## Solution
Reference the manifest relative to `gpui.rc` and explicitly add the
resource directory to the include paths. This keeps both native Windows
and xwin builds working.
## Testing
- Tested with `cargo xwin clippy --target x86_64-pc-windows-msvc`
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
- [GPUI] N/A
---------
Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com>
yenru0
