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
Addresses https://github.com/zed-industries/zed/discussions/33773.
This changes git panel file activation so double-clicking or
secondary-opening a changed file opens a dedicated full-file diff tab
backed by a `SplittableEditor`.
The per-file diff reuses the project diff staging and restore controls,
respects the configured diff view style, and focuses an existing
per-file diff tab when one is already open instead of creating
duplicates.
Verified with `cargo run`.
Release Notes:
- Improved git panel file diff opening.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
References
[FR-28](https://linear.app/zed-industries/issue/FR-28/task-modal-does-not-show-runnable-rust-test).
The bug this PR aims to fix is
> I can click the play button beside a rust test function, but it does
not show up in the task modal.
I wasn't able to reproduce it, but I suspect this was caused by the task
system preferring LSP code actions by default. It checked that an LSP
was queried for a task instead of checking if the queried LSP actually
returned any tasks. So the fix was just adding the below if statement as
a check.
```rust
if !new_lsp_tasks.is_empty() {
lsp_tasks
.entry(source_kind)
.or_insert_with(Vec::new)
.append(&mut new_lsp_tasks);
}
```
I also added a regression test for this
Self-Review Checklist:
- [x] I have 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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed task modal failing to show language tasks in some cases
Adds `scheduler::spawn_dedicated_thread` (and inherent `spawn_dedicated`
methods on `PlatformScheduler` and `TestScheduler`) so single-threaded
actors that own `!Send` state can run on their own OS thread and freely
do blocking I/O without disturbing any other executor.
### Why
A single-threaded actor that needs to do blocking syscalls is currently
stuck: it can't run on the shared foreground executor (blocking would
stall every other foreground session), and it can't move to the
background pool because its state isn't `Send`. `spawn_dedicated` gives
each such actor its own thread and its own `LocalExecutor`, while still
participating in the same testable scheduler infrastructure as
everything else.
### Shape
- `pub fn spawn_dedicated_thread(session_id, scheduler, f) -> Task<_>`
in `scheduler`. Owns the OS thread, the per-session runnable channel,
and the `LocalExecutor` setup.
- Inherent `spawn_dedicated` on `PlatformScheduler` (allocates its own
`SessionId`, delegates to the free function).
- Inherent `spawn_dedicated` on `TestScheduler` (no real thread — runs
as a fresh local session driven by the test scheduler's run loop, so
determinism under `many` is preserved).
- Renames `Scheduler::schedule_foreground` → `schedule_local` and
`scheduler::ForegroundExecutor` → `scheduler::LocalExecutor` to reflect
that these are session-pinned queues rather than "the main thread" (a
dedicated session runs on its own thread). GPUI's wrapper
`gpui::ForegroundExecutor` and the `foreground_executor` field/method
names are unchanged to keep blast radius small.
- `LocalExecutor::new` now takes an explicit dispatch closure, so the
routing decision (default session, dedicated thread, or something else)
lives at the construction site.
### Tests
- `TestScheduler` side: round-trip, `!Send` future, `Send` closure
capturing shared state, inner `executor.spawn`, determinism under `many`
seeds, drop-cancels-future, detached child runs after root completes.
- `PlatformScheduler` side: real separate thread (blocking syscalls
don't stall the test), `!Send` future output, drop-cancels-future,
thread tears down after work completes, detached child outlives root.
cc @as-cii
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Now that customisation of this prompt was moved to `AGENTS.md`, we don't
want to load the customised prompt, and instead just use the default
prompt, so that we don't include the same instructions twice
Release Notes:
- git: Improve performance when generating git commit message with LLM
This updates our WebRTC configuration to enable gain normalization in
the
recording flow, which should help normalize the effective volume of
participants
in calls.
Release Notes:
- Added volume equalizations to participants in collab calls
Follow up to https://github.com/zed-industries/zed/pull/57632, uses
changes from https://github.com/zed-industries/zed/pull/58061
Previously the floating permission popover only appeared when the inline
permission prompt was scrolled below the viewport. It now also appears
when the prompt is scrolled above the viewport, with the scroll button
pointing in the right direction.
Release Notes:
- Fixed the agent permission popover not appearing when the inline
prompt was scrolled above the viewport.
Adds the handoff feature flag with staff disabled by default, giving the
rest of the auto-compaction stack a rollout gate without changing
behavior for users outside the flag.
Release Notes:
- N/A
In prep for handling the above-viewport case in
https://github.com/zed-industries/zed/pull/57632, which currently only
handles below case.
This PR adds `ListState::item_is_above_viewport` and
`ListState::item_is_below_viewport` methods, which report whether a
given list item is entirely outside the current viewport. Both return
`None` when the list has not measured enough layout to answer.
Release Notes:
- N/A
cc @SomeoneToIgnore
## Summary
Follow-up to [this
comment](https://github.com/zed-industries/zed/discussions/55352#discussioncomment-16961889).
This extracts the buffer header and breadcrumb rendering helpers out of
`element.rs` into a `header.rs` and mouse related things to `mouse.rs`
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content 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
## Summary
While profiling agent sessions that make a lot of `edit_file`
operations, I noticed the LSP `textDocument/didChange` handler firing
excessively. Looking into this, I found out that the streaming edit
pipeline was applying each `CharOperation` from `StreamingDiff` as its
own `buffer.edit` transaction, and every transaction emits a
`BufferEvent::Edited` event. Each event can trigger several other
expensive events depending on whether the buffer is being rendered in an
editor or is registered with a language.
For example, there are `didChange` LSP events, the editor's on edit work
(matching brackets, bracket colorization, code actions, outline), and
more. A single `edit_file` could trigger hundreds of these at the higher
end in a single synchronous app update, which would block the foreground
thread for a bit and cause Zed to drop frames.
I fixed this by collecting all of a chunk's `CharOperation`s and
applying them in one `buffer.edit` call, so only a single
`BufferEvent::Edited` event gets emitted. This is safe because
operations are non overlapping by design of streaming diff (the edit
cursor only advances).
## Why this wasn't caught earlier
The cost only fully appears when a buffer is both registered with a
language server and rendered in an editor. Without that, most of the per
transaction observers never run, so the existing `edit_file_tool`
benchmark (which ran the tool against a bare buffer) didn't surface it.
I reworked the benchmark to open the edited buffer in an editor view,
register a fake language server with per edit diagnostics, and lay out a
frame, so it exercises the same cascade as the real editor. I also added
a larger fixture.
## Results
Measured with the `release-fast` profile on the reworked benchmark:
| Fixture | Initial file | Before | After | Improvement |
| --- | --- | --- | --- | --- |
| `tiny_function_rewrite` | 1.4 KB | 31.1 ms | 12.1 ms | −61% |
| `small_function_rewrite` | 3.0 KB | 42.4 ms | 19.3 ms | −55% |
| `medium_many_small_changes` | 4.6 KB | 309.2 ms | 151.5 ms | −51% |
| `medium_insertions` | 4.6 KB | 171.8 ms | 126.1 ms | −27% |
| `large_multi_edit` | 44 KB | 9,549 ms | 919 ms | −90% |
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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Improved agent's edit file tool performance
The `nc` crate and `zed --nc <socket>` flag were added in #34577 to let
the Claude Code integration spawn the running zed binary as a
netcat-style bridge between stdio and a Unix socket for its MCP server.
That integration was removed in #37120 in favor of the external
`@agentclientprotocol/claude-agent-acp` npm package, which dropped the
only caller of `--nc`. The flag, its dispatch in `main.rs`, and the `nc`
crate itself were left behind and have been unused since.
Nothing in the Zed codebase spawns `zed --nc` anymore, so remove the
flag and delete the crate. The unrelated `--askpass` netcat bridge (in
the `askpass` crate) is unaffected.
Release Notes:
- N/A
Editing the `lsp` section of `.zed/settings.json` caused two identical
`workspace/didChangeConfiguration` notifications to be sent to each
language server, e.g.:
// Send:
{"jsonrpc":"2.0","method":"workspace/didChangeConfiguration","params":{"settings":{"jetls":{"code_lens":{"references":true},"completion":{"method_signature":{"prepend_inference_result":true}},"full_analysis":{"debounce":2},"inlay_hint":{"block_end":{"min_lines":25}}}}}}
// Send:
{"jsonrpc":"2.0","method":"workspace/didChangeConfiguration","params":{"settings":{"jetls":{"code_lens":{"references":true},"completion":{"method_signature":{"prepend_inference_result":true}},"full_analysis":{"debounce":2},"inlay_hint":{"block_end":{"min_lines":25}}}}}}
`maintain_workspace_config` observed `SettingsStore` directly while
`on_settings_changed` also fed the same loop through
`request_workspace_config_refresh`, so every settings change drove the
refresh loop twice and sent two identical
`workspace/didChangeConfiguration` notifications to each language
server.
Drop the in-loop observer and drive the loop from
`external_refresh_requests` alone. Settings changes still arrive via
`on_settings_changed -> request_workspace_config_refresh`, and toolchain
activation continues to use the same channel.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- Fixed language servers receiving duplicate
`workspace/didChangeConfiguration` notifications on every settings
change.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content 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#57962
## What
When a user is not signed in to their Zed account, the edit prediction
system was still attempting a cloud API request on every keystroke. The
request would fail deep in the credential check
(`CloudApiClient::build_request`) with a `ClientApiError::NotSignedIn`
error, which propagated back up and was logged at `ERROR` level via
`.log_err()` at line 2389 of `edit_prediction.rs`.
## Why
The sign-in check was happening too late — only discovered after async
tasks were already spawned and the full request pipeline entered. This
fix gates the request at the top of `request_prediction_internal`,
returning `Task::ready(Ok(None))` immediately before any inputs are
built or tasks spawned.
The guard mirrors the existing `is_cloud` provider check already used
elsewhere in the same file, and only applies to the `Zeta` model on the
cloud provider path. Local providers (Ollama, `OpenAiCompatibleApi`) and
other models (Mercury, Fim) are unaffected.
Note: I haven't added a test for this — testing the early-return would
require mocking auth state, which I wasn't sure was worth the complexity
for a one-liner guard. Happy to add one if preferred.
Release Notes:
- Fixed noisy `not signed in` error log on every keystroke when not
signed in to Zed
---------
Co-authored-by: Oleksiy Syvokon <oleksiy@zed.dev>
Co-authored-by: MrSubidubi <finn@zed.dev>
Co-authored-by: David3u <3udavid@gmail.com>
This primarily
- requires components to have a description as well as a preview
(especially having no preview makes no sense)
- implements some basic previews where missing
- adds a scrollbar to the preview navigation
with a sadly large diff due to reformatting (less indentation 🎉 ), but
very little changes at its core.
Release Notes:
- N/A
This PR fixes Docker Compose dev containers starting every service in
the compose project, even when `devcontainer.json` specifies
`runServices`.
Previously, Zed deserialized `runServices` but did not use it when
invoking Docker Compose. The startup command was:
```sh
docker compose ... up -d
```
With no service operands, Compose starts every enabled service in the
project. This means unrelated services are started even when the
devcontainer config asks to run only the primary service and its
dependencies.
The fix propagates `runServices` into the Docker Compose build/start
path so Zed invokes Compose with the requested services:
```sh
docker compose ... up -d devcontainer
```
Compose will still start services required by `depends_on`, but
unrelated services are left untouched.
**Reproduction**
`.devcontainer/devcontainer.json`:
```json
{
"name": "Run Services",
"dockerComposeFile": "../compose.yml",
"service": "devcontainer",
"runServices": ["devcontainer"],
"workspaceFolder": "/workspace"
}
```
`compose.yml`:
```yaml
services:
devcontainer:
image: ubuntu:24.04
command: sleep infinity
volumes:
- .:/workspace
depends_on:
- database
database:
image: postgres:16-alpine
environment:
POSTGRES_PASSWORD: postgres
unrelated:
image: nginx:alpine
```
**Expected**: Zed starts `devcontainer` and `database`.
**Before this fix**: Zed also starts `unrelated`.
**After this fix**: `unrelated` remains stopped.
Closes: https://github.com/zed-industries/zed/issues/57279
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 Docker Compose dev containers starting services not listed in
`runServices`.
Summary:
- Preserve spinner/logo prefixes from live terminal titles when terminal
threads have custom titles.
- Store raw terminal titles and custom user titles separately,
recomposing display titles on demand.
- Keep spinner prefixes out of the title editor while preserving
sidebar/search display behavior.
Tests:
- cargo test -p agent_ui
test_terminal_custom_title_recomposes_with_live_spinner -- --nocapture
- cargo test -p agent_ui
test_terminal_title_editor_excludes_spinner_prefix -- --nocapture
- cargo test -p sidebar
test_agent_panel_terminals_appear_in_sidebar_and_search -- --nocapture
Closes AI-304
Release Notes:
- Fixed terminal thread titles to preserve animated spinner and logo
prefixes after renaming.
Added because I'd like to get this skill Danilo made without having to
upload a gist
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
This PR does two things
1. Move PTY child spawning to the background executor. Forking to spawn
the terminal child was taking between 10-70ms on profiles I was looking
at, which caused frames to be dropped because it was on the foreground
thread. This should fix issues such as #57574 where the miniprof from
this comment showed terminal creation blocking the foreground thread as
well.
https://github.com/zed-industries/zed/issues/57574#issuecomment-4546858817
2. Stopped overwriting alacrities exit status with `9` on
`AlacTermEvent::Exit` event handling. Before we get the exit event,
alacritty emits `ChildExit(status)` with the real status, which we used
to overwrite with exit status 9 when handling the AlacTermEvent::Exit.
This was an easy fix so I added it in this PR when I noticed the bug.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- fixed dropped frames caused by agents or users creating new terminals
Adds a progress indicator to the worktree picker so users get visual
feedback while a worktree deletion is in progress, which can take
several seconds.
Closes AI-239
Release Notes:
- Added progress feedback in the worktree picker while deleting a
worktree
## Summary
This moves the remaining first-party AGPL surface to GPL, a less
restrictive license for these components. Apache-2.0 components are
unchanged.
Changes:
- Updates the `collab` crate from `AGPL-3.0-or-later` to
`GPL-3.0-or-later`
- Removes the root AGPL license file and first-party crate AGPL symlinks
- Updates web, documentation, Flatpak, README, and terms references to
reflect the GPL/Apache licensing split
- Updates the open-source component example list in the terms and
regenerates the RTF copy; no other terms changes are intended
- Adds guardrails so first-party crates cannot declare AGPL licensing or
carry `LICENSE-AGPL` files
Release timing: preview during the week of June 1, 2026; stable during
the week of June 8, 2026.
## Residual AGPL/Affero references
- `LICENSE-GPL`: GPLv3's own compatibility clause; unchanged official
license text.
- `crates/json_schema_store/src/schemas/package.json`: generic npm
package-license schema value, not Zed licensing.
- `script/check-licenses`, `script/new-crate`,
`script/licenses/zed-licenses.toml`: guardrails that reject or warn
against reintroducing AGPL.
## Verification
- `script/check-licenses`
- `script/generate-licenses`
- `script/generate-terms-rtf`
- `script/new-crate license_probe_for_gpl`, then discarded generated
crate
- `script/new-crate license_probe_for_agpl agpl` fails as expected
- `mdbook build docs`
- `./script/clippy`
- `git grep -n -I -E "AGPL|Affero"`
- `git diff --check`
Release Notes:
- The `collab` crate, used to implement Zed's collaboration backend, is
now licensed under the GPL instead of the AGPL. The AGPL license is no
longer used in the zed repository.
Notebook cells are currently not responding to changes in font-family
(`zed://settings/buffer_font_family`) and font-size
(`zed://settings/buffer_font_size`).
Currently, `MarkdownCell` and `CodeCell` create and set a
`TextStyleRefinement` on their `Editor`, creating copies of font-family
and font-size in the process. As a result, these do not get updated when
the global font-family or font-size change.
By not setting the refinement manually and letting the editor handle
these value instead, these values get updated when the global settings
change.
This behaviour is consistent with how the inline repl already behaves
and in my opinion is according to the users expectations.
After Review: this PR changes the rendered preview of MarkdownCells to
use the themed MarkdownStyle instead of an empty Markdown Style
Before:
https://github.com/user-attachments/assets/e70b9346-8fa1-4d66-aa85-07e987c56ff2
After:
https://github.com/user-attachments/assets/4957e20e-9b5b-4cb9-a9df-3b33538bc686
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- not sure if this needs test or how they should look like...
- [x] Performance impact has been considered and is acceptable
~~Closes #ISSUE~~
Release Notes:
- Fixed notebook cells not responding to appearance settings changes
The relative date format introduced in #47687 floors to whole years, so
a commit from 22 months ago is shown as "1 year ago". It would be better
to align with `git blame`'s own behavior so it can display timestamps
like "1 year, 10 months ago".
reference:
c69baaf57b/date.c (L189-L205)
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [X] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes#57907
Release Notes:
- Fixed inaccurate humanized date in git blame, e.g. a commit from 22
months ago no longer shows as "1 year ago"
<img width="627" height="752" alt="Screenshot 2026-05-28 at 1 20 22 PM"
src="https://github.com/user-attachments/assets/0a7825f0-73c5-49e9-b59a-83924a45de98"
/>
Adds Claude Opus 4.8 for BYOK providers, including Anthropic fast-mode
handling and Bedrock/OpenCode model definitions.
Closes AI-336
Release Notes:
- Added Claude Opus 4.8 BYOK support
Update the behavior of both `editor: go to diagnostic` and `editor: go
to previous diagnostic` in order to ensure that, if there's a diagnostic
under the user's cursor that isn't active, it is first activated, with a
subsequent call jumping to the next or previous diagnostic,
respectively.
These changes also update how diagnostic activation handles the
situation when the global diagnostic renderer is not registered, as we
used to not update the active diagnostic group in that situation.
However, we now rely on it to determine whether the user's cursor is
already in the active diagnostic, with some tests now failing, so we now
default to an empty set of blocks for the active diagnostic group when
no global renderer is registered.
Release Notes:
- Update both `editor: go to diagnostic` and `editor: go to previous
diagnostic` to prefer activating the diagnostic under the cursor before
jumping to the next or previous diagnostic, respectively
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
## Summary
This started from #57636, after we saw ChatGPT subscription/Codex
requests stall over the past week. OpenCode v1.15.11 shipped related
resilience fixes for the same class of Codex subscription endpoint
issues, so this ports the relevant pieces into Zed's native ChatGPT
subscription provider.
When Zed asks ChatGPT/Codex for a response, sometimes the server
connection can get stuck before it even sends the first response
headers. Before this PR, Zed could wait indefinitely, which looks like
OpenCode/Zed “stalling.”
This PR makes Zed:
- Wait up to 10 seconds for the server to start responding.
- If nothing comes back in that window, treat it as a temporary
network/API failure.
- Let the existing retry logic try again instead of leaving the user
stuck.
- Send a stable session-id header so OpenAI’s Codex backend can
associate requests with the same Zed agent thread.
- Add tests to make sure:
- stuck-before-response requests time out,
- normal slow streaming responses are not cut off,
- ChatGPT subscription requests send the right session header,
- the agent retries this kind of failure.
intended user-facing result is: fewer “the assistant is just sitting
there forever” failures when using ChatGPT subscription models.
## Verification
- cargo test -p open_ai responses
- cargo test -p language_models openai_subscribed
- cargo test -p agent test_send_retry_on_http_send_error
- cargo check -p open_ai
- cargo check -p language_models
- cargo check -p agent
Release Notes:
- Fixed ChatGPT subscription requests stalling indefinitely before
response headers arrive.
When importing settings from VS Code, the minimap is now enabled by
default (matching VS Code's behavior) even if the user hasn't explicitly
set minimap-related options in their VS Code settings.json.
Previously, if `editor.minimap.enabled` and `editor.minimap.autohide`
were absent from the VS Code config, Zed would leave minimap at its own
default ("never"). Since VS Code defaults to minimap on, this caused a
mismatch for users expecting their VS Code experience to carry over.
Closes#56297
Release Notes:
- Fixed apply VS Code minimap default when importing settings
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
This PR uses https://github.com/zed-industries/zed/pull/57758 as a base
and adds tests, cleans up the comments, and checks changes the database
query used in auth.db to include oauth key.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- Fixed GitHub Copilot Chat showing an empty model dropdown for users on
newer Copilot SDK builds
---------
Co-authored-by: Alexander Shlemov <eodus@users.noreply.github.com>
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Follow up to #57704
This makes sure that we offer a worktree creation option in case
resolving the default branch fails
Release Notes:
- git: Fixed an issue where worktree creation would not be possible if
resolving default branch fails
Adds opt-in rendering for Markdown frontmatter metadata blocks in
Markdown Preview and agent markdown.
- Simple `key: value` metadata blocks now render as a two-column table,
while more complex metadata falls back to a code-style block.
- Metadata block content and key/value rows are parsed in the parser
step, and the request layout simply takes over rendering.
<img width="1288" height="436" alt="image"
src="https://github.com/user-attachments/assets/b35b949a-8bc4-47db-82ef-ed835e9ac06f"
/>
Release Notes:
- Added support for rendering Markdown frontmatter metadata blocks in
Markdown Preview and Agent Panel.
Provide a way to prevent GPUI from creating AccessKit adapters, and
enable this in Zed.
This will allow us to test AccessKit support in Zed without rolling it
out more broadly, while we gain confidence in the implementation in
GPUI.
I've also added a log statement
## Motivation (i.e. a mini post-mortem about the #56065 panics)
Merging #56065 caused some nasty panics in nightly. This was caused by a
bug in the logic for selecting a focus node for a `TreeUpdate`.
AccessKit panics when an invalid `TreeUpdate` is provided.
My assumption was that, since Zed uses no a11y APIs, and also that
essentially 0 zed users would have AT apps running, that merging this PR
would have no effect on the behaviour of Zed itself. However, two issues
combined to cause the panics:
- It seems like many people (everyone?) on mac gets the activation
callback called by accesskit_macos. A quick search suggests this might
be due to password managers searching for password fields, but not sure
how true that is.
- The bug in question related to *forgetting to check* whether a node
used a11y APIs, so we *were* pushing non-empty `TreeUpdate`s
As a (probably temporary) defensive measure, I added a function to try
to detect the bad cases and fix them. But it would be lovely if this
could live in AccessKit itself, since it would mean we wouldn't have to
do the check twice (once in GPUI, once in AccessKit). This would also
help prevent drift when updating accesskit versions if new invariants
are added.
We also cannot protect against this with `catch_unwind`, since we use
`panic=abort`. So our only option unfortunately is to temporarily
disable AccessKit until we know our implementation is stable.
Release Notes:
- N/A or Added/Fixed/Improved ...
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
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#56357
Release Notes:
- Fixed bug where devcontainers were not respecting override_command
Selecting text inside the hover documentation or git popups did not
scroll the popup when the drag passed the visible area, so any text
below the area could not be selected with the mouse.
The popup's container already had a `ScrollHandle` wired to its
scrollbar and wheel scrolling, but the inner `MarkdownElement` was
constructed without one. That left it in the default
`AutoscrollBehavior::Propagate` mode, which routes drag-autoscroll
requests to the editor-wide autoscroll listener, which is a listener
that does not exist inside a floating popover, so the requests were
silently dropped.
Passing the popup's existing `ScrollHandle` into the `MarkdownElement`
switches it to `AutoscrollBehavior::Controlled`, which scrolls the
popup's own container directly during a drag. The markdown preview view
already uses this same pattern.
Release Notes:
- Fixed hover documentation and git popups not scrolling while selecting
text with the mouse
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content 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
I ran into this while using lazygit: the Shift navigation keys were
being captured by Zed to scroll the terminal buffer instead of being
passed through to the program.
Capturing them makes sense in the normal terminal case, where the user
wants to scroll and Shift has no other meaning. But in alternate-screen
TUIs like lazygit, less, or neovim, terminal scrollback isn't relevant,
so we can forward these keys to the program while it's open.
Release Notes:
- Fixed Shift+Up, Shift+Down, Shift+Home, and Shift+End in terminal TUIs
like lazygit, less, and neovim.
---------
Co-authored-by: John Tur <john-tur@outlook.com>
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
Some best-effort tracking of an allowed-list of agents (to avoid
grabbing sensitive data) just to get basic data on general usage
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 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: morgankrey <morgan@zed.dev>
Closes#56493
In Helix select mode, pressing `a` after a selection (e.g. `v a`) placed
the cursor one column too far to the right.
Bound `a` to `vim::HelixAppend` in the `helix_select` keymap so it
matches the behavior in `helix_normal`, and added a regression test for
the `v a` case.
Release Notes:
- Fixed cursor placement after pressing `a` in Helix select mode.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
We were missing a check when setting the focused node ID, causing a
panic in accesskit's internal validation logic. Fixes the bug, and adds
some defensive logic to help mitigate potential future issues.
You can reproduce the panic by:
- turning on a screenreader
- launching zed
- opening a menu and pressing tab
This change fixes it.
Release Notes:
- N/A or Added/Fixed/Improved ...
Stacked on top of #57430.
When the `sandboxing` feature flag is on (macOS only), agent-run
terminal commands are launched under `/usr/bin/sandbox-exec` with a
per-command Seatbelt policy:
- **Reads:** any path on the filesystem.
- **Writes:** each project worktree plus a per-command `$TMPDIR`.
- **Network:** blocked.
The model can request relaxations on individual calls via three new
input flags on the `terminal` tool:
- `allow_network: true`
- `allow_fs_write: true`
- `unsandboxed: true`
Each one triggers a separate always-prompt user approval (bypassing any
`always_allow` rules, since escalation is a stronger trust boundary than
the baseline command approval). The flags are silently ignored when
sandboxing is off, so the model can't surreptitiously change runtime
behavior by setting them in the no-op case.
The per-command tempdir is provisioned regardless of sandbox state so
the model can't infer whether the sandbox is in effect by looking at
`$TMPDIR`.
The Seatbelt config file's lifetime is tied to the `Terminal` entity via
an opaque RAII handle (`SandboxConfigHandle = Box<dyn Any + Send>`), so
cancellation paths drop it automatically.
### Notes for review
- The writable scope passed to the sandbox is the project's worktree
paths plus the per-command tempdir, **not** the resolved `cd` working
directory — `cd` is model-controlled, and using it as the writable scope
would let the model widen its own write permissions outside the project.
- The new tool flags are always present in the JSON schema (with
`#[serde(default)]`), even when the sandbox prompt section isn't
rendered. The system prompt only documents them when the section is
present, so the model shouldn't try to use them when it's not — but the
schema doesn't actively reject them, just ignores them.
- I opted not to add an end-to-end test for the escalation prompt path:
the existing `FakeThreadEnvironment` ignores the new params and toggling
the feature flag in tests is more wiring than felt worth it for a first
cut. The pure-function pieces (`sandbox_approval_title`, schema,
deserialization) are covered, and the sandbox crate itself has
end-to-end tests that actually invoke `sandbox-exec`.
Release Notes:
- N/A
---------
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Stacked on top of #57429.
Adds a new `sandboxing` feature flag (off for staff by default) and a
single source-of-truth helper `sandboxing_enabled(cx) = cfg!(target_os =
"macos") && cx.has_flag::<SandboxingFeatureFlag>()`. When the helper
returns true, the agent's system prompt gains a new `## Terminal
sandbox` section that:
- Lists each worktree's absolute path as a writable directory.
- Describes the per-command `$TMPDIR` scratch directory.
- States that outbound network access is blocked.
- Documents the three per-command flags (`allow_network`,
`allow_fs_write`, `unsandboxed`) the model can request to relax the
sandbox.
- Tells the model the section is stable for the duration of the
conversation.
When the flag is off, the section is omitted entirely — no mention of
sandboxing at all.
No behavior change to terminal execution yet; that's the next PR in the
stack.
Three new tests cover: section omitted when `sandboxing: false`, section
rendered with all worktrees + flag docs when `sandboxing: true`, and the
zero-worktrees case.
Release Notes:
- N/A
---------
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Co-authored-by: Martin Ye <martin@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)
- [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 (didn't add new test for
parsing SHA-256 - not sure if would be desired)
- [x] Performance impact has been considered and is acceptable
Closes#24070
Upgrades git2 from 0.20.1 to 0.21.0 with the `unstable-sha256` feature -
adds ability to open and work with git repositories using the SHA-256
object format. `Oid::from_str` now detects 64-char hex strings to parse
SHA-256 OIDs correctly.
Also adapts to breaking API changes in 0.21.0:
`Remote::url()` and `Commit::message()` both now return `Result`.
Release Notes:
- Added support for opening SHA-256 object format git repositories
