Rather than continuing to try to persuade Claude to pretty please only
output json, or to parse json out of Claude's prose, switch to forced
tool calls with a json schema and hope this works better.
And bump the version of the bot to 4 since the model upgrade which was
shipped earlier today is evidently behaving differently enough.
Release Notes:
- N/A
Manage various LLM settings (previously in agent panel) in settings UI.
Behind a feature flag, not staff shipped
Release Notes:
- N/A or Added/Fixed/Improved ...
Include the changed paths in `UpdatedEntries` events emitted by remote
worktrees.
Previously a remote worktree emitted `Event::UpdatedEntries` with an
empty changeset (`Arc::default()`), discarding the changed paths. The
changeset now carries the real added/updated/removed paths, resolving
removed entries against the previous snapshot.
Release Notes:
- Fixed file change events not reporting changed paths in remote
projects
Follow-up to #58962 addressing review feedback on the quit-time thread
flush.
The flush now builds its save payloads through the same helper as
`save_thread`, so the two write paths can't drift — in particular, the
flush now captures the current draft prompt the same way ordinary saves
do, instead of writing whatever stale draft was last serialized. It also
logs database connection errors instead of silently discarding them, and
runs the per-thread saves concurrently, since all quit observers share
gpui's 200ms `SHUTDOWN_TIMEOUT` and serial saves risked a partial flush.
The regression test now quits through the real `App::shutdown` path, so
the `on_app_quit` registration itself is exercised rather than just the
flush method, and it additionally covers draft-prompt capture and the
empty-thread skip.
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#57888
Commit `c19cc4c51e` introduced the bug on
#50412 . This change modified the `remove_path` function to also remove
the path from the watcher:
f0341c96a1/crates/worktree/src/worktree.rs (L3218-L3220)
And when a user modified the global setting and doesn't include `.git`
in it, like:
```jsonc
// ~/.config/zed/settings.json
{
"file_scan_exclusions": ["foo"]
}
```
But then includes it on their local project settings:
```jsonc
// ~/my/local/project/.zed/settings.json
{
"file_scan_exclusions": ["**/.git"]
}
```
It causes zed to stop watching for changes on `.git`
Release Notes:
- Fixed bug where zed stopped watching change on `.git` directory if it
was added to the project local `file_scan_exclusions`
This removes gpui's dependency on the `util` crate, which depends on
async process. It now depends on `gpui_util` only, and uses
`std::process::Command` for the two cases where it was previously using
an async `Command`. This lifts the requirement of non-Zed consumers of
gpui to depend on our forked async-process (see #59156).
Release Notes:
- N/A
Adds provider-side context compaction support to the Anthropic and
OpenAI API clients. Client plumbing only; not wired into the UI.
Release Notes:
- N/A
The GitHub workflow was sometimes failing when someone edited the
already-merged PR that had been archived on the board because archived
items can't have their fields changed. The project board fields don't
need to be updated when the PR is already merged or closed.
Release Notes:
- N/A
claude-sonnet-4-20250514 was retired by Anthropic on June 15, 2026,
causing the "Comment on potential duplicate bug/crash reports" workflow
to fail with a 404 from /v1/messages on the first call_claude
invocation.
Switch to the recommended replacement, claude-sonnet-4-6.
Release Notes:
- N/A
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Co-authored-by: Martin Ye <martin@zed.dev>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
# Objective
- Renaming a folder whose name contains a dot pre-selects only the text
before
the last dot, treating the suffix as if it were a file extension.
- Fixes#59294
## Solution
- `ProjectPanel::rename_impl` computed the rename editor's initial
selection with
`Path::file_stem().len()` for every entry. For a directory such as
`my.folder`,
`file_stem()` returns `my`, so only `my` was selected.
- Directories have no extension, so select the whole name for them.
Files keep
the existing behavior (the last extension is left unselected for quick
renames).
## Testing
- Added `test_rename_folder_with_dot_selects_whole_name` in
`project_panel_tests.rs`.
It fails before the change (folder selection ends at offset 2 of
`my.folder`) and
passes after (offset 9, the whole name); it also asserts a file still
leaves the
last extension unselected.
- `cargo test -p project_panel` — all 100 tests pass.
- `cargo clippy -p project_panel --all-targets --all-features -- --deny
warnings` and
`cargo fmt -p project_panel -- --check` are clean.
## 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 and icon
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed renaming a folder with a dot in its name selecting only the part
before the dot.
---------
Co-authored-by: Finn Evers <finn.evers@outlook.de>
# Objective
When reviewing changes in the Git Panel, the only ways to open a file
were through a diff view ("Open Diff" or "Open Diff (File)"). There was
no way to open the file directly in the editor to inspect or edit its
current contents without entering a diff.
This PR adds a **View File** action to the Git Panel changes list
context menu.
## Solution
- Add a `git::ViewFile` action in `crates/git/src/git.rs`, alongside
other per-file git actions like `FileHistory`.
- Wire it into the Git Panel file context menu, between the diff actions
and "View File History".
- Implement `GitPanel::view_file` to resolve the selected entry's repo
path to a project path and open it via `workspace.open_path_preview`,
matching the pattern used in `commit_view::open_file_at_head`.
- Document the new action in `docs/src/git.md`.
### Related issues
- https://github.com/zed-industries/zed/issues/58250
## Testing
- Added three GPUI tests in `git_panel.rs`:
- `test_view_file_tracked` — modified tracked file
- `test_view_file_untracked` — untracked file
- `test_view_file_tree_view` — nested file in tree view
- Ran `cargo test -p git_ui test_view_file` — all three pass.
- Ran `./script/clippy -p git_ui` — clean.
**Manual testing for reviewers:**
1. Open a project with changed files and open the Git Panel.
2. Right-click a changed file and select **View File**.
3. Confirm the file opens in the editor (not a diff view).
4. Repeat for an untracked file and with tree view enabled.
5. Confirm **Open Diff** and **Open Diff (File)** still work.
Tested on macOS only. Linux and Windows should behave the same since
this is a context menu action with no platform-specific code, but I
haven't verified on those platforms.
## 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
<details>
<summary>Click to view showcase</summary>
Video recoding of the Git Panel context menu showing the new **View
File** item:
https://github.com/user-attachments/assets/c878fd4d-9acb-4c05-bd91-b452da0a6b90
</details>
---
Release Notes:
- Added "View File" to the Git Panel context menu to open a changed file
in the editor without a diff view.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
When a setting was reset to its default while its input field was
focused, the field kept showing the old value. The reconciliation that
syncs the editor with the current setting value now handles cleared
(null/empty) defaults and reconciles focused fields when they have no
unsaved edits, so the field clears as expected.
Release Notes:
- Fixed settings input fields not clearing when a setting was reset to
its default while the field was focused
Follow-up to #58996. The "Remove Worktree from Window" button captured
the row index at render time and re-resolved it against the picker's
matches at click time. Matches are rebuilt asynchronously (initial
worktree list load, post-delete refresh, query changes), so the index
could drift between the rendered frame and the click being processed,
closing the workspace of a different worktree than the one the user
clicked.
This changes the click handler to capture the worktree's path — a stable
identity — instead of its index, adds the same `deleting_worktree_paths`
click-time guard the neighboring handlers use, and constructs the button
only when it will actually be shown.
Scoped to the code added in #58996; the same stale-index pattern in the
delete and open-in-new-window handlers is left for a later change.
Release Notes:
- Fixed an issue where the worktree picker's "Remove Worktree from
Window" button could act on the wrong worktree if the list updated at
the moment of the click.
## Summary
- Show the command being approved in sandbox permission prompts even
when no specific write paths are requested
- Keep the existing network and write-path details alongside the command
## Validation
- rustfmt crates/agent_ui/src/conversation_view/thread_view.rs
- cargo check -p agent_ui
Release Notes:
- Improved sandbox permission prompts to show the command being
approved.
This makes unrestricted sandbox network access an explicit sandbox mode
instead of a fallback when the enforcing proxy is unavailable.
Host-specific network access still uses the proxy, while approved
arbitrary network access skips proxy setup and maps directly to
unrestricted egress.
Release Notes:
- Improved agent terminal sandbox network permission handling.
---------
Co-authored-by: Martin Ye <martin@zed.dev>
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Final PR of a four-PR stack adding hostname-allowlisted network access
to agent terminal sandboxing. Stacked on #59219 — review/merge #59217,
#59218, and #59219 first.
Spawns the `http_proxy` allowlisting proxy for sandboxed terminal
commands that request network, and pins the Seatbelt policy to its
loopback port (`NetworkAccess::LocalhostPort`) so all egress is forced
through it. The child's proxy environment variables are pointed at the
proxy and any inherited `NO_PROXY` is blanked so nothing connects
direct; a real upstream proxy from the environment is chained through
when present. The proxy and its Seatbelt config file share one RAII
handle so both live exactly as long as the command, and per-connection
events are drained to the log.
The proxy binds loopback, so it only applies to local projects on macOS;
elsewhere the wrap falls back to unrestricted egress as before (the
agent layer widens such requests accordingly).
Release Notes:
- Added the ability to grant agent terminal commands network access to
specific hosts (rather than all-or-nothing), enforced by an allowlisting
proxy.
---------
Co-authored-by: Martin Ye <martin@zed.dev>
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
- **collab: Don't revoke LiveKit token when rejoining the same channel**
- **call: Bound LiveKit reconnect attempts and decouple from collab
rejoin**
# Objective
- Describe the objective or issue this PR addresses.
- If you're fixing a specific issue, use "Fixes #X" for each issue as
[described in the GitHub
docs](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword).
## Solution
- Describe the solution used to achieve the objective above.
## Testing
- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
## Showcase
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- N/A or Added/Fixed/Improved ...
Third of a four-PR stack adding hostname-allowlisted network access to
agent terminal sandboxing. Stacked on #59218 — review/merge #59217 and
#59218 first.
Replaces the boolean `allow_network` terminal-sandbox escalation with a
hostname allowlist. The `terminal` tool now takes `allow_hosts` (exact
hostnames or leading-`*.` subdomain wildcards, validated up front) and
`allow_all_hosts` as a broad escape hatch. Approval prompts name the
requested hosts, thread grants and persistent "allow always" settings
cover requests via host-pattern subsumption the same way write paths use
subtree containment, and the authorization card in the agent panel lists
the requested hosts.
Host allowlists aren't enforced yet in this PR: `SandboxWrap` carries
the allowlist, but any network request still maps to unrestricted egress
at the Seatbelt layer, matching previous behavior. Enforcement via the
in-process proxy lands in the final PR of the stack. All of this is
behind the existing sandboxing feature flag. For non-local projects
(where the loopback proxy won't apply), host requests are widened to
"arbitrary network access" before prompting so approvals match
enforcement. Old persisted `network: bool` authorization details still
deserialize via a serde alias.
Release Notes:
- N/A
---------
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Co-authored-by: Martin Ye <martin@zed.dev>
Fourth PR of the stack adding hostname-allowlisted network access to
agent terminal sandboxing. Stacked on the `http_proxy` crate PRs
(#59217, #59222, #59223) — review/merge those first; this PR's diff is
only the sandbox change.
Replaces the `allow_network: bool` field on the macOS Seatbelt
`SandboxPermissions` with a `NetworkAccess` enum: `None` (block all
egress), `All` (the previous `allow_network: true` behavior), and
`LocalhostPort(u16)`, which confines a sandboxed command to a single
loopback port. The new variant emits a Seatbelt rule permitting outbound
TCP only to `localhost:<port>` and isn't constructed yet; it exists to
pin sandboxed commands to the in-process network proxy in a later PR.
The sole consumer maps its existing boolean to `All`/`None`, so behavior
is unchanged.
Release Notes:
- N/A
Closes AI-404
This PR fixes a flicker that was happening when clicking on an empty
draft thread item in the sidebar, given we were going through the whole
regular activation flow despite the thread already being active. So, the
fix here was just extracting a boolean so we can identify whether the
thread is active in the workspace and if so, not doing nothing in the
on_click handler of the thread item.
Release Notes:
- Sidebar: Fixed a flicker when clicking on an empty draft thread.
Third of the `http_proxy` stack. Stacked on #59217 and the
upstream-config PR — review/merge those first.
Adds the in-process HTTP/HTTPS proxy server that enforces an
`Allowlist`. It speaks HTTP CONNECT for HTTPS tunnels and forward
proxying for plain HTTP, vets resolved addresses against
loopback/private/link-local ranges to prevent DNS-rebinding past the
sandbox, pins each connection to the destination approved for its first
request (so later keep-alive requests can't escape the policy decision),
optionally chains through the upstream proxy, and bounds header sizes,
connection counts, and connect/handshake waits since its sole client is
untrusted model-driven code running inside the editor process. Includes
end-to-end tests covering allowed/denied CONNECT and HTTP forward,
IP-literal handling, DNS-rebinding denial, and upstream chaining.
Still has no callers; wired into the agent terminal sandbox in the
remaining PRs of the stack.
Release Notes:
- N/A
---------
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Second of the `http_proxy` stack. Stacked on #59217 — review/merge that
first; this PR's diff is just the upstream-proxy config.
Adds `UpstreamProxy`: parsing of an upstream HTTP proxy from the
environment (`HTTPS_PROXY` / `HTTP_PROXY` / `ALL_PROXY` and lowercase
forms) with `NO_PROXY` bypass matching delegated to the `proxyvars`
crate, basic-auth credentials kept out of `Debug`/`Display`, and
IPv6/default-port normalization. The proxy server (next PR) uses this to
chain outbound connections through a corporate proxy when one is
configured.
Release Notes:
- N/A
Summary:
- Include terminal command text in sandbox authorization metadata.
- Render the command in sandbox permission prompts, including prompts to
run outside the sandbox.
- Keep write-path details visible alongside the command when both are
present.
Tests:
- cargo test -p agent sandbox
- cargo check -p agent_ui
Release Notes:
- Improved agent sandbox permission prompts to show the command being
requested.
First of a stack adding hostname-allowlisted network access to agent
terminal sandboxing. Adds a new `http_proxy` crate containing only the
allowlist policy types.
`HostPattern` parses exact hostnames or leading-`*.` subdomain
wildcards, normalizes IDNs to punycode, and rejects IP literals and
localhost-family names. `Allowlist` holds a set of patterns (or an
allow-any escape hatch), and `covers` implements host-pattern
subsumption (`*.github.com` covers `api.github.com`) used later to
decide when an already-granted permission covers a new request — the
network analogue of write-path subtree containment.
Pure, self-contained logic with no callers yet. The upstream-proxy
config and the proxy server that enforces these policies land in the
next two PRs.
Release Notes:
- N/A
Previous versions of the tool required passing the diff back because the
parent agent wouldn't have known the edits applied otherwise. Given that
we adapted this to use streaming tool calls now, this is redundant
information and wastes context windows, especially for local models.
We still pass the diff in the case that only some of the edits were
applied, but in the successful case, we just let the model know that the
edit was successful.
---
Release Notes:
- agent: Improve edit tool performance with more succinct success
response.
When a Zed Business organization hits its token spend limit, the agent
panel told the user to "check that your API key has access to this
model", and did not display the error message returned by the server.
The message about checking your API key was the generic 401 and 403
error for all language model providers. This is also incorrect in
general since there are no API keys involved in the Zed and ChatGPT
Subscription providers.
So this commit changes the message for authentication errors (401s) to
be provider-specific, with the current message about invalid API key as
the default, and overrides for the providers that don't use API keys.
And the authorization error messages (403s) now include the server error
message. So the spend-limit case now reads "Permission Denied —
Token-based spending limit reached." instead of talking about API keys.
<img width="1888" height="426" alt="grafik"
src="https://github.com/user-attachments/assets/cf9e07cd-66f0-4f8d-828c-79b875edcf2d"
/>
Telemetry event names (`invalid_api_key`, `no_api_key`) are kept
unchanged to avoid breaking existing dashboards.
Release Notes:
- Fixed agent panel errors telling users to check their API key when the
provider doesn't use one (Zed account, ChatGPT subscription). Permission
errors also now show the provider's actual message.
The work introduced in https://github.com/zed-industries/zed/pull/54496
updated the `command_aliases` schema, adding support for auto-completion
action names when editing the settings file. However, it didn't take
into consideration the case where the user is simply creating an alias
to an arbitrary string.
These changes introduce a new `CommandAliasTarget` newtype for which the
json schema is either a registered action name, from `ActionName` or any
arbitrary string, as those are supported by the `command_aliases`
setting.
Updating the `ActionName` schema to accept any arbitrary string would
break the guarantees we have on the keymap binding schema, so that's why
a new schema was introduced.
Lastly, trying to set `CommandAliasTarget::json_schema` to a simply
`anyOf` with either the registered action name or a string that is not a
registered action name, like shown below, broke deprecation warnings,
hence why we're still doing the approach of only building
`CommandAliasTarget` at runtime.
```json
{
"anyOf": [
{ "$ref": "#/$defs/ActionName" },
{ "type": "string", "not": {
"$ref": "#/$defs/ActionName"
}},
]
}
```
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed validation of `command_aliases` setting to avoid showing
warnings when aliasing to an arbitrary string
For the extension devs:
Adds a `RebuildDevExtension` action that triggers a rebuild of an
installed dev extension.
- If no dev extensions are installed, shows an error notification.
- If exactly one dev extension is installed, rebuilds it immediately.
- If multiple dev extensions are installed, opens a fuzzy picker to
select which one to rebuild.
Makes it easy for devs to trigger a rebuild with a keymap once an action
is defined with this PR.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- Added `RebuildDevExtension` action to rebuild installed dev extensions
from the command palette
<img width="675" height="310" alt="Screenshot 2026-04-29 at 1 49 54 AM"
src="https://github.com/user-attachments/assets/dbf618f7-f590-40aa-bc5c-580eea9f0001"
/>
<img width="623" height="329" alt="Screenshot 2026-04-29 at 1 50 16 AM"
src="https://github.com/user-attachments/assets/b4bb4131-924f-442b-8351-528a87698399"
/>
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
## Context
Sticky scroll was anchoring multiline signatures to the first outline
context row instead of the row containing the symbol name, which could
leave the sticky header showing unhelpful context. This change carries
each outline item’s `selection_range` through the tree-sitter, LSP,
multi-buffer, and editor paths, then uses that range to choose the
sticky header row.
This is intended to improve sticky scroll generically, not only for one
language. It should help wherever symbol data distinguishes the symbol
name from the larger symbol range:
- tree-sitter outlines that provide a distinct `@name` capture
- LSP document symbols whose `selectionRange` is more precise than
`range`
The actual improvement is still language-dependent, because it relies on
the quality of each language’s outline query or language server symbol
metadata.
Closes#55587
Manual video of the test :
[Screencast from 2026-05-10
14-05-46.webm](https://github.com/user-attachments/assets/40f327d3-cab2-4b85-887b-08b541a102bf)
## How to Review
`crates/language/src/outline.rs`, `crates/language/src/buffer.rs`, and
`crates/language/src/buffer_tests.rs`: Adds `selection_range` to
tree-sitter outline items and verifies that multiline signatures can
anchor sticky scroll on the symbol-name row while preserving the
existing displayed outline text.
`crates/project/src/lsp_store/document_symbols.rs`: Threads LSP document
symbol `selection_range` into `OutlineItem`, keeping enriched labels and
highlight ranges intact while preserving the distinction between the
full symbol range and the selected name range.
`crates/multi_buffer/src/multi_buffer.rs`,
`crates/editor/src/document_symbols.rs`, `crates/editor/src/editor.rs`,
`crates/outline/src/outline.rs`, and
`crates/outline_panel/src/outline_panel.rs`: Propagates
`selection_range` through the places that remap outline items between
buffers, multi-buffers, editors, and outline views.
`crates/editor/src/element.rs` and `crates/editor/src/editor_tests.rs`:
Uses `selection_range` when computing sticky header rows and adds a
regression test covering a multiline signature case from the issue.
`crates/language/Cargo.toml` and `Cargo.lock`: Adds `tree-sitter-c` for
the language-level regression test fixture.
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the UI/UX checklist
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed sticky scroll anchoring to unhelpful context rows for multiline
signatures when symbol metadata provides a more precise name range.
On Windows, `util::process::Child::kill()` only terminated the direct
child process, and nothing tied the lifetime of spawned process trees to
Zed. External agent servers launched through ACP (e.g. `claude-code-acp`
via `npx`) spawn node workers and MCP servers as grandchildren, which
were orphaned on every session teardown and accumulated indefinitely —
hundreds of idle `node.exe` processes and GBs of RAM over days.
This PR assigns spawned processes to a Win32 job object configured with
`JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE`:
- `kill()` now calls `TerminateJobObject`, killing the entire tree
instead of just the (shell wrapper) child.
- Dropping `Child` closes the job handle, which makes the OS reap the
tree — including when Zed exits for any reason (even crashes), since the
OS closes its handles.
- Unix behavior (process groups via `killpg`) is unchanged.
Added two Windows tests that spawn a real `powershell -> ping` process
tree and assert the grandchild is terminated on `kill()` and on drop.
Both fail without the fix and pass with it. Verified with `cargo test -p
util`, `script/clippy -p util`, and `cargo check -p agent_servers -p
dap` on Windows 11.
Closes#58873
Release Notes:
- Fixed external agent servers and debug adapters leaking helper
processes (e.g. node workers and MCP servers) on Windows.
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Closes AI-393
When the user proactively cancels a turn, we mark all pending entries as
cancelled. But if something else stops/halts a turn, we weren't doing
that in the case of compaction, which means we would be stuck in a
loading state forever.
Release Notes:
- N/A _(feature hasn't been publicly released yet so no notes)_
Currently zed runs `git rev-parse HEAD` and `git show` sequentially to
get the git `HEAD` state in `compute_snapshot`.
`git show` already natively resolves the `HEAD` commit so we can
retrieve all info in a single process spawn which speeds things up and
removes one git background process.
Followup on #59042 in the hope to improve performance of working with
large git repos over SSH.
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 performance of git HEAD state resolution
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
When uncommiting we check whether the commit already exists on a remote
branch. This currently spawns a lot of git processes to do so,
especially when having multiple remotes.
This PR switches this to a single `git for-each-ref` call to do the same
checks. I tested this in the UI and added some unit tests to verify this
behaviour.
This is a followup on #59053, #59044 and #59042 with the goal to reduce
overhead of the git handling.
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 performance of git uncommit
## Solution
- A simple find and replace.
## Testing
- Did you test these changes? If so, how? No, as in my opinion, a single
character change in a string does not justify the time it takes to
recompile
- Are there any parts that need more testing? No.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know? Just open the models UI.
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [X] Unsafe blocks (if any) have justifying comments
- [X] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [X] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
---
Release Notes:
- Edit name of Gemini 3.1 Flash Lite to Gemini 3.1 Flash-Lite to better
match Google's official documentation
# Objective
Fixes#54882:
When selecting a project group that has a remote host (SSH, WSL, Docker)
from the window project picker, or when closing/removing a workspace
with a remote neighbor group, the code was unconditionally calling
find_or_create_local_workspace. This created a local project with the
remote server's paths, producing a 'ghost' project where language
servers and file watchers fail trying to access paths that don't exist
locally.
## Solution
Three locations fixed:
1. RecentProjectsDelegate::confirm (recent_projects.rs) - window project
picker selecting a ProjectGroup entry. Routes to
find_or_create_workspace with connect_with_modal for remote hosts.
2. MultiWorkspace::close_workspace (multi_workspace.rs) - closing a
workspace whose neighboring group is remote. Falls through to the empty
workspace fallback instead of creating a ghost project.
3. MultiWorkspace::remove_project_group (multi_workspace.rs) - removing
a project group whose neighbor is remote. Same fallback.
All three detect remoteness via key.host().is_some() and skip
find_or_create_local_workspace when set.
Includes regression tests for all three paths using mock remote
connections.
## Testing
- Not yet tested with a custom build
- Unit tests added
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
---
Release Notes:
- Fixed ghost project appearing in the window project picker and sidebar
when switching between local and remote projects.
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Update the toast shown after running `git: push` so as to always include
a button to create a pull request for the current branch.
We used to only do this on the initial push, as that is when the output
of running `git push` would include an URL that could be used to create
the Pull Request. However, since we now have a `git: create pull
request`, we can always build this URL, meaning we no longer need to
rely on the command's output in order to display the "Create Pull
Request" button.
Something worth noting is that the
`git_ui::remote_output::format_output` function used to also match on
Bitbucket's terminal output, so these changes include the implementation
of `GitHostingProvider::build_create_pull_request_url` for the
`Bitbucket` provider.
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:
- Improved the toast shown after `git: push` to always display the
"Create Pull Request" button
I noticed while working on a personal project which derives some logic
from the core Zed stack that I was getting very unexpected results out
of BufferChunks::next when walking through formatted chunks.
The code calculates the mask for the `tabs`, `chars`, and `newlines`
masks incorrectly, making the mask far too large when we are extracting
chunks when chunk_start != 0.
I believe the reason that this isn't a problem in Zed is that the
InlayMap ends up re-masks all the bitmasks before passing things up the
stack, so covers up the problem, preventing it from causing any damage.
It appears this isn't caught in tests because this only happens when
extracting chunks with formatting, during which we offset our retrieval
by next_capture_start, and the current chunks tests don't use
formatting.
I think the fix is sound. The test is maybe not super ideal, but I
wanted to demonstrate the issue in the pull request.
If we process the following text by chunks:
```rust
use std::cmp::Eq;
```
The first chunk is 'use ' with the chars mask being 0b1111. The second
chunk is 'std' with the chars mask being 0b1111111 when it should just
be 0b111.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments (N/A — docs only)
- [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 (N/A — docs only)
- [x] Performance impact has been considered and is acceptable
Documents the `llvm-objcopy --strip-debug` step that
`script/bundle-linux` runs after `cargo build`. Without it, self-built
`remote_server` binaries are ~462 MB instead of ~62 MB and behave
differently from the prebuilt downloads.
Two contributors converged on the same fix in the issue thread; this PR
is a docs-only version of their suggestion, plus the musl/static variant
that `script/bundle-linux` actually uses for the official Linux release.
Closes#56939
Release Notes:
- N/A
AI was used for assistance.
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
I came across this while tackling another block map sync issue.
When a block is anchored past the point where its line soft wraps,
inserting or removing it invalidated the wrong range of rows. Inserting
such a block alone could silently not show it, and removing it could
leave the block on screen.
To reproduce:
```sh
SEED=113 ITERATIONS=1 cargo test -p editor test_random_blocks
```
Release Notes:
- Fixed inline assistant prompt sometimes not appearing, or lingering
after dismissal, when that line was soft-wrapped.
## Context
Dragging a file from the Project Panel into the agent composer was
appending the generated file mention to the end of the prompt instead of
inserting it at the active caret position. This change routes dragged
file insertion through the same caret-based mention insertion path
already used for pasted external paths, so dropped file and directory
mentions are inserted inline where the user is typing.
Closes#55002
Video of the manual test below :
[Screencast from 2026-04-29
01-13-59.webm](https://github.com/user-attachments/assets/9d2196fb-accd-4f4a-a9c0-0ce45b212121)
## How to Review
-
[crates/agent_ui/src/message_editor.rs](/home/saber/coding/zed/crates/agent_ui/src/message_editor.rs)
removes the separate end-of-buffer insertion mode from
`insert_mention_for_project_path`, updates `insert_dragged_files` to use
the shared caret-based insertion flow, and adds regression tests
covering single-file and multi-file drag insertion order at the cursor.
The existing paste-at-cursor behavior remains covered by the
pre-existing test in the same module.
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the UI/UX checklist
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed dragged file mentions in the agent composer being appended to
the end of the prompt instead of inserted at the cursor
Co-authored-by: Richard Feldman <richard@zed.dev>
Retrieving the default branch currently spawns up to 5 git processes
sequentially which isn't ideal.
This PR switches to a `git for-each-ref` and `git config` call to do the
same checks while requiring spawning less git processes. I tested this
in the UI and added a unit test to verify that the behaviour doesn't
change.
This PR follows the approach from #59069.
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 performance of retrieving default git branch
Currently Zed fetches remote URLs by sequentially calling `git remote
get-url origin` and `git remote get-url upstream`.
This PR introduces a new `remote_urls` function which uses `git remote
-v` to retrieve all remote fetch URLs with a single git process.
Followup on #59042 and #59042 in the hope to reduce the amount of
spawned git processes.
Probably best to review both commits separately.
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 performance of listing git remotes
Currently `git stash list` will run on every `paths_changed` event e.g.
every time files are modified or saved.
This is unnecessary since the git stashes will only change when a `git
stash` command is run. Which can either happen from within Zed or from a
terminal. Changes there are already tracked by monitoring
`.git/logs/refs/stash`.
I verified that Zed's git stash view still works as expected.
I'm noticing that Zed performs very badly when working with a large git
repo via SSH remote development. In particular I've noticed bad
performance when working with https://github.com/pytorch/pytorch which
includes lots of submodules.
I'm hoping that this PR will reduce the amount of git processes and
hopefully make it more responsive without having to manually add folders
to `file_scan_exclusions`.
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:
- Reduce git processes run on every file change
