<img width="1110" height="280" alt="Screenshot 2026-01-28 at 3 35 52 PM"
src="https://github.com/user-attachments/assets/4d467e2c-2e7b-4ec7-bc87-6f0df8e667f0"
/>
<img width="1094" height="411" alt="Screenshot 2026-01-28 at 3 40 54 PM"
src="https://github.com/user-attachments/assets/f559df93-e72e-4457-ba1b-f7d6239f3285"
/>
Previously, if a user configured `^ls` as an always-allow pattern, an
attacker could craft a command like `ls && rm -rf /` which would be
auto-approved because the regex only matched the beginning of the
command string.
Now the command is parsed into individual sub-commands (`ls`, `rm -rf
/`) and EACH sub-command must match an allow pattern for auto-approval.
This prevents shell injection attacks using operators like:
- `&&` and `||` (boolean operators)
- `;` and `&` (sequential/background execution)
- `|` (pipes)
- Newlines
- Command substitution (`$()` and backticks)
- Process substitution (`<()` and `>()`)
## Matching Logic
- **always_deny**: if ANY sub-command matches, deny the entire command
- **always_confirm**: if ANY sub-command matches, require confirmation
(unless always_deny matched, in which case deny)
- **always_allow**: ALL sub-commands must match for auto-approval
(unless always_confirm or always_deny matched, in which case defer to
those)
- If parsing fails, or if the shell is unsupported, then always_allow is
disabled for this command
As usual, `always_allow_tool_actions` supercedes all of these. If it is
`true`, then we always allow all tool calls, no questions asked.
## Shell Compatibility
The shell parser only supports POSIX-like command chaining syntax (`&&`,
`||`, `;`, `|`).
**Supported shells:** Posix (sh, bash, dash, zsh), Fish 3.0+, PowerShell
7+/Pwsh, Cmd, Xonsh, Csh, Tcsh
**Unsupported shells:** Nushell (uses `and`/`or` keywords), Elvish (uses
`and`/`or` keywords), Rc (Plan 9 shell - no `&&`/`||` operators)
For unsupported shells:
- The "Always allow" UI options are hidden for the terminal tool
- If the user has `always_allow` patterns configured in settings, they
will see a `Deny` with an explanatory error message
(No release notes because granular tool permissions are behind a feature
flag.)
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Previously, each Agent panel created its own `ThreadStore` instance, so
thread history updates wouldn't sync between open windows. Users had to
close and reopen windows to see threads created in other windows.
Now `ThreadStore` is initialized once as a global and shared across all
windows. When any window saves a thread, ThreadStore::reload() calls
cx.notify(), which notifies all NativeAgentSessionList observers,
causing all windows' history views to refresh.
Note: This only works for the native Zed agent. It also is only
improving the history view (thread titles)—this PR does not sync edits
between multiple windows when the same thread is open in each.
Release Notes:
- Improved Zed agent thread history to update across all open windows
Brought the Markdown output up to date with how Markdown is used in the
Agent panel. This fixed an issue with outputs that were too large for
the execution view as well as made sure that markdown would wrap.
<img width="3222" height="2334" alt="image"
src="https://github.com/user-attachments/assets/c65efa53-b792-4529-909a-9117053e30be"
/>
Release Notes:
- N/A
Closes #ISSUE
Store `ReleaseChannel` instead of `&'static str`. This allows displaying
other aspects about the channel than just the display name. Makes it
more concrete what is stored within the field, as it has limited
variants, as opposed to something like `session_id`
Release Notes:
- N/A *or* Added/Fixed/Improved ...
The inline git blame always calculated the difference in years for
commits based solely upon the difference between the years and not
actual time passed. This is currently somewhat unfortunate during
January, as for all dates starting from 2024 and lower, we would show `2
years ago`, even if the date was the 31st of December 2024.
This fixes/improves this to use the lower bound always instead, as I
find this much more intuitive - we can probably look into even better
formatting here at some other point.
Release Notes:
- Fixed an issue where relative time deltas would sometimes show as `n +
1 years` instead of the actual `n years`.
Closes #ISSUE
Make `ProtoConversion::to_proto` consume `self`. We never create more
than one `proto` type out of a single `dap` type, meaning having the
conversation be non-consuming has no benefits, while consuming allows us
to remove a bunch of clones.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
I'm used to having the Emacs mark-sexp command, which selects/extends
the selection to the start or end of a sexp/larger syntax node, so when
I found out the `move to {start,end} of larger syntax node` commands
were added, these seemed like a natural addition; especially since most
other commands in Zed seem to have movement and selection pairs, but
those didn't really feel like they did.
I did a really *lot* of tests (brainstormed ideas with GLM 4.7, then
wrote the actual test case strings myself, then had it convert them to
Rust, then made sure the tests made sense and passed), I'm not sure if
it's too much or too little, but I looked at the PR that added the `move
to` versions of these commands and it was also +~550 lines, so this
seemed in the ballpark 😅
I factored out the core syntax node finding logic from those commands
into a common function, so that both sets of commands could use it, just
with different code for modifying the editor state wrapped around — mine
just moves each selection's head, instead of totally resetting it.
Release Notes:
- Added commands for extending selections to syntax node boundaries.
i.e. `editor: select to start of larger syntax node` and `editor: select
to end of larger syntax node`.
Basically just replaced `SharedString::new("` with
`SharedShring::new_static("` which removes the allocation to `Arc<str>`.
Unfortunately this can't be enforced at compile time without trait
specialization which is only available on nightly. You could assert that
`TypeId`'s differ, but `TypeId` only exists at runtime.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
When working in a workspace with multiple repositories, the git panel
provides a repository picker to switch between them. However, there was
no visual indication of which repositories have uncommitted changes:
users had to either select each repository individually or check the
project panel where modified directories are highlighted.
This change adds git status icons to the repository picker, allowing
users to see at a glance which repositories contain changes (modified,
added, deleted, or conflicted files). The icons use the same visual
language already established for file status throughout the git panel.
Additionally, the repository picker now matches the branch picker's
styling for visual consistency:
- Added "Repositories" header
- Aligned popover width and positioning
- Added scrollbar
- Added check icon next to currently selected repo
- Added selected branch under repo list item
- Sort by display name is now case insensitive
Before:
<img width="1200" height="815" alt="Screenshot 2026-01-27 at 11 43 55"
src="https://github.com/user-attachments/assets/12c1008b-4724-44bf-80c9-e9ad97755090"
/>
After:
<img width="1761" height="1196" alt="Screenshot 2026-01-27 at 14 07 52"
src="https://github.com/user-attachments/assets/cd778f42-ade0-4da0-9732-2d8631c04124"
/>
Branch picker for style reference:
<img width="1200" height="815" alt="Screenshot 2026-01-27 at 11 44 03"
src="https://github.com/user-attachments/assets/369b0d29-8fed-4293-98c2-52c2d780fe9a"
/>
Release Notes:
- Git: Improved the project picker in the panel by also displaying the
GIt status icon on them, to clearly indicate which repos have changes.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR adds a check during extension compilation to ensure that every
compiled extension provides at least one feature, as otherwise, the
extension is useless to have.
With this in, compiling an extension that does not provide anything will
fail.
Release Notes:
- N/A
This PR adds the upsell banner for built-in agents in the ACP registry
page, meaning: if you search for Claude Code, Codex, or Gemini, we'll
display a banner communicating they're already available in Zed. This
may change one day, though, whenever we rely on their registry
implementation. I'm also removing the beta chip from the page here.
Release Notes:
- N/A
Previously, double-click word selection in markdown used simple
space-based boundaries, so `foo.bar()` would be selected as a single
word.
Now we use `CharClassifier` which properly handles word boundaries:
- **Regular markdown text**: Punctuation (`.`, `(`, `)`, etc.) now acts
as word boundaries. Double-clicking on `foo.bar()` selects just `foo` or
`bar`.
- **Code blocks**: Uses the language's word characters. For example, in
JavaScript, `$foo` and `#bar` are selected as whole words since `$` and
`#` are configured as word characters.
Release Notes:
- Improved double-click word selection in Agent Panel to respect
punctuation and language-specific word characters.
`LanguageServerSeed` is used as a key to identify language servers.
Previously, it included the entire `LspSettings`, which meant that
changing `lsp.<server>.settings` (dynamic configuration) would cause the
server to restart unnecessarily.
Dynamic settings can be updated via LSP's
`workspace/didChangeConfiguration` notification without requiring a
server restart. Only `binary` and `initialization_options` should be
part of the server identity, as changes to these genuinely require
restarting the server.
This is a follow-up fix to #35270 which introduced `LanguageServerSeed`
but inadvertently included dynamic settings in the server identity
(although I remember that this dynamic settings reflection stopped
working pretty recently, so there might be other commits besides #35270
that changed the behavior of `LanguageServerSeed`)
Closes #ISSUE
Release Notes:
- Fixed language servers unnecessarily restarting when changing
`lsp.<server>.settings` configuration. Dynamic settings are now properly
updated via `workspace/didChangeConfiguration` without requiring a
server restart.
## Summary
Adds three syntax highlighting captures that are used across multiple
language definitions but were missing from the documentation table in
`docs/src/extensions/languages.md`.
## Added Captures
| Capture | Used In |
|---------|---------|
| `@constant.builtin` | C, Go, C++, YAML, TSX |
| `@type.builtin` | C++, Python, Rust, JavaScript, TSX |
| `@variable.parameter` | TypeScript, JavaScript, Python, Rust, TSX,
Diff |
## Context
While working on a [PR to add named argument highlighting to the PHP
extension](https://github.com/zed-extensions/php/pull/95), I initially
used `@label` because the documentation didn't list
`@variable.parameter`. A reviewer pointed out that `@variable.parameter`
is actually supported and preferred - the docs were just outdated.
This PR fixes that documentation gap.
Release Notes:
- N/A
This setting brings Zed in parity with Sublime's `bold_folder_labels`.
The settings does just that, it makes directory labels bold. This
setting is
particularly useful for those who turn icons off, but do need a visual
queue (besides the chevron) to quickly tell apart files and folders.
Note: This PR depends on
https://github.com/zed-industries/zed/pull/47629.
Otherwise, the setting will appear to have no uneffect (unless you're
using a custom UI font). ZedSans has "bold" today, but that's too thick
for the project panel.
<img width="2282" height="1545" alt="zed-project-panel"
src="https://github.com/user-attachments/assets/63ccacc0-c00a-48b2-8e70-923aa6717956"
/>
Release Notes:
- Added `project_panel.bold_folder_labels` to show folder names with
bold text in the project panel (defaults to `false`).
- Remove the newlines in the unzip command string, which made it not
work.
- Fix spawning the terminal and tasks. Unfortunately, the Windows
OpenSSH server has limitations that require rather ugly workarounds.
Release Notes:
- N/A
Closes#47064Closes#20806
The previous implementation used Zed's custom fsevent crate, which
spawned a dedicated thread for each watched path. On large projects,
this could result in 100+ threads just for filesystem watching.
This PR removes the `fsevent` crate and switches to using `notify's`
FsEventWatcher directly. The notify implementation maintains a single
FSEvents stream that watches all paths on one thread. When paths are
added or removed, the stream is stopped, the path list is updated, and
the stream is restarted.
Ref: https://github.com/notify-rs/notify/blob/main/notify/src/fsevent.rs
As a result, Zed now uses one thread for filesystem watching regardless
of how many paths are watched.
Release Notes:
- On macOS, Zed now uses significantly fewer resources when watching
filesystem changes
---------
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
Co-authored-by: Anthony Eid <anthony@zed.dev>
This PR swaps the @ icon button in the message editor for a + one, which
opens a dropdown that displays context options you can add to the agent.
Aside from removing one step if you're wanting to add context first with
the mouse (in comparison to just inserting @ in the message editor),
this menu will also house skills you've created, whenever we get to
support to that. It also works to surface images and selections in a bit
more visible way as context options. So, effectivelly, this is a bit of
foundation work for further features to come. Here's what it looks like:
<img width="500" height="586" alt="Screenshot 2026-01-27 at 11 38@2x"
src="https://github.com/user-attachments/assets/551686ba-4629-4317-9177-1e942512a23c"
/>
Note that all the options you see in the menu should also be available
through simply typing @ in the message editor.
Release Notes:
- Agent: Added a menu for inserting context more easily with the mouse
in the agent panel.
The same way you can use `size` when width and height have the same
value, it should also be possible to write `min_size` and `max_size`.
This PR adds these two methods, which are also supported in Tailwind
(but not documented in v4, surprisingly!).
Release Notes:
- N/A
