Closes#22490
## Summary
• Keep kill-ring state as a dedicated global structure (`text`,
`metadata`, `row`, `column`, `buffer_id`) instead of a raw clipboard
wrapper.
• Update `editor::KillRingCut` to append consecutive empty-line kills
only when all are true:
- one selection only
- previous selection was empty
- same row/column
- same buffer
• Preserve existing behavior for non-empty and multi-selection cuts by
replacing the ring payload instead of appending.
• Preserve yank metadata behavior through the existing clipboard
selection metadata path.
• Add regression coverage in
`editor_tests::test_kill_ring_cut_accumulates_multi_line_kills`.
## Verification
• `cargo fmt --all -- --check`
• `./script/check-keymaps`
• `./script/clippy -p editor`
• `cargo test -p editor -- --nocapture`
• `cargo test -p editor
editor_tests::test_kill_ring_cut_accumulates_multi_line_kills --
--exact`
• `cargo test -p editor test_cut_line_ends -- --exact`
## Manual
• `Ctrl+K`, `Ctrl+K`, `Ctrl+Y` with repeated line-end kills at same
caret location pastes concatenated text.
• Non-empty selection cut and multi-selection still replace as before
(no unintended append).
• Cut in one buffer then cut in another does not cross-append.
• Moving caret between kills does not append.
• Undo/redo around cut+yank path works cleanly.
Release Notes:
- Fixed Emacs-style kill-ring behavior so successive `KillRingCut`
operations at the same caret context are accumulated and pasted together
via one `KillRingYank`, while preserving existing non-empty selection
and multi-selection semantics.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
fixes#53726
Compute the base delta from the first visible, non-filtered row instead
of using rows.start. This avoids off-by-one numbering when rows.start is
a wrapped continuation that gets filtered out. Ensure deleted lines
still advance the relative counter even when they are not numbered. Add
a test for the wrapped scrolling case.
P.S. This is my first time using rust for a serious pull request and
let's say I'm a little bit rusty with 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 is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content 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
This PR makes two changes:
1. detect() now returns the line number of the first match instead of
just a boolean.
2. This line number (line_hint) is threaded through the pipeline and
passed as a subrange to query.search in full buffer scan, so the full
buffer scan starts from where the first match was already found instead
of the beginning of the file.
## Scope
- This optimization only applies to **local search** (not remote).
- It is only effective for **single-line text and single-line regex**
queries. For multiline queries, `detect()` returns `line_hint = 0`, so
the full buffer is scanned from the beginning as before.
- It does not apply to already-open buffers, which always receive
`line_hint = 0`.
## Test
i tried to search the word "typeably" in the file
"pkgs/development/haskell-modules/hackage-packages.nix" of the repo
[nixpkgs](https://github.com/NixOS/nixpkgs) given in the comment:
[comment](https://github.com/zed-industries/zed/issues/38799#issuecomment-4088491295).
Result seems promising:
**with line_hint:
search: 45.21ms**
**without line_hint:
search: 508.05ms**
I measured the time within the function: "handle_find_all_matches"
## Assumption
The core assumption is: if the search query is long enough (after 4 or 5
chars), the probability of finding multiple matches in a single file is
low. In that case, re-scanning the content before line_hint is
unnecessary — detect() function already confirmed there is no match
there.
Changes maybe can make an improvement on issues #38799 and #58905
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Automates the Guild contributor program on project board #74 so the
cohort is recognized and kept unblocked without manual babysitting.
- Move a board issue to In Progress when a Guild member self-assigns it,
and post a friendly heads-up when they are assigned an issue that is not
on the board.
- Flag when a Guild member opens a new PR while another of theirs is
still open, to help them land work before spreading thin.
- Check in on quiet assignments and, if an assignee stays silent, free
the issue back to a to-do column so others can pick it up; a "guild
hold" label lets maintainers pause check-ins after they have followed
up.
- Share a weekly digest of what the Guild shipped.
- Label PRs from Guild members and recognize a Guild contributor tier on
the community PR board.
Release Notes:
- N/A
# Objective
Microsoft has decoupled the MSVC version from the Visual Studio version
starting with Visual Studio 2026 (see [this
blog](https://devblogs.microsoft.com/cppblog/new-release-cadence-and-support-lifecycle-for-msvc-build-tools/)),
meaning that the previous traditional naming conventions were obsolete.
For Visual Studio 2026 (including future newer versions of VS) users,
the existing docs will probably confuse them, as they cannot find out
the components named like "MSVC v145 - VS 2026 C++ ..." in present
Visual Studio Installer.
## Solution
Add a note next to the dependencies.
## Testing
Docs are no need to test. (Maybe?)
## 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
While profiling https://github.com/zed-industries/zed/issues/60102 I
noticed `GitStore::update_repositories_from_worktree` does unneeded
work. It fires on every `WorktreeUpdatedGitRepositories` event, which
under filesystem pressure (`rescan: user dropped`) repeats roughly once
per second and can fire more frequently in a large monorepo with many
repositories, since the redundant work scales with the number of
repositories.
## Solution
In `crates/project/src/git_store.rs`:
- Drop the per-iteration `Arc<Path>` clone in the repo lookup; compare
the borrowed reference instead.
- Hoist the `is_trusted` (`can_trust`) computation out of the loop since
it only depends on `worktree_id`.
No behavior change is intended; this is purely reducing redundant work
per event.
## Notes
The *frequency* of these events originates upstream in
`LocalWorktree::changed_repos` (`crates/worktree/src/worktree.rs`),
which re-emits an `UpdatedGitRepository` whenever `git_dir_scan_id`
changes on a full rescan. That path is intentionally left untouched here
since it involves scan semantics; this PR only addresses the redundant
work on the consumer side.
## 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
Make images nested inside markdown links (e.g., README badges)
clickable, so they behave like normal markdown links.
Previously, linked images rendered correctly but were not interactive in
markdown previews: they did not show a pointer cursor, could not be
clicked to open their target URL, and did not expose link actions
through the context menu.
## Solution
Changed the `MarkdownElement` to detect when an `<img>` tag is inside a
`<a>` tag during rendering. When a linked image is rendered:
- The wrapper `div` gets a `cursor_pointer` style and an `on_click`
handler that opens the link URL (or delegates to the `on_url_click`
callback if set).
- The wrapper also captures right-click events to populate the context
menu with "Copy Link" via `capture_for_context_menu`.
- The `on_url_click` closure type was changed from `Box<dyn Fn>` to
`Rc<dyn Fn>` to allow cloning across multiple handlers.
- When a linked image fails to load, the fallback element's `on_click`
now calls `cx.stop_propagation()` to prevent the event from bubbling to
the parent link wrapper and opening the URL twice.
The feature is gated behind `!self.style.prevent_mouse_interaction` so
it respects existing interaction-prevention settings.
## Testing
- `cargo test -p markdown`: 95 tests passed.
- Manually verified in markdown preview that badge/image links open
correctly and right-click shows "Copy Link".
- Verified existing markdown tests continue to pass.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed images inside markdown links not being clickable.
https://github.com/user-attachments/assets/df2a8d8f-b002-47f9-b139-815ee713700b
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
This PR makes the `markdown_preview_font_size` setting be based on the
UI font size instead of the buffer UI font size. I typically use a much
smaller code font than UI font, and that made reading the markdown
preview super small. I don't think this will be uncommon because the
dimensions between mono and non-mono typefaces are different...
Release Notes:
- Changed the markdown preview to fall back to the UI font size instead
of the buffer font size when `markdown_preview_font_size` is unset.
WSL downloads a linux zed binary for the sandbox helper. But the flag is
set on the `zed-editor` binary, not the `zed` cli binary. This fixes
that
---
Release Notes:
- N/A or Added/Fixed/Improved ...
## Summary
When formatting specific ranges (e.g. via Format Selections), trailing
whitespace removal and final newline enforcement currently operate on
the entire file. This PR makes these operations range-aware, so they
only affect lines within the target ranges.
As noted in #16509, users want `remove_trailing_whitespace_on_save` and
`ensure_final_newline_on_save` to suppress jitter by only touching
changed lines. This PR provides the foundational infrastructure for that
— range-based whitespace and newline operations — which a follow-up PR
will wire into the `format_on_save` modifications mode.
## Changes
- Added `remove_trailing_whitespace_in_ranges` and
`ensure_final_newline_in_range` to `Buffer`
- When a `FormattableBuffer` has ranges set, whitespace and newline
operations now use the range-based variants
- `format_ranges_via_lsp` returns `Ok(None)` instead of an error when
the LSP doesn't support range formatting
- Extracted `anchor_ranges_to_row_ranges` helper to deduplicate
conversion logic
<details><summary>Tests (4)</summary>
- `test_trailing_whitespace_in_ranges` — only modified lines have
whitespace removed
- `test_trailing_whitespace_empty_ranges` — empty ranges → no changes
- `test_final_newline_modified_last_line` — newline added when last line
is in range
- `test_final_newline_unmodified_last_line` — newline not added when
last line is outside range
</details>
---
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 Format Selection to scope trailing whitespace removal and
final newline enforcement to the selected range instead of the entire
file
- Improved handling of LSP servers that do not support range formatting
by gracefully skipping instead of producing an error
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes#50210
Bracket colorization currently runs theme accents through
`ensure_minimum_contrast`, which can significantly alter authored
palette colors in order to satisfy a single foreground-vs-background
target. In practice, that makes rainbow brackets drift away from the
theme colors they are supposed to reflect.
This PR keeps bracket colorization as a single automatic behavior, but
changes how the palette is derived:
- preserve authored accent colors when they already work
- adjust only the specific accents that are too weak against the editor
background
- only reorder the palette when adjacent bracket levels are still too
similar after that
The implementation is staged because bracket colorization has to handle
two separate problems:
- **Bracket-vs-Background Readability**: is an individual bracket
visible against the editor background?
- **Adjacent Bracket Separation**: can you still distinguish one nesting
level from the next?
Those two constraints are also why the implementation cannot simply
defer to whatever accent colors the theme provides. Some themes,
including the bundled One and Ayu, do not define explicit accents at
all, so bracket colorization falls back to Zed's shared default accent
palette. That palette was not designed with any particular theme's
background in mind, which makes the background contrast check especially
important for those cases.
That is why the previous `ensure_minimum_contrast(..., 55.0)` path is
not enough on its own. It addresses foreground-vs-background
readability, but if lightness-only adjustment cannot satisfy that target
it escalates to saturation reduction and then black/white fallback.
This PR instead keeps the bracket-specific background fix bounded and
lightness-only in OKLCH, so the resulting color stays much closer to the
authored accent.
### How it works
- **Background Contrast Correction**: accents that fall below the APCA
floor against the editor background are adjusted by changing OKLCH
lightness only, preserving hue and chroma
- **Adjacency Correction**: if the resulting palette is still too weak
between neighboring nesting levels, the palette is reordered
conservatively to improve adjacent separation
That ordering matters. Doing the reorder first can easily be undone by
the background-fix step.
### Color measurement
- background contrast uses APCA, via the existing `apca_contrast` path
- adjacent bracket separation uses OKLab Euclidean distance
APCA is the right tool for bracket-vs-background readability, but it is
not designed to compare two foreground colors against each other. OKLab
distance is a better fit for detecting when neighboring bracket levels
are perceptually too close.
### Thresholds
- background APCA floor: `30` on dark themes, `35` on light themes
- adjacent OKLab target: `0.08` on dark themes, `0.10` on light themes
- light-theme reorder tolerance band: reorder only triggers below
`0.095`, avoiding threshold-artifact reordering on palettes that are
visually fine but narrowly miss `0.10`
### Validation
- `cargo test -p editor bracket_colorization`
- manual comparison on bundled One, Ayu, and Gruvbox theme families
Release Notes:
- Improved bracket colorization by preserving theme accent colors when
possible and applying targeted contrast fixes only when needed.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes AI-432
The turn-end action buttons in the agent panel (scroll to top, scroll to
most recent prompt, open as markdown, thumbs up/down, share/sync) are
now exposed as local slash commands in the message editor instead of
buttons rendered at the end of each turn. The actions themselves are
unchanged — this is just a different way to access them.
Release Notes:
- Changed some of the agent panel's turn-end action buttons into slash
commands in the message editor.
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
When files are dragged into the terminal, paths were formatted using
Rust's Debug format (`{path:?}`), which wraps them in double quotes.
This caused issues with programs like Claude Code that parse bare paths
from terminal input — quoted paths were treated as plain text instead of
file references.
This change replaces double-quote wrapping with backslash escaping for
special shell characters on Unix, which is both valid shell syntax and
compatible with path-parsing tools running in the terminal. On non-Unix
platforms the previous behavior is preserved.
Tested on macOS only. Unable to verify Windows behavior.
Fixes#57471
Release Notes:
- Fixed/ file drag-and-drop into terminal inserting double-quoted paths,
which prevented tools like Claude Code from recognizing them as file
references.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
Zed uses `pet` to auto-discover Python virtual environments. When
opening Python projects, there is a large amount of log spam from `pet`
output, which is not useful:
```
2026-07-01T22:32:07+08:00 INFO [pet::find] find_and_report_envs; search_scope=None
2026-07-01T22:32:07+08:00 INFO [lsp] starting language server process. binary path: "/usr/bin/ty", working directory: "/home/xin/works/test/test_python", args: ["server"]
2026-07-01T22:32:07+08:00 INFO [pet::find] locators_phase;
2026-07-01T22:32:07+08:00 INFO [pet::find] path_search_phase;
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=PipEnv
2026-07-01T22:32:07+08:00 INFO [pet::find] workspace_search_phase;
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Poetry
2026-07-01T22:32:07+08:00 INFO [pet::find] global_virtualenvs_phase;
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Venv
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=VirtualEnv
2026-07-01T22:32:07+08:00 INFO [pet::find] find_python_environments_in_workspace_folder_recursive; workspace_folder="/home/xin/works/test/test_python" workspace=/home/xin/works/test/test_python
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Homebrew
2026-07-01T22:32:07+08:00 INFO [lsp] starting language server process. binary path: "/usr/bin/ruff", working directory: "/home/xin/works/test/test_python", args: ["server"]
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=LinuxGlobal
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=VirtualEnvWrapper
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=["/home/xin/works/test/test_python/.venv/bin/python"] executable_count=1
2026-07-01T22:32:07+08:00 INFO [pet::locators] identify_python_environment_using_locators; env=PythonEnv { executable: "/home/xin/works/test/test_python/.venv/bin/python", prefix: Some("/home/xin/works/test/test_python/.venv"), version: None, symlinks: None } executable=/home/xin/works/test/test_python/.venv/bin/python
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=["/usr/bin/python", "/usr/bin/python3", "/usr/bin/python3.14"] executable_count=3
2026-07-01T22:32:07+08:00 INFO [pet::locators] identify_python_environment_using_locators; env=PythonEnv { executable: "/usr/bin/python", prefix: None, version: None, symlinks: None } executable=/usr/bin/python
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Poetry
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PipEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnvWrapper
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Venv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Homebrew
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=LinuxGlobal
2026-07-01T22:32:07+08:00 INFO [pet::locators] resolve_python_env; executable=/usr/bin/python
2026-07-01T22:32:07+08:00 INFO [pet::locators] identify_python_environment_using_locators; env=PythonEnv { executable: "/usr/bin/python3", prefix: None, version: None, symlinks: None } executable=/usr/bin/python3
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Poetry
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PipEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnvWrapper
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Venv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Homebrew
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=LinuxGlobal
2026-07-01T22:32:07+08:00 INFO [pet::locators] resolve_python_env; executable=/usr/bin/python3
2026-07-01T22:32:07+08:00 INFO [pet::locators] identify_python_environment_using_locators; env=PythonEnv { executable: "/usr/bin/python3.14", prefix: None, version: None, symlinks: None } executable=/usr/bin/python3.14
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Poetry
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PipEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnvWrapper
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Venv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Homebrew
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=LinuxGlobal
2026-07-01T22:32:07+08:00 INFO [pet::locators] resolve_python_env; executable=/usr/bin/python3.14
```
This PR is intended to remove this log spam.
## Solution
Add `pet` to the default log filters. Now, `INFO` logs from `pet` are
suppressed by default.
## Testing
Tested locally, and verified that there is no longer any `pet` log spam
in the Zed logs.
## 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 or Added/Fixed/Improved ...
Removes git sandbox feature
The reason is essentially:
- write access to a `.git` dir can be trivially escalated to unsandboxed
access
- therefore, it is misleading to offer git access separate from
unsandboxed access
- instead, we encourage the model to use `--no-optional-locks` to avoid
needing write access to `git status`, etc.
Adds sandboxing to fetch tool
---
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments N/A
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Remote `HEAD` refs such as `origin/HEAD` and `upstream/HEAD` are
symbolic refs that point to a remote's default branch. These refs can
appear in the branch picker, but selecting them shows this error prompt:
This happens because the local branch name is directly derived from the
selected ref, resulting in an attempted checkout of a local branch named
`HEAD`.
This change follows up on feedback from #57588, which just filtered
remote `HEAD` refs out of the branch picker to prevent the error prompt.
As mentioned in [this
comment](https://github.com/zed-industries/zed/pull/57588#issuecomment-4533477336),
I agree that the preferred behaviour should be to instead allow checking
them out - useful for repos with multiple remotes such as an upstream.
For example, if `refs/remotes/origin/HEAD` points to
`refs/remotes/origin/main`, selecting `origin/HEAD` now behaves like
selecting `origin/main`, switching to the corresponding local `main`
branch instead of trying to create or check out a branch named `HEAD`.
This does not fetch or pull from the remote; it uses the locally known
remote refs.
Release Notes:
- Fixed selecting remote HEAD refs from the branch picker
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Behind a feature flag as we iterate on the RFD
Release Notes:
- N/A
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
This makes it so that we show open the settings UI instead of the modal
when adding an MCP server when clicking on `Add server`:
<img width="240" height="320" alt="image"
src="https://github.com/user-attachments/assets/bc5e9059-1053-45d5-8fd5-acfb7da48a35"
/>
We still show the modal when installing an extension. Since we're
hopefully replacing MCP extensions with MCP registry support soon, we
can leave it as is for now.
Release Notes:
- N/A
## Summary
It is incremental step to solve issue #59825.
This PR addresses the need for facilitating quick edits for matches
obtained by ‘text_finder’. This makes the text finder remember the last
query, so you can jump to a match, make a quick edit, and reopen the
finder to the same results instead of typing the same query again.
## Problem
A common flow is, open the text editor, then jump to first match, edit
that file, then reopen the finder to continue for next matches. But on
the reopen, the query was seeded from under the cursor. And after
editing, the cursor is usually sitting on an unrelated word, and
previous search was lost. The root cause is priority, the word under the
cursor was seeding the query.
## Solution
Reorder query seeding so last query outranks the cursor word, then
cursor word can be dropped entirely, since last query is prioritized
over the word under cursor, the last query always wins, so checking the
cursor word afterwards is dead code. And JetBrains makes the same
choice, entirely ignores word on the cursor for seeding query. Explicit
selection still outranks the last query, since selecting text is usually
a deliberate choice.
### Before
1- Active project search query (if any)
2- Active buffer search query (if any)
3- Selected text or word under the cursor
4- Empty
### After
1- Active project search query (if any)
2- Active buffer search query (if any)
3- Selected text
4- Last query (of this project)
5- Empty
With updated order, this friction disappears (the same order is also
observed in JetBrains). To make the last query persistent, it is stored
per project in the database along with the active filters (case
sensitive, whole word, regex), so they also survive reopening the
project.
## Testing
- Manually verified the seed priority order between the options.
- Verified the last query is seeded when project is reopened.
- Verified filters are restored regardless of this query order.
Release Notes:
- Improved the text finder to seed the last query and filters to make
quick edits easier.
---------
Co-authored-by: ozacod <ozacod@users.noreply.github.com>
Co-authored-by: Yara 🏳️⚧️ <git@yara.blue>
Zed don't surface the fact that bookmarks can have labels/names now
anywhere except opening the bookmark name editor every time you place
one. This keeps the label/name mechanism but makes the default add
bookmark action add an unnamed one.
Next step is probably to enable holding shift (or some other modifier)
to place a named bookmark, or even a setting to switch between default
named vs unnamed.
Release Notes:
- N/A
# Objective
Zed supports trusting all projects under a given directory. However,
when a local Windows client connects to a remote Linux server, the trust
scope input rejects valid directories with the error "Enter an absolute
folder path", even though the path is correct.
<img width="681" height="374" alt="image"
src="https://github.com/user-attachments/assets/87f084fb-1213-4594-96cb-3de81f4789aa"
/>
The root cause is in the `validate_trust_scope` function:
https://github.com/zed-industries/zed/blob/970e93e88132737477e0ab5dc618faa29d1040ff/crates/workspace/src/security_modal.rs#L497-L519
which uses `Path::is_absolute()` to check whether the entered path is
absolute. On Windows, this method only considers paths with a drive
letter as absolute, so Unix-style paths like `/home/user` are never
recognized. When doing cross-platform remote development, valid trust
scopes are incorrectly rejected.
## Solution
The `util::paths` crate already provides a helper for this situation:
https://github.com/zed-industries/zed/blob/970e93e88132737477e0ab5dc618faa29d1040ff/crates/util/src/paths.rs#L575-L586
The fix
- Adds a `path_style: PathStyle` parameter to `validate_trust_scope` and
uses `util::paths::is_absolute()` in place of `Path::is_absolute()`.
- The call site in `edited_trust_scope` retrieves the path style from
the worktree store, which already tracks whether a connection is local
or remote and the remote host's path convention.
The associated unit tests were updated for the new function signature.
## Testing
Built and tested locally; `cargo test -p workspace` passed.
## 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 "Folder to trust" input rejecting valid folder paths when
connecting to a remote host that uses a different path style than the
local machine.
Closes AI-159
Closes AI-434
Closes AI-435
Release Notes:
- Key agent-related settings now live in the settings editor, close to
all other settings available in Zed. This specifically includes the move
of LLM providers, external agents, and MCP servers to the settings
editor.
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
This makes sure that the behaviour of the CLI matches that of the UI.
In Zed itself we always open a new window (e.g. when clicking on Open
Project in new window in the recent projects picker), but in the CLI we
where re-using existing windows even when specifying
"cli_default_open_behavior": "new_window".
This caused confusion, so this PR ensures that we always open a new
window, even if that folder is already open. We still focus the active
window in the case where the path is a subpath of a project that is
already open.
Can be tested with
```
cd crates/cli
cargo run -- --zed ../../target/debug/zed somefolder
```
Release Notes:
- cli: Ensure `zed somefolder` always opens a new window, even when
`cli_default_open_behavior` is set to `new_window` and the project is
already open
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#54160
Summary:
In Helix mode, rename could fail when the cursor was visually positioned
on the last character of a symbol. The editor renders some Vim/Helix
selections with the visible cursor offset from the selection head, but
rename was still using the raw selection head as the LSP prepare-rename
position.
This updates rename to use the visible cursor position for point lookup
when cursor offset rendering is active. It also adds regression coverage
for Helix rename and Vim visual rename.
Verification:
- `cargo check -p editor`
- `cargo fmt --check --package editor --package vim`
- `git diff --check -- crates\editor\src\editor.rs
crates\vim\src\test.rs`
- `test::test_rename`
- `test::test_helix_rename_uses_visible_cursor_position`
- `test::test_visual_rename_uses_visible_cursor_position`
Release Notes:
- Fixed Helix mode rename when the cursor is visually on the last
character of a symbol.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Helix's keymap to `Vertically center the line` (`align_view_center`
command) is `zc`
([documentation](https://docs.helix-editor.com/keymap.html#view-mode)).
Release Notes:
- Added Helix's `z c` keymap to editor, project panel and outline panel
to scroll cursor to center
Right now subpages are not searchable. Since we don't have the bandwidth
to implement this today, this PR adds support for having aliases users
can search for. E.g. if I search for `claude` I will see the LLM
provider subpage, whereas previously I would not see anything.
https://github.com/user-attachments/assets/25af5c5a-86d2-473b-b0dd-11141b12a089
Release Notes:
- N/A
Large change to sandboxing:
- fixes a nasty TOCTOU relating to a symlink swap attack, documented in
the `sandboxing/README.md`
- Adds UI and restrictions when in an untrusted workspace
- Adds tests for (soon to be removed) git support
---
Release Notes:
- N/A or Added/Fixed/Improved ...
This follows up on discussion #56551.
Right now, when Zed generates a commit message, it includes project
rules files like `AGENTS.md`, `CLAUDE.md`, and `.rules` in the prompt
alongside the git diff. That can add a lot of extra context for a task
that is really just summarizing the changes in a commit.
This PR adds an `include_project_rules` option to
`agent.commit_message_model`. When it is set to `false`, Zed skips
loading project rules when generating commit messages. If the option is
omitted, the current behavior stays the same.
Example:
```json
{
"agent": {
"commit_message_model": {
"provider": "anthropic",
"model": "claude-3-5-haiku",
"include_project_rules": false
}
}
}
```
I also updated the settings plumbing so this option is only used for commit message generation and defaults to true when not specified.
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:
- agent: Added setting to exclude project rules files from commit message generation prompts (`agent.commit_message_include_project_rules`)
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Now that we have `/compact` we want to make the "new from summary"
option less prominent. You can still manually handoff to a new thread by
@mentioning the thread in a new one (`@thread threadname`)
Release Notes:
- agent: Remove "New from summary" menu item from agent panel dropdown.
You can still @mention the thread in a new one, or run /compact
Co-authored-by: gaauwe <gaauwe@users.noreply.github.com>
# Objective
The objective is to improve Helix's default keymap within Zed as a few
are still missing.
These are all [default
keymaps](https://docs.helix-editor.com/keymap.html) i was using within
Helix but dissapointed they weren't working in Zed
There's more info in [Are we Helix
yet?](https://github.com/zed-industries/zed/discussions/33580#top)
## Solution
- Add `] g` and `[ g` for hunk navigation in helix mode, in helix this
is go to next/previous change which maps nicely to Zed's go to
next/previous hunk. (it was set to `c` here but this is incorrect and
doesn't match Helix's keymap.
- Add `alt-b` and `alt-e` for larger syntax node navigation in helix
mode, i use this a few times to go to the top of a function within the
body and Zed doesn't have it mapped.
- Add `] space` and `[ space` for inserting empty lines in helix mode.
This one was incorrectly implemented previously, after the `space` Zed
is waiting for input. It needs to be a direct chord added rather than on
`helix_next` mode.
- This means the space binding from the helix_next operator context is
redundant, so ive removed it
- Add `*` to use selection for find in helix mode. Helix mode is
slightly different and doesn't "go to next" on `*`, instead that becomes
the `/` register. This is pretty fundamental to helix navigation so
should be ported to Zed also.
- Move `] d` and `[ d` diagnostics navigation into helix_normal context.
Vim was already using this one but it wasn't shared with Helix. I've
moved it to the shared Vim and Helix block.
## Testing
I've tested these changes with a local build and each one works as
expected
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added `alt-b`/`alt-e` in Helix mode to move to the start/end of the
larger syntax node.
- Added `*` in Helix mode to set the current selection for search.
- Fixed Helix `[`/`]` navigation so `c` goes to the previous/next
comment and `g` to the previous/next hunk, and single-key follow-ups
like `g` no longer hang.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Summary:
- Use the compaction-aware request history when generating thread
summaries.
- Reuse the same compaction boundary logic for thread title generation,
including saved-thread title regeneration.
- Add regression tests for summary and title request construction with
compacted history.
Tests:
- `cargo test -p agent uses_compacted_history`
Release Notes:
- Improved agent thread summary and title generation to respect
compaction boundaries.
Co-authored-by: gaauwe <gaauwe@users.noreply.github.com>
# Objective
Closes EP-202
Prevent V4 edit predictions from leaking `<|user_cursor|>` markers into
users' buffers.
## Solution
- Strip cursor marker text from emitted prediction edits, including when
`text_diff` splits the marker across edit fragments.
- Preserve literal marker-like text that already exists in the buffer.
## Testing
- `cargo test -p edit_prediction prediction_edits_for_single_file_diff
-- --nocapture`
- `cargo test -p edit_prediction --lib`
- `cargo fmt --check`
## 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
After a filesystem watcher loses sync (e.g. a `git pull` that changes
many files overflows the backend's event queue), the backend can enqueue
many `Rescan` markers in quick succession. The dispatch thread processed
each one separately, and each rescan invokes every registration for that
watcher mode, so a single burst could kick off several full worktree
scans at once — leading to sustained CPU and an unresponsive project
panel.
This adds `dispatch_batch`, which handles the first event and drains the
events already waiting in the channel, forwarding at most one `Rescan`
per `WatcherMode` per drained batch while letting ordinary filesystem
events and errors pass through untouched. A later watcher overflow can
still trigger another recovery scan.
Reported with a reproduction and patch in #59610.
Release Notes:
- Batch file watcher rescan events to improve Zed's responsiveness under
heavy FS usage
# Objective
Fix the agent `terminal` tool in headless eval environments. In the eval
sandbox, terminal commands failed before the shell ran with `IOError:
Not a tty (os error 25)` because PTY setup attempted to acquire a
controlling terminal.
## Solution
- Add a `terminal::HeadlessTerminal` global that is set by `eval_cli`
only.
- When headless mode is enabled, run terminal task commands as plain
subprocesses with piped stdout/stderr instead of opening a PTY.
- Pump subprocess output through the existing terminal emulator/event
channel so output capture, completion, and task killing keep working.
- Build ACP terminal commands non-interactively in headless mode.
- Keep the normal editor terminal path unchanged when the global is
unset.
- Handle non-PTY output edge cases by preserving split CRLF sequences
and avoiding an indefinite wait if subprocess exit-status polling
errors.
## Testing
- `cargo fmt --all`
- `cargo test -p util non_interactive_omits_interactive_flag`
- `cargo test -p terminal test_no_pty_task_terminal_captures_output`
- `cargo test -p terminal test_convert_lf_to_crlf_preserves_split_crlf`
- `cargo test -p terminal test_write_output`
- `cargo check -p eval_cli`
- `git --no-pager diff --check`
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed the agent terminal tool failing with "Not a tty" in
headless/eval environments
Bennet Bo Fenner