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
Dev container image builds default to BuildKit (`docker buildx`).
Docker-compatible engines that lack an integrated BuildKit — notably
[Apple Container](https://github.com/apple/container) accessed through a
Docker-API bridge — cannot resolve a locally-built image in a `FROM`,
which breaks the dev container build: Zed builds the features image,
then a second `FROM <features-image>` build (the UID remap), and
BuildKit's docker-container/remote drivers can't see the daemon's local
image, failing with `pull access denied`.
The daemon's *classic* builder resolves locally-built images, and Zed
already generates a BuildKit-free Dockerfile for the non-BuildKit path
(multi-stage `FROM` + `COPY --from`, no `RUN --mount`). This wires that
path to a setting and makes the remaining build invocations actually use
the classic builder.
## Changes
- Add a `dev_container_use_buildkit` setting (tri-state):
- unset → auto-detect via the `docker buildx` plugin (current behavior)
- `false` → force the classic builder
- `true` → force BuildKit
- When the classic builder is selected, pass `DOCKER_BUILDKIT=0` (and
`COMPOSE_DOCKER_CLI_BUILD=0` for compose) to the feature-content build,
the compose build, and the UID-remap build, so multi-stage `FROM` of a
locally-built image resolves through the daemon's classic builder.
- Document the setting in `docs/src/dev-containers.md`.
With this setting plus a Docker-API bridge, a real Rails dev container
(compose: app + mysql + valkey, with features) builds and starts on
Apple Container.
## How to Review
- `settings_content.rs` / `dev_container/src/lib.rs` — the new setting
and its plumbing into `DevContainerContext`.
- `docker.rs` — `Docker::new` honors the setting
(`supports_compose_buildkit`), `docker_compose_build` selects the
classic builder; unit test
`use_buildkit_setting_overrides_buildx_detection`.
- `devcontainer_manifest.rs` — `DOCKER_BUILDKIT=0` for the
feature-content and UID-remap builds.
## 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
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added a `dev_container_use_buildkit` setting to build dev containers
with the classic Docker builder for engines without an integrated
BuildKit (e.g. Apple Container)
# Objective
When the agent's terminal tool runs a command with an unsupported shell
syntax (e.g. process substitution `<()` in dash), the shell prints an
error and then drops into interactive mode. It shows a `$` prompt and
hangs waiting for input, requiring the user to press Ctrl+D to continue.
This happens because the stdin redirect wraps the command in a subshell
`(...) </dev/null`, which only closes stdin for the inner command. The
outer shell still has its stdin connected to the PTY, so after a syntax
error it reads from the PTY and waits for more input.
## Solution
Replace the subshell wrapping with an `exec`-level redirect. Instead of:
```sh
sh -i -c '(command\n) </dev/null'
```
We now produce:
```sh
sh -i -c 'exec </dev/null; command'
```
`exec </dev/null;` closes stdin for the **entire shell process**. If the
command fails with a syntax error, the shell immediately gets EOF from
stdin and exits cleanly instead of prompting for more input.
The `-i` flag is preserved so that shells which support it still source
their interactive init files and enable job control.
This change applies to `ShellKind::Posix` (sh/bash/dash/zsh) and
`ShellKind::Fish` in both `ShellBuilder::build()` and
`ShellBuilder::build_no_quote()`.
## Testing
- Manually verified that `cat <(echo hi)` (process substitution in dash)
no longer hangs: the shell exits immediately with the syntax error
## 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 agent terminal tool hanging with a `$` prompt when commands
encounter syntax errors or unsupported shell features like process
substitution
When expanding build args in a dev container Dockerfile, only the braced
`${VAR}` form was substituted. The bare `$VAR` form — which is valid
Docker
syntax and common in real-world Dockerfiles — was passed through
verbatim.
For example, the Rails dev container images use:
```dockerfile
ARG RUBY_VERSION=3.4.4
FROM ghcr.io/rails/devcontainer/images/ruby:$RUBY_VERSION
```
This left `$RUBY_VERSION` unexpanded, so the subsequent `docker inspect`
/
build ran against the literal string `ruby:$RUBY_VERSION` and failed
with
an invalid reference format.
This adds `expand_dockerfile_var`, which substitutes both `${VAR}` and
bare
`$VAR`. Bare `$KEY` is only replaced when it is not immediately followed
by
a word character, so expanding `$RUBY_VERSION` does not partially
consume
`$RUBY_VERSION2`.
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
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed dev container Dockerfiles not expanding build args written in
the bare `$VAR` form
Signed-off-by: Toru Nayuki <tnayuki@icloud.com>
# Objective
Closes#59229
When adding a newline, Zed has a bit of intelligence to do more work
than just inserting a `\n`. For comment lines, it simply extends the
comment:
```rust
Before
// This is a comment, ˇThis is another comment
After
// This is a comment,
// ˇThis is another comment
```
And when the cursor is inside bracket pairs, Zed inserts another newline
to move the closing bracket to a new line:
```rust
Before
fn main() {ˇ}
After
fn main() {
ˇ
}
```
However, when we have a comment line with the cursor inside a bracket
pair, both mechanisms apply, resulting in an unintended state where the
closing bracket is kicked out of the comment:
```rust
Before
// {ˇ}
After
// {
// ˇ
}
```
We definitely do not need the bracket extension rule when we are adding
a newline inside comments. We want comment lines inside brackets to be
split like this:
```rust
// {
// ˇ}
```
## Solution
- Disable Bracket Extra Newline in Comments: When a line comment
delimiter is detected, we override the default `newline_config` to set
`extra_line_additional_indent` to `None` .
- Avoid Rule Conflicts (Short-circuiting): The three newline
customization helpers (line comment, block comment, and list item) are
mutually exclusive. I refactored their execution from a sequential list
into an `if let Some ... else if let Some` branch. This prevents
subsequent rules from having side effects on `newline_config` when a
match has already occurred.
## Testing
A new test named `test_newline_comments_with_brackets` is introduced in
`crates/editor/src/editor_tests.rs`, All tests in the `editor` crate
were verified using `cargo test -p editor` .
## 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 an issue where splitting brackets inside line comments inserted
an extra line and broke the comment formatting
# Objective
Without the `font-kit` feature, `MacPlatform` silently substitutes
`gpui::NoopTextSystem`, which accepts fonts and resolves font ids but
rasterizes every glyph to an empty bitmap.
I hit this with the `component_preview` example
https://github.com/zed-industries/zed/pull/59241.
## Solution
Log a warning at startup in `MacPlatform::new()` when falling back to
`NoopTextSystem`. Skipped in headless mode, where no text is expected to
render and the fallback is a reasonable configuration.
## Testing
Checked as part of https://github.com/zed-industries/zed/pull/59241
## 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)
## Showcase
It just render as like without any error:
<img width="1312" height="945" alt="cp_pr1_before"
src="https://github.com/user-attachments/assets/f5faf3c0-9523-4c5f-9756-e65cbaf3456f"
/>
---
Release Notes:
- N/A or Added/Fixed/Improved ...
`cargo run -p component_preview --example component_preview` does not
work.
On current main it panics at startup:
```
thread 'main' panicked at crates/gpui/src/action.rs:296:13:
Action with name `zed::Quit` already registered
```
With that panic fixed, the window opens but renders no text and no icons
(see Showcase below).s
## Solution
Root cause for the blank window: `component_preview` package resolves
`gpui_platform` with just `"screen-capture"`.
On macOS the missing `font-kit` feature makes `MacPlatform` fall back to
`gpui::NoopTextSystem`, as mentiond also in README (or CONTRIBUTE) file.
On Linux the missing `wayland`/`x11` features leave no windowing backend
at all.
list of changes:
- Enable the same `gpui_platform` features as the `zed` binary.
- Attach `Assets` and load the embedded fonts.
- Initialize `env_logger` so platform warnings reach the terminal.
- Fix three startup panics: move the example's `Quit` action to the
`component_preview` namespace.
## Testing
Tested on macOS/Linux, not tested on Windows. I use Parallel VMs.
## 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)
## Showcase
Before:
<img width="1312" height="945" alt="cp_pr1_before"
src="https://github.com/user-attachments/assets/4611596f-6775-4863-bd4a-5f4d8c642e35"
/>
After:
<img width="1312" height="945" alt="cp_pr1_after"
src="https://github.com/user-attachments/assets/8f8082e6-c8cd-48f5-946a-032ce8186d30"
/>
---
Release Notes:
- N/A
This fixes an issue where we would still allow users to toggle for agent
servers but would not actually show them any results, since they are all
suppressed.
Also slightly changes the order in which we present the provides chips:
Languages is now first, and debug adapters are now further up.
Release Notes:
- Removed the agent server chip from the extension UI search filder.
Summary:
When you have a lot of projects open, finding a thread from a specific
project in the archive ("Search all threads") view is slower than it
should be — the filter only matches the thread title, so you have to
remember or scan titles to find what belongs to which project. Folder
names are a quicker mental handle than thread titles, especially across
many projects.
This PR makes the archive filter also try matching the basename of each
of the thread's worktree paths. Title matches still take precedence and
get the highlight positions; project-name matches just include the row.
Same `fuzzy_match_positions` contiguous substring matcher already used
for titles, so the matching feel is consistent.
Example: typing `my-laravel-project` now surfaces every thread that
lives
under a project named `my-laravel-project`, regardless of title.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] 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)
- [x] Tests cover the new/changed behavior — small extension to an
existing filter branch; manually verified.
- [x] Performance impact has been considered and is acceptable — per-row
path-basename check only runs when the title didn't match.
Release Notes:
- Improved the archive "Search all threads" view so you can filter by
project name, not just by thread title — handy when many projects are
open.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
When clicking the "Open Folder" button in a remote project window, the
"Remote Projects" window was not being dismissed. Now we're emitting a
DismissEvent so we can close it.
Release Notes:
- Fixed the Remote Projects modal not being dismissed on "Open Folder"
click.
Follow-up to #59195. While verifying that fix against prod we hit a log
that couldn't distinguish "retrying with a fresh token that is still
revoked" from "silently retrying with the same dead token because the
server returned no connection info" (e.g. a collab deploy predating
#59195). Make the retry loop self-diagnosing:
- Warn when `RejoinRoomResponse` carries no `live_kit_connection_info`,
since the loop then reuses the existing token.
- On refresh, log whether the token actually changed.
Release Notes:
- N/A
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Clip split buffer headers to the editor's content bounds so they no
longer paint into the horizontal scrollbar area.
Reuse the editor's computed right margin and horizontal scrollbar
visibility instead of reimplementing scrollbar detection in
split_editor_view. This keeps split headers aligned when minimap, inline
blame, or scrollbar visibility change the available content area.
Release Notes:
- Fixed horizontal scrollbars not being rendered behind buffer headers
in split editors
---------
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Co-authored-by: dino <dinojoaocosta@gmail.com>
Closes AI-394
When the kernel isn't running — e.g. Python isn't installed, ipykernel
is missing, or the kernel failed to launch — clicking run on a notebook
cell would unconditionally enter the executing state and silently drop
the execute request. The cell then spun forever with no logs and no way
to cancel (the stop button only works on a running kernel).
This change makes `execute_cell` attempt to send the execute request
first, and only mark the cell as executing when the send succeeds. On
failure it:
- Renders the failure (including the original kernel launch error) as an
error output on the cell, reusing the same `ErrorView` used for Python
tracebacks
- Logs the reason at the moment run is clicked, instead of only once at
notebook open
- No longer swallows `try_send` errors when the kernel process has died
Also adds the first unit test for the notebook editor, which exercises
the production path end to end: a real `.ipynb` parsed via
`NotebookItem::try_open`, a kernelspec pointing at a nonexistent
interpreter selected through `ReplStore::set_active_kernelspec`, a real
failed process spawn, and assertions through the production save path
(`to_nbformat_cell`). Verified red/green: the test fails against the
previous behavior.
Note for future notebook tests: `NotebookEditor` renders a continuously
animating kernel status icon, so rendering it as a root view in a GPUI
test makes `run_until_parked` spin forever. The test creates the editor
inside an empty window instead.
Release Notes:
- N/A
# Objective
We were not caching builds for nightly/bundling jobs AT ALL.
## Solution
## Testing
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
This is a follow up to https://github.com/zed-industries/zed/pull/58169
and https://github.com/zed-industries/zed/pull/58518 after removing a
bunch of unsafe usage.
Before this, GPUI moved traffic lights by directly changing the native
button frames inside AppKit’s existing titlebar layout and the old
y-coordinate was based on the native titlebar height, so the buttons
moved visually while the titlebar tracking geometry could still be based
on the old layout.
Now the native titlebar container is resized and repositioned to contain
the traffic lights. We capture the original AppKit titlebar/button
frames, resize the titlebar container to fit the requested position,
move the native close/minimize/zoom buttons inside that container and
update AppKit tracking areas. This keeps the visible buttons and
hover/click geometry aligned.
### Before
https://github.com/user-attachments/assets/77dde6cb-3fc8-4166-bc86-22cf2c93e119
### After
https://github.com/user-attachments/assets/da84ade6-ef47-4e53-ae4a-3779315773f9
---------
Co-authored-by: Yara 🏳️⚧️ <git@yara.blue>
# Objective
You know that feeling? You join the channel, crack a banger joke to
break the ice - yet, nobody laughs. Worse yet, you're swarmed with Slack
messages like "Piotr, we can't hear you". After a while you realize that
maybe it's for the best as the joke was not as good as you've initially
thought, but still: it's possible to get into a state where other
participants see you as muted. You don't hear anybody. Bummer.
That's what happened when we were hoping to pair with @dinocosta today.
I could not hear him. However, he had some logs to share which indicated
that while collab thought he's in the room with me, live-kit was
rejecting his token as it was revoked.
What clanker helped us figure out is that there's a race-y code path
where if you disconnect from a given room abruptly, collab can put you
in a limbo.
<details><summary>Clanker's idea of what's going on</summary>
<p>
Found the whole story. Here's what those logs mean and where the bug
surface is.
What's happening
The error at room.rs:1809 is the detach_and_log_err on the task spawned
by spawn_room_connection (crates/call/src/call_impl/room.rs:1754-1810).
So this is the initial livekit::Room::connect call failing — the LiveKit
SDK internally retried 3 times (that's the retrying... (1/3) lines), got
401 invalid token: revoked every time, gave up, and the error propagated
out of the ? at line 1762 and was logged-and-dropped.
The "revoked" comes from the collab server: leave_room_for_session
(crates/collab/src/rpc.rs:4091-4095) calls
live_kit.remove_participant(livekit_room,
session.user_id().to_string()), and LiveKit Cloud treats a removed
participant's token as revoked. Crucially, the LiveKit identity is just
the user id, not the connection id, while the DB-side
leave_room(connection_id) is per-connection. leave_room_for_session
fires from three places:
1. Explicit leave (rpc.rs:1666)
2. connection_lost, after RECONNECT_TIMEOUT expires (rpc.rs:1342)
3. Stale-connection cleanup when re-joining a channel (rpc.rs:3401)
So there's a race: an old connection's delayed cleanup (path 2) can fire
after the same user has rejoined the room on a new connection and been
issued a fresh token — and remove_participant(room, user_id)
kicks/revokes the user's current LiveKit participant, because the
identity is shared across connections. Quick restart of Zed, two
instances, or a reconnect that straddles the server's RECONNECT_TIMEOUT
all set this up.
Client-side consequences (this connects to your first question)
When that initial connect fails:
- this.live_kit stays None and this.diagnostics is never created — lines
1780-1791 only run on success. So in this failure mode CallDiagnostics
doesn't exist at all; the "stats never overridden" path I described
earlier isn't even reached.
- There is no retry and no token refresh. The failure is
detach_and_log_err'd and that's the end of it. The user stays in the
room at the collab level (status is still Online, they appear in the
channel), but with no audio and no way to recover short of leaving and
rejoining.
- Even a collab-level reconnect doesn't help: RejoinRoomResponse
(crates/proto/proto/call.proto:58) carries no live_kit_connection_info,
and rejoin() never calls spawn_room_connection — the LiveKit connection
is established exactly once, in Room::new, with the token from the
original join response.
So the user-visible symptom is: you're "in" the call, everyone sees you,
but you can't hear or be heard, and there's no error surfaced in the UI
— just this log line.
If you want to fix it, the two angles are server-side (make
leave_room_for_session skip the LiveKit removal when the user still has
a live connection in that room, or scope LiveKit identities
per-connection) and client-side (treat a failed spawn_room_connection as
fatal-but-recoverable: surface it, and have rejoin request fresh
connection info instead of silently carrying on). Happy to dig into
either if you want.
</p>
</details>
So tl;dr: our token was swapped out underneath us. One way to "fix" it
was to just go into another channel, but that was a bummer.
We have a good and reliable repro for it though: `kill -9 $ZED_PID`
followed by an attempt to rejoin the same channel within 30s would
consistently put us in that state.
Put another way: you panic and thus do not send a clean "leave room"
message to LK. if you rejoin the channel within 30s (after restarting),
LK will invalidate the very token you're attempting to use (as it cleans
up old tokens).
It may also happen without crashing, but that's the most reliable way to
repro the issue. Long story short your LK token gets tainted and you
can't share the audio anyhow.
## Solution
The fix is both client and server-side.
On client's side, we now retry the reconnection with a back-off and we
grab a fresh token off of reconnect attempts.
On server's side, we share the current token on room reconnect attempts.
We've also tweaked the call diagnostics to not use `unwrap_or_default`
so much: it was hard for us to tell that we're in a totally bogus state
and we've only reached that conclusion based on source code analysis. We
now show some generic "ok you're in a borked state pls report a bug"
message instead.
## Testing
We added tests that present the flacky scenario. We've also tried to
setup an infra to test the new behaviour, but sadly, local LK instance
seems to revoke tokens more leniently than the prod..
OTOH, we are quite confident that once new collab is deployed, we'll be
able to mince the new tokens and life is going to be good. Even when
running against the current prod instance we could see that our code
changed the behaviour for the better, as now we'll actually try to use a
new token if one is provided by collab. For that to happen we need to
redeploy though.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed a race condition that caused collab users to not receive/send
any audio to their peers.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Co-authored-by: Dino <dino@zed.dev>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Both cloning and dropping of these has quite a bit of overhead (despite
them being snapshots), so avoid where possible, especially in display
map syncing
Release Notes:
- N/A or Added/Fixed/Improved ...
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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#56748
## Summary
Block / column selection (Shift+Ctrl+drag on Linux, Shift+Cmd+drag on
macOS) anchored its rectangle on a single byte column applied to every
row in the dragged range. On a row whose text contained a multi-byte
character before that column (for example `ã`), the same byte offset
mapped to a different visual `x`, so the per-row cursor drifted off the
column.
`select_columns` now anchors the rectangle in `x` pixels via
`x_for_display_point` and resolves each row's byte column with
`display_column_for_x` — the same pair of helpers already used by
vertical cursor motion and Vim VisualBlock.
## Before / After
**Before** — cursor on the `ã` row drifts one column to the left:
<img width="1068" height="366" alt="image"
src="https://github.com/user-attachments/assets/0559ef89-852e-40f3-9d43-f5f44277f99e"
/>
**After** — rectangle stays visually aligned across rows:
<img width="866" height="408" alt="image"
src="https://github.com/user-attachments/assets/bce13c1a-1ddb-4fd6-8216-2c0e902f6668"
/>
## Test plan
- `cargo test -p editor test_columnar_selection_with_multibyte_chars`
(new regression test covers the buggy case past the `ã` byte boundary,
plus a control case where old and new logic agree).
- Manual: Shift+Ctrl+drag down a five-line buffer where row 3 contains
`ã` — selection rectangle stays aligned (see screenshots).
- Manual: Shift+Alt+drag (`FromSelection` branch) over the same buffer —
same result.
- Manual: drag past EOL on the `ã` row — each row extends to its own EOL
with no panic.
Release Notes:
- Fixed misalignment of column selection on rows that contain multi-byte
characters
---------
Co-authored-by: Tom Houlé <tom@tomhoule.com>
Release Notes:
- Fixed an issue where the close button could overflow within a
workspace error popup.
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
# Objective
Give a bit more structure to contributors so that each (potentially new)
contributor doesn't have to come up with their own structure on-the-fly.
## Solution
Update the PR template to include sections for describing
- what the PR is trying to achieve
- how it decided to achieve the goal
- how reviewers can test the work
- demos of the new functionality
## Testing
I used the PR template for this PR, so reviewers can evaluate if they
think the structure is useful.
## 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>
### Before
<img width="1082" height="572" alt="image"
src="https://github.com/user-attachments/assets/bc72b8ab-f5ec-4270-b1ec-546456525e92"
/>
### After
<img width="1241" height="945" alt="image"
src="https://github.com/user-attachments/assets/088d90e4-2cb1-42cd-9f8f-0b2783ab7fe4"
/>
</details>
---
Release Notes:
- N/A
Follow up to https://github.com/zed-industries/zed/pull/59126 where
seeing the typed-prompt in the agent panel's toolbar felt really busy.
With that change, I'd be seeing the prompt I'm writing in three
different stops, which felt overwhelming. Toning that down a little bit
in here.
Release Notes:
- N/A
Mermaid diagrams with long node labels rendered as an unreadable jumble:
each label was painted as one long line over a box sized for wrapped
text, overflowing into neighboring nodes. With this change, labels wrap
to the box width the layout computed.
**Root cause:** mermaid's default `htmlLabels: true` makes merman emit
labels as HTML inside `<foreignObject>`, which resvg cannot rasterize.
merman's resvg-safe pipeline replaces each one with a single-line
`<text>` fallback that only honors explicit `<br>` breaks, so
soft-wrapped labels collapse onto one long line — while the node boxes
were laid out for the wrapped text.
**Fix:** disable HTML labels in the site config (both the top-level key,
which merman reads for node labels, and `flowchart.htmlLabels`, which it
reads for edge labels). merman then emits native SVG `<text>`/`<tspan>`
labels wrapped to the same measured width the layout used, and the
foreignObject fallback never runs for these diagrams.
One behavior preserved deliberately: a literal `\n` in label text used
to become a line break as a side effect of the foreignObject fallback
(`fallback.rs` converts `\n` when flattening HTML labels).
`render_mermaid` now normalizes `\n` to `<br/>` before rendering so the
native path keeps that behavior; the existing
`backslash_n_converted_to_line_break` test covers it.
Side effect: class diagram member text also switches from the lossy
fallback to native SVG text; the accent-class test was updated
accordingly (accent classes now land directly on `text`/`tspan`
elements).
Verified with `cargo nextest run -p mermaid_render`, `-p markdown`,
`script/clippy -p mermaid_render`, and `cargo fmt --check`.
Release Notes:
- Fixed mermaid diagram labels overflowing and overlapping nodes when
long labels wrap
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Replaces the verbose struct-literal construction of `gpui::BoxShadow`
with a builder API:
- `BoxShadow::new(offset_x, offset_y, color)` takes the required fields,
with arguments ordered to match the CSS `box-shadow` property.
- `.blur_radius(_)`, `.spread_radius(_)`, and `.inset()` set the
optional fields.
All in-tree call sites are migrated, including the Tailwind-style
`shadow_xs`..`shadow_2xl` helpers in `gpui_macros`, the `ElevationIndex`
shadows in `ui`, and various widgets across `editor`, `workspace`,
`agent_ui`, and `ai_onboarding`. The fields on `BoxShadow` remain
public, so external code using struct-literal construction continues to
work.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Opening a new git worktree of a repository that has a dev container
configuration re-prompted you to reopen in a dev container, even after
you'd clicked "Don't Show Again" in another worktree of the same repo.
The dismissal was keyed on each worktree's own absolute path, so sibling
worktrees never saw the stored choice.
This keys the dismissal on the repository's common Git directory
instead, which is shared across all linked git worktrees of the same
repo, so dismissing in one worktree now suppresses the prompt in the
others. Projects that aren't Git repositories fall back to the worktree
path as before.
Closes AI-357
Release Notes:
- Fixed the "Reopen in Dev Container" suggestion re-appearing in new git
worktrees after choosing "Don't Show Again"
I asked Claude Fable 5 to review our macOS process spawning layer, and
it found two notable bugs:
- We didn't mark stdio descriptors as inherited when the `Inherit`
option was passed. This means they would be closed in the child due to
`POSIX_SPAWN_DEFAULT_CLOEXEC`. Now we correctly mark them as inherited.
- Child processes were inheriting Rust's default `SIG_IGN` disposition
for `SIGPIPE`. `std::process::Command` resets the disposition to
`SIG_DFL` for children, and this PR makes us do that too, with a
regression 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:
- N/A
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
## Context
GPUI API change only:
- added `.alpha(a: f32)` method to `RGBA`
- added `.opacity(factor: f32)` method to `RGBA`
- added documentation for both new methods
- added test coverage for both methods
These implementations already exist for the `HSLA` struct and were
missing for `RGBA`.
> [!NOTE]
> In my opinion, a trait implementation could be beneficial here. Let me
know what you think about that idea before I end up making unwanted
changes.
## How to Review
Just added the new methods, including documentation and test coverage.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [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:
- Added `gpui::Rgba::alpha` and `gpui::Rgba::opacity` methods for
setting and scaling a color's alpha channel, matching the existing
`gpui::Hsla` API
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
This change is motivated by user feedback where we saw some confusion
where they didn't know that you could create either a worktree or branch
through simply typing in their respective picker's editor. Hopefully,
this new placeholder in each of them will help communicate that.
Release Notes:
- Improved placeholder copywriting in both the branch and worktree
pickers to communicate it's possible to type-to-create each.
Co-authored-by: María Craig <maria@zed.dev>
This PR fixes an issue where font properties like bolds and italics
would be lost when falling back to a fallback font.
The problem we identified was that when loading the fallback fonts, we
were just loading them by name. This meant that when the original font
had a different font weight (e.g., bold) or style applied to it this
would not cascade to the fallback font.
To reproduce the problem, we used the following text in a Markdown file:
```md
**한글 bold**
```
With the following font configuration in Zed:
```json
"buffer_font_family": "Victor Mono",
"buffer_font_fallbacks": [
"D2Coding"
]
```
The fonts can be obtained from their respective locations:
- [Victor Mono](https://rubjo.github.io/victor-mono/)
- [D2Coding](https://github.com/naver/d2codingfont)
#### Before
<img width="168" height="46" alt="Screenshot 2026-05-14 at 1 15 15 PM"
src="https://github.com/user-attachments/assets/f6883e4b-8f2b-4285-a110-0e18d562c51d"
/>
#### After
<img width="176" height="53" alt="Screenshot 2026-05-14 at 1 16 04 PM"
src="https://github.com/user-attachments/assets/88d67207-6711-473b-8027-e0acfa58c258"
/>
Closes#51460.
Release Notes:
- macOS: Fixed fallback fonts missing weight/style.
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
When the agent panel's thread is empty, the toolbar no longer shows the
labeled agent dropdown on the far left. Instead, it uses the same layout
as an active thread: a stable plus icon button on the far right, and the
left slot displays a muted "New {agent} Thread" placeholder title —
matching the sidebar's draft thread item. As soon as you type into the
message editor, the title shows your prompt text instead, reusing the
sidebar's draft label truncation logic.
Release Notes:
- Improved the agent panel's empty-state toolbar to show a "New {agent}
Thread" placeholder title (or your draft prompt as you type), with a
stable new-thread button on the right.
Wrap the fds returned by `create_pipe` and `open_dev_null` in
`std::fs::File` earlier, so that they are closed if we return early due
to an error. Includes a regression 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:
- Fixed a file descriptor leak on macOS.
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Audited the AI documentation against the implementation
## Changes
- **tool-permissions**: `skill` tool patterns match the absolute
`SKILL.md` path, not the skill name (fixed the table, example pattern,
and added a clarifying note).
- **external-agents**: Gemini CLI receives Zed's Google AI key when no
env key is set; extension-provided agents are deprecated in favor of the
ACP registry.
- **inline-assistant**: alternatives run alongside the inline assistant
model (not just the default model); fixed a broken anchor and
`gpt-4-mini` → `gpt-5-mini` model id typos.
- **mcp**: corrected the extensions menu item name ("Install New
Servers…"), the remote server `url` example, and removed the nonexistent
`thinking` tool from the profile example.
- **agent-panel**: "New From Summary" lives in the New Thread menu;
corrected the `@`-mention type list (no "instruction files"; added Fetch
and Branch Diff).
- **use-api-access**: DeepSeek default `api_url` includes `/v1`.
- **skills**: folder name is a convention not a requirement; long
descriptions warn rather than fail (measured in bytes); hidden skills
are also `@`-mentionable; dropped the unenforced consecutive-hyphen
rule; reconciled the no-remote-registry note with GitHub import.
- **edit-prediction**: `alt-tab` and `alt-l` are bound across platforms;
predictions are throttled rather than fired on every keystroke.
- **getting-started, windows-and-projects, parallel-agents**: Panel
Layout lives in the title-bar user menu, with
`workspace::UseAgenticLayout`/`UseClassicLayout` action references.
Release Notes:
- N/A
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Kunall Banerjee