Closes#61346
# Objective
At startup, a synchronous `try_recv` decides whether to restore the
session. On a macOS cold launch the CLI request arrives via
`application:openURLs:`, which AppKit dispatches only *after* the
startup closure returns, so the check finds nothing, session restore
begins, and the request lands moments later on the post-startup path.
Both behaviors are individually correct: a user with
`restore_on_startup: "last_session"` wants their session back, and the
requested file should open. The defect is that they race, the CLI open
runs its existing-window matching before restore has placed any windows,
finds nothing to reuse, and opens a redundant window.
## Solution
Make the post-startup open loop wait for restore to settle before
handling a request, so `find_existing_workspace` sees the restored
windows and honors `cli_default_open_behavior`.
The wait races full restore completion against the first window being
placed, so a slow or hung remote-workspace restore can't block a local
open. No timeouts involved, the fix is ordering, not delay :).
## Testing
**Steps**:
1. disable & enable the setting `close windows when quiting an
application` in macos itself in `desktop & dock` section
2. create a bundled Zed app
3. install cli binary to actually test the change
4. Follow any of the steps inside the before/after video's to test all
the cases we have
I tested this with a manual prod build using a custom script that
bundles Zed as a preview app. So I could actually test the cli baviour
since it works different for non-bundled builds. So the easiest way to
test this would be to run bundling on this PR and install the cli binary
to actually test it with the fix included.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>**Disabled** Close windows when quiting an
application</summary>
**before** (disabled apps on close & `add to existing window` cli
bahavior)
https://github.com/user-attachments/assets/b497130b-3432-4fa8-9fbe-70c6f63d165e
**After** (disabled apps on close & `add to existing window` cli
bahavior)
https://github.com/user-attachments/assets/354657f7-8dfe-4beb-9dd4-2bb615cb912c
**After** (disabled apps on close & `open a new window` cli bahavior)
https://github.com/user-attachments/assets/07fc3062-89a3-4e2a-811e-296533feaad7
</details>
<details>
<summary>**Enabled** Close windows when quiting an application
(unchanged)</summary>
**After** (enabled** apps on close & `add to existing window` cli
bahavior (**unchanged**))
https://github.com/user-attachments/assets/445f1d3a-2987-46b1-9bfb-b2d61894ddec
**After** (enabled apps on close & `open a new window` cli bahavior
(**unchanged**))
https://github.com/user-attachments/assets/c3078b0d-7fb4-42db-9dea-095439e23830
</details>
---
Release Notes:
- Fixed an extra window opening on macOS when launching Zed from the CLI
with session restore enabled
# Objective
Closes#61054
This PR fixes Zed window not repainting after they are uncovered on X11.
When an X11 window becomes visible after being covered, X11 sends an
`Expose` event to tell the application that the window contents need to
be presented again. Previously, Zed stored this event and waited for the
periodic refresh loop to request a presentation but, the refresh loop is
stopped while a window is fully hidden to avoid unnecessary rendering.
This meant there might be no refresh tick to handle the pending
exposure.
window is fully hidden -> periodic refresh loop stops
window is uncovered -> expose event -> waits for refresh loop -> window
may remain blank
This change requests one presentation directly after processing the
pending X11 events. Multiple `Expose` events for the same window are
coalesced, and unmapped windows are ignored.
## Solution
window is uncovered -> expose event -> presentation is requested ->
window contents are displayed
Required presentations are also excluded from inactive-window frame
throttling, so the request is not dropped when Zed is unfocused. Regular
rendering for unfocused or fully obscured windows remains throttled.
## Testing
Check the issue being closed on steps to reproduction.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed Zed windows sometimes not repainting after being uncovered on
X11
# Objective
Closes#56127
Right now there is an issue where in certain contexts, specifically GPUI
div elements, horizontal scrolling w/ a trackpad works very poorly, even
when trying to scroll sideways, vertical scrolling will happen.
This happens with both a trackpad and scrollwheel. The showcase video
also shows the broken behavior.
## Solution
The way that scrolling works in the editor is really nice, scrolls are
locked to the axis they started on but with enough force can change
axis. so by taking the ongoing scroll handler from the editor and moving
it up into GPUI, we can get that same functionality for GPUI.
I somewhat "take over" the functionality of the existing
`restrict_scroll_to_axis` property, because it seems like its purpose
was basically trying to fix this problem already, just unsuccessfully.
The alternative, and would make things overall nicer to look at, would
be to tie this to `allow_concurrent_scroll`, but the effect radius tied
to that option is way bigger, so im holding off on that atleast right
now.
## Testing
Theres a good number of scroll related tests generally, so I don't think
i've perturbed any common existing behaviors. attach the functionality
to `restrict_scroll_to_axis` really limits the surface. There are also
some new tests for the ongoing_scroll behaviors.
Tested on my mac w/ both trackpad and 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 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
Video show casing all the behaviors:
broken w/ trackpad
working w/ trackpad
broken w/ scroll
working w/ scroll
https://github.com/user-attachments/assets/1935cd2d-a255-4a77-81d5-daa9f72470a6
---
Release Notes:
- markdown_preview: Fix horizontal scrolling inside certain elements
Follow-up to #58161, which handed file drags to AppKit once the pointer
left the window but left the handoff one-way. Re-entering the source
window and dropping was not possible.
GPUI now suspends the original drag when handing it to the platform and
restores it when the drag re-enters the source window, so drop targets
receive the original typed payload instead of the synthetic
external-paths payload.
No release notes this hasn't shipped yet.
Release Notes:
- N/A
The MCP server list was always populated from the first workspace in the
`MultiWorkspace`. If Zed is configured to `"restore_on_startup":
"launchpad"`, the first workspace will always be the 'launchpad'
workspace which has no worktees in it. Since there are no worktrees in
this workspace, the MCP store is not populated, so the settings UI did
not show any MCP servers.
---
Release Notes:
- Fixed an issue where the settings UI would sometimes not show the list
of configured MCP servers
# Objective
- Prevent MCP extension configuration dialogs from appearing when
switching to background workspaces.
- Closes FR-145.
## Solution
- Route configuration requests through the active application window and
workspace, while keeping uninstall settings cleanup global.
## Testing
- Added a regression test covering active and retained background
workspaces.
## 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:
- Agent: Fixed MCP extension configuration dialogs appearing in other
workspaces.
This PR reworks the extension card component to take care of most the
rendering.
It no longer implements `ParentElement` and instead takes care of
rendering the details of the card now. This also allows us to finally
render the list of features for dev extensions amongst some other
cleanup whilst working with these.
## Why this change?
This is in preparation for allowing to show extensions locally when the
fetch fails based on the information available. Currently, this would
require a lot of duplication and would be tedious to add. With this in,
we can much more easily just construct an extension card with the
upstream metadata missing, removing the need for duplication.
Lastly, this also adds a component preview for extensions cards so we
can play around more easily with other designs.
Release Notes:
- Installed dev extensions will now show the features they provide and
will also respect feature filters.
GitHub issue search can't express the one filter we want here: "created
at least one business day ago." That's the whole reason the project
board #\87 exists — since we can't save it as a search, we keep a
project's membership in sync to stand in for it.
So: an hourly workflow runs script/github-triage-queue-board.py, which
adds the open issues that fall in the eligibility window to project #\87
and removes the ones that have aged out. Also wires the workflow into
the community automation failure Slack alert, so if it breaks we hear
about it.
Release Notes:
- N/A
Adds missing documentation about font fallbacks on `appearance.md` and
`all-settings.md`
`all-settings.md` only lacked terminal font fallback documentation so
that's the only thing I added there.
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [it's a doc update] Unsafe blocks (if any) have justifying comments
- [there is no ui] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [it's a doc update] Tests cover the new/changed behavior
- [i really hope that my extra bytes on documentation cause no
performance impacts] Performance impact has been considered and is
acceptable
Release Notes:
- N/A
When the image viewer reloads an image after the underlying file
changes, it now tracks the `RenderImage` currently displayed by the view
and drops that image’s atlas entry before replacing it with a newly
decoded render image. This prevents rapidly updated images from
accumulating atlas textures per reload while keeping cleanup scoped to
the window that displayed the image.
Closes#35894
Release Notes:
- Fixed a memory leak when previewing images that are repeatedly updated
on disk.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
Fixes#58492.
With Vim mode enabled and an editor focused in normal mode, Escape does
not close the release notes notification shown after an update. Vim
consumes Escape before the workspace can handle `menu::Cancel`.
## Solution
Add Windows-specific Escape bindings for `menu::Cancel` in Vim and Helix
normal modes. Place them after the existing Escape bindings so GPUI
tries `menu::Cancel` first.
This is limited to Windows because macOS and Linux already provide
non-conflicting `Ctrl-C` and `Ctrl-Escape` alternatives, respectively.
## Testing
Added regression coverage for dismissing workspace notifications with
Escape in Vim normal mode.
I verified the test passes and the visible notification is dismissed
locally.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
https://github.com/user-attachments/assets/3895385f-7be1-4c62-8d7c-05a5b580d855
---
Release Notes:
- Fixed release notes notifications not closing with `escape` when Vim
or Helix mode is enabled, on Windows.
Release Notes:
- copilot: Improve robustness of copilot chat provider by splitting
authorisation paths for edit predictions and chat. Note: Existing users
will have to re-authenticate with Copilot
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Closes#61410
## Summary
Tree-sitter bracket queries can become incomplete when recovering from
syntax errors. The existing code handled incorrect matches by collecting
the delimiters returned by the query and pairing them again in order.
The query missed the innermost closing parenthesis. The repair therefore
worked on an incomplete sequence, paired the innermost opening
parenthesis with the next available close, and shifted every remaining
pair outward.
## Solution
This change records the syntax-node kinds used by each bracket pattern
and, when a syntax layer contains errors, checks the concrete leaves
inside those error nodes for delimiters missing from the query output.
When the opening and closing kinds are different and the error range
remains balanced, the missing delimiters are included in the existing
reconstruction.
## Testing
Reproduced the issue using the C snippet from #22679 and verified that
each parenthesis is matched with its correctly nested partner.
Also verified that unbalanced code does not cause the recovery logic to
invent a missing bracket pair.
## How to Review
The relevant changes are in `BufferSnapshot::fetch_bracket_ranges` in
`crates/language/src/buffer.rs`.
The important distinction is between the bracket-query output and the
concrete syntax leaves inside an error node. Previously, the repair
could only rearrange delimiters present in the query output. It can now
detect when that output is incomplete, add the missing real delimiters,
and run the existing reconstruction over the complete set.
## 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)](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 incorrect bracket matching when syntax-error recovery omitted a
delimiter.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
Prevent accepted v4 edit predictions from moving the cursor past the
model's predicted position.
## Solution
Keep the cursor's base anchor fixed while applying inserted text, then
apply the model-provided offset. Add regression coverage based on the
reported cursor jump.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
# Objective
Instruct agents not to create persistent sibling threads without user
approval.
## Solution
Update the `create_thread` instructions to require an explicit request
or approval. Agents may still suggest creating a thread.
## Self-Review Checklist:
- [x] I’ve reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed’s UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
# Objective
Improve documentation to inform about toolchain in repl session and
avoid issues like https://github.com/zed-industries/zed/issues/60465
## Solution
- Add a note in documentation about using toolchain for change python
enviroment
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
Release Notes:
- N/A
---------
Co-authored-by: Kunall Banerjee <hey@kimchiii.space>
The notebook editor has actions for adding and moving cells but no way
to delete one. This adds `notebook::DeleteCell`:
- Trash icon button in the notebook toolbar (own group below
add-markdown/add-code, disabled when the notebook has no cells)
- Jupyter-style `d d` binding plus `backspace` in cell command mode
(macOS and Linux keymaps)
- Deletes the selected cell; selection moves to the neighboring cell,
focus returns to command mode, and the item is marked dirty via the
existing structural-change tracking so saving persists the deletion
Tested locally on macOS with the notebook feature enabled: button click
and bindings delete the selected cell and saving writes the result.
(Screenshots in comments.)
Release Notes:
- Added a delete-cell action (`d d` in command mode and a toolbar
button) to the notebook editor (preview-only).
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
JSX and TSX only treated the dot as a tag-name character during
linked-editing, so renaming a tag to a custom element name such as
`custom-el` stopped mirroring the closing tag at the dash.
A follow-up to https://github.com/zed-industries/zed/pull/43179, really.
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#58553.
Release Notes:
- Added support for linked-editing of custom elements in JSX/TSX
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
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)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes#52205.
Release Notes:
- Enabled Emmet completions in return and arrow function bodies for
JSX/TSX
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
## Purpose
While developing a theme for Zed I remarked that the schema available
doesn't mark colors in a way that Zed recognize to display the color
annotations:
```json
{
"$schema": "https://zed.dev/schema/themes/v0.2.0.json"
}
```
<img width="119" height="190" alt="Screenshot 2026-02-25 at 23 15 10"
src="https://github.com/user-attachments/assets/3f1bb703-cb26-4630-9598-3a7cb8873c20"
/>
But Zed has support for it when colors are marked with `"format":
"color"` in the schema:
<img width="127" height="186" alt="Screenshot 2026-02-25 at 23 14 58"
src="https://github.com/user-attachments/assets/1a9387a4-613a-4cf8-a3af-f6ac201bdf54"
/>
So I searched if the schema file was Open Source somewhere, discovered
it was generated from the codebase and attempted the change.
## Implementation
This is essentially done using a `ThemeColor` wrapper for the color
strings that implements `JsonSchema` with a dedicated regex for
validation and the color format specified. This ends up with a new
`$defs` of `Color` being specified and used:
```json
{
"$defs": {
"Color": {
"type": "string",
"format": "color",
"pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{4}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$"
}
}
}
```
## Other
- There is a small change I made for testing to the schema_generator
that adds an `--output` / `-o` flag. When provided it writes the
generated schema JSON to the specified file path instead of printing to
stdout. This was done to made testing easier but I can remove it or
split it to a separate PR (It's already a separate commit)
- For this PR to do anything a new schema version will need to be
published at something like `https://zed.dev/schema/themes/v0.3.0.json`
and documentation needs to be updated to point to it.
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing (Manual testing, couldn't find any existing good place to test
it)
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
I ran into this while conducting some tests. If you search for a channel
name in the Collab Panel and then try to “Add a Contact,” it seeds the
query with your search term from the current contents of that channel
search editor.
Opted to just drop that method altogether as it’s not being used
anywhere else.
## 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:
- Fixed the contact finder inheriting the channel search query in the
Collab Panel
## Description
Adds native macOS file drag out support for Project Panel entries. Local
file paths are resolved only when a drag gesture starts, remote or
missing paths are skipped, and unsupported platforms keep the default
no-op behavior.
The macOS implementation starts an AppKit drag session with file URL
pasteboard items, allows Finder and other external apps to choose copy
or move, keeps in-app GPUI drag/drop behavior in control for internal
drags, and clears the active drag state when the native session ends.
https://github.com/user-attachments/assets/42909389-1a32-4574-a200-9a14b913f55f
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
- [ ] Performance impact has been considered and is acceptable
Closes#55370
Release Notes:
- Added support for dragging files from the Project Panel to external
macOS apps.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
- Fixes#59409. Closes FR-143. Zed's managed npm directory reaches
10–17GB on machines that use
external agents, and is never pruned.
- Two independent causes: registry agents are launched with `npm exec`,
which keys its
install directory on the requested version, so every agent release
leaves a full
~250MB copy behind; and npm never evicts anything from its download
cache.
## Solution
- Install registry agents into a directory we reuse, so npm replaces the
previous
version in place instead of accumulating one copy per release. As a side
effect,
updates now download only the changed dependencies rather than the whole
tree.
- Empty the download cache on startup. Nothing in it needs to survive a
restart, since
packages are installed elsewhere. It has to go wholesale: deleting
individual
downloads leaves npm's index pointing at missing files, and npm then
fails with
`ENOENT` rather than fetching them again.
- The first launch after this does one full agent install as it moves
into its new
home, and reclaims whatever the old directories were holding.
## Testing
- Installed the real agent at 0.33.1, then upgraded to 0.42.0 in the
same directory:
253MB → 256MB, against two separate copies today. The resolved
executable answers an
ACP `initialize`.
- macOS only. Windows deserves a look — it should be better than before,
since the
agent is now launched as a plain `.js` file with Node instead of through
npm's `.cmd`
shim, but I can't verify it.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed the bundled npm cache growing without bound, which could consume
many gigabytes of disk.
### Objective
PR #58902 made native macOS window chrome follow the selected theme, but
AppKit can synchronously invoke `viewDidChangeEffectiveAppearance` while
the settings observer holds an `App` borrow. `handle.update` then fails
with `RefCell already borrowed`, leaving `Window::appearance()` and its
observers stale.
### Steps to reproduce
1. Set Zed's theme mode to Dark.
2. Set macOS Appearance to Light.
3. Change Zed's theme mode to System.
4. Notice that the window chrome switches to light, but Zed's UI remains
dark.
https://github.com/user-attachments/assets/f91962cc-76ba-4d8e-b587-2a2343f365ba
### Expectation
Zed should switch to its configured light theme when returning to System
mode.
### Solution
Defer `Window::appearance_changed` to the foreground executor so the
current `App` borrow finishes before refreshing the cached appearance
and notifying observers.
### Testing
- Added a regression test.
### Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
# Objective
- Fix multi-stroke keybindings such as `ctrl-x k` being intercepted by
the macOS Japanese IME before GPUI can complete the binding.
- Preserve IME-first handling for ordinary Japanese text input and
active marked-text composition.
- Fixes#56043.
## Solution
- Stop preferring IME-first printable input while a valid multi-stroke
keybinding is pending. This allows the next printable keystroke to reach
GPUI and complete the binding.
- Consider pending input active only when it belongs to the window's
current focus. This prevents stale pending state after a focus change or
blur from bypassing normal IME handling.
- Preserve the existing macOS active-composition path, so marked text,
candidate selection, and composition commands continue to reach
`NSTextInputContext` first.
## Testing
Manually tested on macOS using Apple’s built-in Japanese–Romaji/Hiragana
input source with a `ctrl-x k` keybinding. Also added regression test
for pending keybinding routing.
## 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 multi-stroke keybindings not completing when using a Japanese
IME on macOS.
---------
Co-authored-by: Tom Houlé <tom@tomhoule.com>
Fixes the bug that made us remove the sandbox.
The bug in question was very dumb:
- there is sophisticated machinery for detecting whether a user-granted
writable path is swapped out for a symlink in the timing gap between
approval and sandbox creation
- there was no equivalent machinery to do the same for the (much larger)
gap between a user *persisting an approval* (either for the current
thread or permanently via settings)
- The fix is essentially to store canonical (i.e. absolute and
symlink-free at all depths) paths as the source of truth, but retain the
raw path for display purposes
- On WSL, there is extra care needed becasue of the bidirectional
mounting (i.e. `/mnt/c/...` and `\\wsl.localhost\Ubuntu\...`). In
particular, `/mnt/c/...` paths, since their inodes do not necessarily
pin NTFS file references, weaken the sandbox guarantees, and so we need
some extra UI to call this out and docs etc...
This also does not remove the feature flag, but just toggles it to
"enabled_for_all"
---
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Closes#39286
## Problem
Switching the keyboard layout on Wayland (e.g. GNOME's Super+Space)
makes the compositor briefly grab the keyboard, which deactivates the
Zed window. GPUI reports window deactivation as a blur of the focused
element (`WindowFocusEvent` is emitted with an empty
`current_focus_path`), so controls that dismiss or cancel on blur
treated it as the user abandoning them. The same happens when switching
to another app window. As discussed in #39286 with @MrSubidubi, the
desired behavior is to keep these controls open and focused across
window deactivation.
## Fix
Guard the blur-driven cancel/dismiss handlers with
`window.is_window_active()`, following the pattern established for
pickers in #41320:
- Project panel: in-progress rename / new file / new directory inputs
are no longer cancelled when the window is deactivated
- Collab panel: in-progress channel rename is no longer cancelled
- Go to Line: the dialog is no longer dismissed
In-window focus changes (clicking elsewhere, Escape) keep the existing
commit/cancel semantics. The terminal tab rename needed no change: it
re-checks `FocusHandle::is_focused`, which reads `window.focus` and that
survives deactivation. Command palette, file finder, and outline were
already fixed by #41320.
Added a regression test (`test_rename_survives_window_deactivation`)
that starts a rename, deactivates the window via the test platform, and
asserts the edit state survives.
Two milder siblings were left unchanged to keep this PR focused,
flagging them for a maintainer decision: the notebook markdown cell
exits edit mode on blur (`crates/repl/src/notebook/cell.rs`), and the
diagnostics view prunes diagnosticless buffers on blur
(`crates/diagnostics/src/diagnostics.rs`).
Longer term it may be worth carrying the blur cause in the event itself
(e.g. a `FocusMoved` vs `WindowDeactivated` reason on `FocusOutEvent`
and `EditorEvent::Blurred`), so each handler has to state which causes
it handles instead of relying on an opt-in guard; happy to file a
separate issue for that.
## Before
https://github.com/user-attachments/assets/9eec1bb5-1881-4b3a-80ef-a287e23219ca
## After
https://github.com/user-attachments/assets/49b8775c-175a-4882-835d-871432c0b315
## Suggested .rules additions
> Handlers that cancel or dismiss UI on blur (`EditorEvent::Blurred`,
`on_blur`, `on_focus_out`) must check `window.is_window_active()` first:
GPUI reports window deactivation (app switch, layout switcher grabbing
the keyboard) as a blur of the focused element, and dismissing there
loses user input.
Release Notes:
- Fixed in-progress file renames, channel renames, and the Go to Line
dialog being cancelled when the window is deactivated, e.g. by a
keyboard layout switch on Wayland or by switching to another application
([#39286](https://github.com/zed-industries/zed/issues/39286)).
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Fixes#60270.
## Summary
- Accept MCP HTTP SSE `data:` fields when the optional space after the
colon is omitted.
- Add a regression test covering `data:{...}` streamable HTTP responses.
## Tests
- `cargo fmt --check`
- `cargo test -p context_server
test_sse_data_field_without_space_after_colon -- --nocapture`
- `cargo test -p context_server -- --nocapture`
Release Notes:
- Fixed MCP HTTP context servers timing out when SSE data fields omit
the optional space after the colon.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
# Objective
A failed restore, for example, a collision at the original path, used to
remove the `TrashedEntry` from the registry before attempting the
operation, so any later attempt with the same `TrashId` would report an
`AlreadyRestored` error, even though the item still sat in the system
trash.
## Solution
Update both `RealFs::restore` and `FakeFs::restore` to remove the entry
only after the restore succeeds. There's also a small unrelated change
in `ProjectPanel::drag_onto` to log, rather than silently discard, a
failed undo-history record in the project panel, matching existing call
sites.
## Testing
Introduced a new test for these changes
– `restore_can_be_retried_after_collision` .
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
# Objective
- GPUI provides `grid_cols_min_content()` and `grid_cols_max_content()`,
but the `grid_rows_*_content()` methods are missing.
## Solution
- This PR adds the `grid_rows_min_content()` and
`grid_rows_max_content()` methods, and renames the enum
`TemplateColumnMinSize` to `GridTemplateMinSize`.
## Testing
- I have tested locally.
## 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
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
# Objective
Fixes#61687
Prior to #60772, an `abs_path` outside the `repo_root` would cause a
panic. That PR changed it to return the `abs_path` itself, preventing
the panic, but allowing all parents of `repo_root` to be subject to the
global ignore.
This is not what git itself does.
## Solution
- This change returns `false` when the `abs_path` is outside the
`root_repo`, preventing the panic but also not returning the `abs_path`
## Testing
- One in-memory test
- Manual test by building Zed and confirming the project pane changes
(pictured below)
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
### Before, with the bug
<img width="1430" height="814" alt="Screenshot 2026-07-26 at 11 44
11 AM"
src="https://github.com/user-attachments/assets/66e3bb95-4f45-4fd9-a1e4-e7f253f092eb"
/>
### After the fix
<img width="1568" height="1042" alt="Screenshot 2026-07-26 at 12 34
58 PM"
src="https://github.com/user-attachments/assets/588eb01d-830a-4c22-93c0-667742de90b6"
/>
Release Notes:
- Fixed the project panel's global gitignore incorrectly matching parent
directories of a repository
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Use `web_time::Instant` instead of `std::time::Instant` when advancing
scrollbar animations. This uses the web platform's compatible clock in
WASM builds.
Release Notes:
- N/A
Instead of a dropdown, it is now just a one-click icon.
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 theme toggle for the documentation website
---------
Co-authored-by: Gaauwe Rombouts <mail@grombouts.nl>
This builds on #59521 and addresses @dinocosta's comment
https://github.com/zed-industries/zed/pull/59521#pullrequestreview-4563460240
Looking at it again, I think
https://github.com/zed-industries/zed/pull/59521/commits/e7ed02cc4963868632ba97a1fb09f1b398d3b22b
was too conservative. Re-running the access check on every commit,
stage, or checkout, doesn't really make sense. Access depends on `.git`
ownership/permissions and on the global `safe.directory` config.
File writes in `.git/` can actually never change the access. The only
case where this access can change is an external command that changes
the ownership or permission of the folder. That sounds like a quite rare
edge case and I'm not 100% sure whether all file watchers even currently
correctly trigger events for ownership changes. @dinocosta Let me know
what you think.
Release Notes:
- Improved Git Panel performance by avoiding redundant repository access
checks.
Co-authored-by: dino <dinojoaocosta@gmail.com>
- Add `ForegroundExecutor::spawn_when_idle(timeout, future)`, which
schedules `future` to be polled on the main thread when the main thread
is idle, but tries to do so no later than `timeout` after the current
instant (with the same `timeout` being applied to subsequent polls of
the same future)
- Add `Platform::dispatch_on_main_thread_when_idle(runnable, timeout)`
as the basis for `spawn_when_idle`, with a default implementation that
ignores the timeout and delegates to `dispatch_on_main_thread(runnable,
Priority::Low)`
- Implement `dispatch_on_main_thread_when_idle` for the web platform
using
[`requestIdleCallback`](https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback)
Release Notes:
- N/A
## Summary
`gpui_macos` links two private CoreGraphics Services APIs
unconditionally:
```rust
#[link(name = "CoreGraphics", kind = "framework")]
unsafe extern "C" {
fn CGSMainConnectionID() -> id;
fn CGSSetWindowBackgroundBlurRadius(...) -> i32;
}
```
Apple rejects App Store submissions that reference private APIs, so any
application built on GPUI is ineligible for the Mac App Store —
regardless of
whether it ever sets `WindowBackgroundAppearance::Blurred`, since the
symbols are
linked either way.
Their only call site is the `NSAppKitVersionNumber <
NSAppKitVersionNumber12_0`
branch: macOS 11 and earlier. On macOS 12+ the same effect already goes
through
`NSVisualEffectView`, which the existing comment notes is the better
path anyway
(it downsamples the backdrop and gives more control over the effect
layer).
This deletes the legacy branch and the extern block.
## Changed from the previous revision of this PR
This originally added a `macos_app_store` feature gate. @reflectronic
suggested
deleting the legacy `WindowBackgroundAppearance::Blurred` support
instead of
carrying a flag — that is the better call and this PR now does that.
It is the stronger fix on the merits, not just the smaller one: deleting
makes
every GPUI consumer App Store eligible, whereas a feature flag only
helps those
who opt in and leaves the default build ineligible. It also removes a
conditional-compilation path rather than adding one. The diff went from
3 files / +13 −7 to **1 file / +23 −52**.
## Notes for review
Two details that are easy to miss:
- `this.native_window.windowNumber()` resolved through cocoa's
**`NSEvent`**
trait rather than `NSWindow` — `id` is untyped, so it picks up every
trait in
scope. Removing that call makes the `NSEvent` import genuinely unused,
so it is
dropped. Verified against a build of unmodified `main`, which does not
emit
that warning, to confirm this is a consequence of the change and not
pre-existing.
- `NSAppKitVersionNumber` and `NSAppKitVersionNumber12_0` had no other
users and
are dropped with it.
The `NSVisualEffectView` branch is preserved verbatim; the only change
to it is
one level of de-indentation.
## Behaviour change
On macOS 11 and earlier, `WindowBackgroundAppearance::Blurred` no longer
applies
a blur — the window falls back to the `NSVisualEffectView` path, which
those
releases handle via `CAProxyLayer` rather than concrete sublayers. macOS
11 is
past end of life. Every other platform and macOS 12+ are unaffected.
## Verification
`cargo check -p gpui_macos` on macOS — clean, no errors and no new
warnings.
The identical change was also applied to a downstream GPUI fork and
built against
a ~60k-line application using `gpui-component`, where CI passed on
macOS, Ubuntu
and Windows.
Release Notes:
- N/A
# Objective
- Fix V4 edit prediction requests failing for local Windows projects
because native path separators do not match Unix-formatted context paths
on the server.
## Solution
- Canonicalize serialized buffer paths through the existing `RelPath`
representation.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Suggested .rules additions
- Paths serialized for edit prediction APIs must use `RelPath`'s Unix
representation rather than platform-native `PathBuf` formatting.
---
Release Notes:
- N/A
# Objective
Fixes#59129.
`vim::HelixJumpToWord` currently treats its two-character target labels
as text input. When an IME is active, the printable label keys can
therefore enter the IME composition window instead of completing the
jump.
## Solution
- Treat an active Helix jump as command input rather than character
input, preventing the platform input handler from preferring the IME for
its label keys.
- After normal keybinding resolution, handle action-less, unmodified
label keydowns directly from the keystroke's ASCII-equivalent key. This
preserves label matching on non-ASCII keyboard layouts while leaving
Escape, custom bindings, and Ctrl/Alt/Cmd/Function shortcuts untouched.
- Stop propagation after consuming a label key so the platform does not
subsequently forward it to the IME.
- Keep the existing committed-text handling as a fallback for other
input paths.
This is complementary to #61270: that PR handles pending GPUI keybinding
chords before IME input, while this change handles Helix jump labels
after the initiating action has resolved. The changes are also
file-disjoint.
## Testing
- Added a regression test using the issue's `s` → `vim::HelixJumpToWord`
binding. The test verifies that:
- no GPUI keybinding chord is pending;
- Helix jump does not accept text input or prefer the IME;
- both raw label keydown events are consumed; and
- the expected jump completes.
- Manually tested on macOS with both ABC and Japanese Romaji input
sources.
## 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 Helix jump-to-word label input being intercepted by IMEs.
Closes#60985
Clicking a link to a Markdown file from a Markdown preview now opens the
target in a preview instead of the raw editor buffer. `alt`-click opens
the raw source editor instead.
- If there exists existing preview of that file it is reused. A link
back to the file being previewed navigates in place.
- `file.md#heading-slug` scrolls the preview to the linked heading.
- `file.md:42:5`, `file.md#L42` and `file.md#L42C5` open the preview
scrolled to that position with the cursor placed there. Non-Markdown
targets keep the existing behavior from #60864 (raw editor at the
position).
Added tests covering these and more cases.
Release Notes:
- Improved Markdown preview links: links to Markdown files now open in a
preview (scrolled to the linked heading or position) instead of the raw
file, and `alt`-click opens the raw source instead.
- Fixed GitHub-style `#L<line>C<column>` link fragments not placing the
cursor at the linked position.
Remco Smits