When saving after a streaming edit, check if format-on-save is enabled
for the buffer's language and run formatting before saving.
(No release notes because we aren't using the streaming edit tool yet.)
Release Notes:
- N/A
Move shell command parsing logic (`extract_commands` and supporting
code) from the agent crate into a new `shell_command_parser` crate so it
can be reused by `agent_servers` for ACP permission checking.
Release Notes:
- N/A
TODO:
- [x] Review code
- [x] Decide whether to keep ignored API tests
Release Notes:
- Fixed a bug where cancelling a thread mid-thought would cause further
anthropic requests to fail
- Fixed a bug where the model configured on a thread would not be
persisted alongside that thread
This PR hardens the authorization flow for all file and directory tools.
## Sensitive settings protection
All file/directory tools (copy, move, create_directory, delete, save,
edit, streaming_edit) now detect and protect sensitive settings paths:
- Paths inside `.zed/` directories (local settings)
- Paths inside the global config directory (`~/.config/zed/` or
equivalent)
Even when the global default is `allow`, modifications to these paths
require explicit confirmation. The authorization dialog title is
annotated with "(local settings)" or "(settings)" to inform the user.
`sensitive_settings_kind` walks up ancestor directories to handle paths
where intermediate subdirectories don't exist yet (e.g.
`~/.config/zed/new_subdir/evil.json`).
## Deferred filesystem operations
Copy, move, create_directory, and delete tools now defer all
project/filesystem operations until after the user authorizes the
action. Previously, some tools began resolving project paths or
traversing directories before authorization.
## streaming_edit_file permissions
`streaming_edit_file` now shares `edit_file`'s tool name for permission
checks, ensuring consistent permission rules between the two edit tool
variants. The duplicated authorization logic is replaced by a shared
`authorize_file_edit` function.
## Copy/move pattern extraction
Copy and move tools now include both source and destination paths in
their permission context (`input_value`). The always-allow pattern is
extracted from the common parent directory of both paths, ensuring the
pattern covers future checks against both.
## Save tool improvements
- Authorization title now shows only the paths that need confirmation,
not all paths
- Title is annotated with "(local settings)" or "(settings)" for
sensitive paths
Release Notes:
- File and directory tool operations now require confirmation before
modifying sensitive settings paths.
Builds on top of #48620 to add explicit test coverage for the exact
bypass scenarios reported by users:
- `rm -rf /etc/../` — path traversal via single parent dir that
normalizes to `/`
- `rm -rf --no-preserve-root /` — long flag without `=value` that could
bypass the old regex
- `rm --no-preserve-root -rf /` — long flag positioned before short
flags
- `rm / -rf --no-preserve-root` — trailing long flag without `=value`
after the path operand
- `sudo rm -rf /`, `sudo rm -rf /*`, `sudo rm -rf --no-preserve-root /`
— sudo-prefixed variants
All of these cases are already correctly blocked by the hardened regex
patterns and path normalization logic added in #48620. These tests
confirm that the reported bypasses are addressed and guard against
regressions.
Release Notes:
- N/A
This PR improves the shell command parser to correctly handle I/O
redirects, here-documents, and compound command constructs. Previously,
commands hidden inside redirect targets, here-document bodies, or
function definition redirects could go undetected by the permission
system.
## Changes
- **Redirect handling**: Capture I/O redirects on simple commands,
compound commands (`if`/`while`/`for`/`case`/subshells/brace groups),
and function definitions
- **Nested command extraction**: Extract commands from redirect file
targets (e.g. `> $(dangerous_cmd)`) and here-document bodies
- **Bare redirect rejection**: Return `None` for bare redirects with no
command name (e.g. `> /etc/passwd`), which forces confirmation
- **Compound command redirects**: Apply redirects on compound commands
to their inner body commands
- **Fail-closed error handling**: `extract_commands_from_word` and
`normalize_word_piece_into` now return `None` on parse failures instead
of silently succeeding
- **Test coverage**: Extensive tests for quoted redirect targets,
no-space redirects, clobber operators, fd-to-fd redirects, pipe+redirect
combinations, function definition redirects, and more
Release Notes:
- Improved shell command parsing to correctly detect commands hidden in
I/O redirects, here-documents, and compound command constructs.
MCP tool names can contain colons (e.g. `mcp:server:tool`), which broke
the `splitn(3, ':')` parsing of always-allow/always-deny pattern option
IDs. This switches to newline (`\n`) as the delimiter between tool name
and pattern, since newlines cannot appear in either component.
## Changes
- **Option ID format**: Changed from
`always_allow_pattern:{tool}:{pattern}` to
`always_allow_pattern:{tool}\n{pattern}`
- **Response parsing**: Replaced `splitn(3, ':')` with `strip_prefix` +
`split_once('\n')`
- **Error logging**: Added `log::error!` when pattern parsing fails
(previously silent)
- **Tests**: Updated test assertions in `agent` and `agent_ui` crates
No release notes because granular tool permissions are still
feature-flagged.
Release Notes:
- N/A
This PR hardens the terminal tool's hardcoded security rules for
destructive commands like `rm -rf /`, and adds path normalization to
prevent traversal-based bypasses.
## Path normalization
Adds `normalize_path` which resolves `..`, `.`, and redundant path
separators, and `decide_permission_for_path` which checks permissions
against both raw and normalized paths (taking the most restrictive
result). This prevents attacks like `rm -rf /tmp/../../` which
previously bypassed the `rm -rf /` rule.
## rm command expansion
Adds `expand_rm_to_single_path_commands` which splits multi-argument rm
commands into individual single-path commands for checking. This catches
cases like `rm -rf /tmp /` where the dangerous path is the second
argument.
## Regex hardening
- **FLAGS**: Now accepts digits, underscores, and uppercase in long
flags (e.g. `--no-preserve-root`)
- **`--flag=value`**: Correctly matched as a single flag token
- **Trailing flags**: Handles GNU rm's acceptance of flags after path
operands (e.g. `rm / -rf`)
- **`--` marker**: Detects end-of-options bypass attempts (e.g. `rm -rf
-- /`)
- **Whitespace**: Handles tabs and other whitespace, not just spaces
## `$HOME`/`${HOME}` handling
Normalizes the suffix after `$HOME`/`${HOME}` variable references so
that traversal attacks like `rm -rf $HOME/./` or `rm -rf ${HOME}/foo/..`
are correctly detected.
Release Notes:
- Strengthened terminal security rules to detect path traversal attacks
in destructive commands like `rm -rf`.
The two `unbounded_send` calls in `ToolCallEventStream`'s authorize
methods were using `.ok()` to silently discard send failures. This meant
that if the authorization channel was closed, the tool call would hang
indefinitely waiting for a response that would never come.
## Changes
- Both `authorize_third_party_tool` and `authorize` methods now use `if
let Err(error)` to detect send failures
- On failure, logs the error with `log::error!` and returns
`Task::ready(Err(...))` so callers get immediate, meaningful feedback
Release Notes:
- Tool authorization failures are now logged and reported instead of
being silently ignored.
This PR updates the model selector to highlight the latest models that
are available through the Zed provider:
<img width="388" height="477" alt="Screenshot 2026-02-06 at 1 46 41 PM"
src="https://github.com/user-attachments/assets/70760399-ecf6-46e3-80a7-cb998216c192"
/>
Closes CLO-205.
Release Notes:
- Added a "Latest" indicator to highlight the latest models available
through the Zed provider.
In `streaming_edit_file_tool.rs`, edits are sorted in reverse order and
applied sequentially. If the LLM produces overlapping edit ranges, the
first applied edit shifts the buffer, and the second edit's range
targets stale offsets, leading to incorrect results.
This adds a `windows(2)` check on the sorted (descending by start) edits
that verifies each earlier-in-file range's end does not exceed the next
later-in-file range's start. The validation is done before entering the
buffer update closure so the error can propagate cleanly via
`anyhow::bail!`.
Release Notes:
- Fixed bug where streaming edits could apply edits incorrectly if the
model requested overlapping edit regions.
This PR removes the `fn name()` default method from the `AgentTool`
trait (which just returned `Self::NAME`) and replaces all call sites
with direct use of the `NAME` associated constant. This lets us use it
as a single source of truth in macros that want to access it at compile
time.
This PR also replaces hardcoded tool name string literals throughout the
codebase with the corresponding `NAME` constants, so tool name
references stay in sync if a tool is renamed.
Intentionally not changed:
- **Display strings** like `"Thinking"` and `"Subagent"` (user-facing UI
labels)
- **Serde attributes** like `#[serde(rename = "thinking")]` (wire
format)
- **The test assertion** `assert_eq!(SubagentTool::NAME, "subagent")`
(replacing the literal would make it tautological)
- **MCP server names** like `"mcp:srv:terminal"` (not tool identifiers)
Release Notes:
- N/A
## Problem
Zed's terminal permission system validates commands using regex patterns
against string representations of parsed commands. The
`SimpleCommand::to_string()` method in brush-parser preserves the raw
lexical form including shell quotes, causing pattern matching to fail on
obfuscated commands.
For example, all of these are semantically equivalent to `rm -rf /` in
POSIX shells, but produced different strings from `to_string()` that
bypassed the hardcoded deny pattern `rm\s+(-[rf]+\s+)*/\s*$`:
| Input | `extract_commands()` returned | Matched deny pattern? |
|---|---|---|
| `rm -rf /` | `"rm -rf /"` | ✅ Yes |
| `rm -rf '/'` | `"rm -rf '/'"` | ❌ No |
| `'rm' -rf /` | `"'rm' -rf /"` | ❌ No |
| `r'm' -rf /` | `"r'm' -rf /"` | ❌ No |
| `rm -r'f' /` | `"rm -r'f' /"` | ❌ No |
| `rm -rf \/` | `"rm -rf \\/"` | ❌ No |
Both hardcoded deny patterns (Phase 2, which operates on extracted
sub-commands) and user-configured `always_deny` patterns were affected.
## Fix
Replace the `simple_command.to_string()` call in
`extract_commands_from_simple_command` with manual construction that:
1. Iterates the command name (`word_or_name`) and word arguments from
the suffix
2. Normalizes each word by parsing it into `WordPiece`s via
`brush_parser::word::parse`
3. Reconstructs the semantic (unquoted) value from each piece:
- `Text` — used as-is
- `SingleQuotedText` — used as-is (brush-parser already strips the
wrapping quotes)
- `EscapeSequence` — leading `\` stripped to produce the unescaped
character
- `AnsiCQuotedText` — used as-is (brush-parser already evaluates
`$'...'`)
- `DoubleQuotedSequence` / `GettextDoubleQuotedSequence` — inner pieces
recursively normalized
- `TildePrefix` — preserved as `~` + suffix
- `ParameterExpansion` / `CommandSubstitution` /
`BackquotedCommandSubstitution` / `ArithmeticExpression` — original
source text preserved so patterns like `\$HOME` and `\${HOME}` continue
to match
4. Joins normalized words with spaces
Falls back to the raw `word.value` if word parsing fails.
## Cross-shell safety
The normalization operates on POSIX-parsed ASTs (brush-parser uses POSIX
grammar), so it applies POSIX quoting rules. For non-POSIX shells
(Nushell, PowerShell, Xonsh, Elvish, etc.) where quoting semantics
differ, any mismatch results in false positives (overly cautious
denials), never false negatives. This is the correct error direction for
a security feature. When brush-parser fails to parse a non-POSIX
command, `extract_commands` returns `None` and the existing fallback
(raw-string matching with `allow_enabled=false`) handles it.
(No release notes because granular tool permissions are still
feautre-flagged.)
Release Notes:
- N/A
Expands the hardcoded security rules that block dangerous `rm` commands
in the agent terminal tool.
### New blocked patterns
- `rm -rf $HOME` / `rm -rf $HOME/` / `rm -rf ${HOME}` / `rm -rf
${HOME}/`
- `rm -rf .` / `rm -rf ./`
- `rm -rf ..` / `rm -rf ../`
- `rm -rf ~/` (previously only `rm -rf ~` was blocked)
### Flag handling improvements
- Simplified the flag character class from `[rRfF]` to `[rf]` since the
regex is already compiled with case-insensitive mode — less confusing,
same behavior.
- Added tests verifying that reversed flags (`-fr`), uppercase (`RM
-RF`), split flags (`-r -f`), and chained commands all get caught.
### Safe commands still allowed
Paths like `rm -rf ./build`, `rm -rf ~/Documents`, `rm -rf
$HOME/Documents`, `rm -rf ../some_dir`, and `rm -rf .hidden_dir` are
**not** blocked.
Release Notes:
- Auto-block a wider range of agent terminal commands, e.g. `rm -rf
$HOME` in addition to `rm -rf ~`
`brush-parser` handles `;` (sequential execution) and `|` (piping) which
all these shells use, so we can safely parse their commands for
`always_allow` pattern matching.
(No release notes because granular tool permissions haven't been
released yet.)
Release Notes:
- N/A
This change introduces hardcoded security rules for the terminal tool
that cannot be bypassed by any setting, including
`always_allow_tool_actions`.
## Currently Blocked Commands
- `rm -rf /` - Recursive deletion of root filesystem
- `rm -rf ~` - Recursive deletion of home directory
These rules are checked **before** the `always_allow_tool_actions`
global flag, ensuring they can never be bypassed. The rules also check
parsed sub-commands, so `ls && rm -rf /` is also blocked.
Release Notes:
- Certain known-bad tool uses are now automatically blocked, such as the
terminal tool attempting to run `rm -rf /` or `rm -rf ~`
Follow up to https://github.com/zed-industries/zed/pull/47637
- Removes the requirement for the terminal to be focused to use the
`cmd->` keybinding. This way, we match the behavior of buffer selections
and you can always add what's selected in the terminal inside the agent
panel
- Add number of lines selected in the mention button as well
- Make the "Selection" menu item inside the "Add Context" menu also
observe terminal selections
<img width="420" height="254" alt="Screenshot 2026-01-29 at 1 36@2x"
src="https://github.com/user-attachments/assets/25d2eb00-096f-44d9-8882-273932ca43e4"
/>
Release Notes:
- Agent: Add number of liners selected in the terminal context mention
Summary
This PR adds the ability to quote terminal selections into Agent
threads, similar to how editor selections can be quoted. Users can now
select text in the terminal and add it as context to their agent
conversation.
### Features
- **Context menu**: Added "Add to Agent Thread" option to the terminal's
right-click menu (only shows when text is selected)
- **Keyboard shortcut**: The existing `cmd->` / `ctrl->` shortcut now
works in the terminal
- **Collapsed display**: Terminal output appears as a collapsed
"Terminal" crease in the chat, just like code references
- **Works with both thread types**: Supports both ACP-style threads
(Claude Code) and text threads
### Implementation
- Extended `quote_selection` handler to check for terminal panel focus
after checking for editor selections
- Terminal content is formatted as ` ```terminal` code blocks via new
`insert_terminal_crease` method
- Refactored crease insertion into `insert_crease_impl` helper to
support both code snippets (with `TextSnippet` icon) and terminal output
(with `Terminal` icon)
- Added automatic detection and folding of ` ```terminal` blocks in
`set_message` so terminal content stays collapsed in sent message
history
- Terminal creases use a trailing space instead of newline so cursor
behavior matches user expectations
### Demo
1. Select text in terminal
2. Right-click → "Add to Agent Thread" (or press `cmd->`)
3. Terminal content appears as collapsed "Terminal" block in chat
4. Send message - AI receives full terminal output, but chat history
shows it collapsed
### General note
I'm new to open source and the codebase in general so let me know if
anything should be different!
I tried to stay in line with other patterns I saw.
I didn't see a way to setup an end to end test with a real terminal so I
just added a unit test for the adding of the text to the chat, if it
exists and I missed it then I think the test coverage could be improved
with a test that uses a real terminal + running the command
<img width="431" height="148" alt="image"
src="https://github.com/user-attachments/assets/854732f9-2a7f-4f31-867e-d54af068c97c"
/>
Release Notes:
- agent: Added the ability to send selections from terminals into the
Agent thread
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
## Summary
This PR extends the `always_allow` tool permission patterns to work with
Nushell, Elvish, and Rc shells. Previously, these shells were
incorrectly excluded because they don't use `&&`/`||` operators for
command chaining. However, brush-parser can safely parse their command
syntax since they all use `;` for sequential execution.
## Changes
- Add `ShellKind::Nushell`, `ShellKind::Elvish`, and `ShellKind::Rc` to
`supports_posix_chaining()`
- Split `ShellKind::Unknown` into `ShellKind::UnknownWindows` and
`ShellKind::UnknownUnix` to preserve platform-specific fallback behavior
while still denying `always_allow` patterns for unrecognized shells
- Add comprehensive tests for the new shell support
- Clarify documentation about shell compatibility
## Shell Notes
- **Nushell**: Uses `;` for sequential execution. The `and`/`or`
keywords are boolean operators on values, not command chaining.
- **Elvish**: Uses `;` to separate pipelines. Does not have `&&` or `||`
operators. Its `and`/`or` are special commands operating on values.
- **Rc (Plan 9)**: Uses `;` for sequential execution and `|` for piping.
Does not have `&&`/`||` operators.
## Security
Unknown shells still return `false` from `supports_posix_chaining()`, so
`always_allow` patterns are denied for safety when we can't verify the
shell's syntax.
(No release notes because granular tool permissions are still
feature-flagged.)
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
<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
This PR reworks the `Plan` type, now that we don't need to be concerned
about the legacy plan versions.
We've also made the deserialization layer more robust, which should make
it easier to add new plan variants in the future without needing to go
through this same song and dance.
Release Notes:
- N/A
The rate limiter's semaphore guard was being held for the entire
duration of a turn, including during tool execution. This caused
deadlocks when subagents tried to acquire permits while parent requests
were waiting for them to complete.
## The Problem
In `run_turn_internal`, the stream (which contains the `RateLimitGuard`
holding the semaphore permit) was kept alive throughout the entire loop
iteration - including during **tool execution**:
1. Parent request acquires permit
2. Parent starts streaming, consumes response
3. Parent starts executing tools (subagents)
4. **Stream/guard still held** while tools execute
5. Subagents try to acquire permits → blocked because parent still holds
permit
6. Deadlock if all permits are held by parents waiting for subagent
children
## The Fix
Two changes were made:
1. **Drop the stream early**: Added an explicit `drop(events)` after the
stream is fully consumed but before tool execution begins. This releases
the rate limit permit so subagents can acquire it.
2. **Removed the `bypass_rate_limit` workaround**: Since the root cause
is now fixed, the bypass mechanism is no longer needed.
Note: no release notes because subagents are still feature-flagged, and
this rate limiting change isn't actually observable without them.
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/47330
This PR moves the queue logic out of the native Thread into the shared
UI layer (thread view) to enable it for external agents. There's a key
difference in behavior, though, between native and external agents:
queued messages in the former will be sent in the next turn boundary,
given we can easily tell this, whereas for the latter, queued messages
will be sent by the end of the generation. We'd need an ACP-level change
to provide exactly the same UX between both types of agents, and I
figured that's better to have _some_ version of the feature for external
agents as opposed to not having it all due to this difference.
Release Notes:
- Agent: Made the message queue feature available for external agents as
well.
Many editors such as vim and emacs support "modelines", a comment at the
beginning of the file that allows the file type to be explicitly
specified along with per-file specific settings
- The amount of configurations, style and settings mapping cannot be
handled in one go, so this opens up a lot of potential improvements.
- I left out the possiblity to have "zed" specific modelines for now,
but this could be potentially interesting.
- Mapping the mode or filetype to zed language names isn't obvious
either. We may want to make it configurable.
This is my first contribution to zed, be kind. I struggled a bit to find
the right place to add those settings. I use a similar approach as done
with editorconfig (merge_with_editorconfig). There might be better ways.
Closes#4762
Release Notes:
- Add basic emacs/vim modeline support.
Supersedes #41899, changes:
- limit reading to the first and last 1kb
- add documentation
- more variables handled
- add Arc around ModelineSettings to avoid extra cloning
- changed the way mode -> language mapping is done, thanks to
`modeline_aliases` language config
- drop vim ex: support
- made "Local Variables:" handling a separate commit, so we can drop it
easily
- various code style improvements
---------
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR adds a thinking toggle for controlling whether to use thinking
for a model in the Zed provider:
<img width="645" height="142" alt="Screenshot 2026-01-22 at 12 34 01 PM"
src="https://github.com/user-attachments/assets/9aa543fe-e708-4840-8b38-1a6fbcb78388"
/>
Previously we would create separate "Thinking" variants of the models
that supported thinking in the model selector.
This only applies to Anthropic models in the Zed provider, currently.
This is gated behind the `cloud-thinking-toggle` feature flag.
Release Notes:
- N/A
---------
Co-authored-by: Neel <neel@zed.dev>
## Problem
When subagents use the `edit_file` tool, it creates an `EditAgent` that
makes its own model request to get the edit instructions. These "nested"
requests compete with the parent subagent conversation requests for rate
limiter permits.
The rate limiter uses a semaphore with a limit of 4 concurrent requests
per model instance. When multiple subagents run in parallel:
1. 3 subagents each hold 1 permit for their ongoing conversation streams
(3 permits used)
2. When all 3 try to use `edit_file` simultaneously, their edit agents
need permits too
3. Only 1 edit agent can get the 4th permit; the other 2 block waiting
4. The blocked edit agents can't complete, so their parent subagent
conversations can't complete
5. The parent conversations hold their permits, so the blocked edit
agents stay blocked
6. **Deadlock**
## Solution
Added a `bypass_rate_limit` field to `LanguageModelRequest`. When set to
`true`, the request skips the rate limiter semaphore entirely. The
`EditAgent` sets this flag because its requests are already "part of" a
rate-limited parent request.
(No release notes because subagents are still feature-flagged.)
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Follow-Up-For: #47243
Previously, we would detach tasks spawned to watch config files.
However, the task blocked on receiving a file event before checking if
the receiver for the updates channel was dropped, causing the task to
never exit. The fix here was to return the task explicitly, so that it
can be dropped instead of calling `.detach()` on it. There is definitely
a way to `select!` between the receiver being dropped and the next file
system event, but I couldn't figure it out in a reasonable amount of
time and decided it wasn't worth it.
Release Notes:
- Fixed an issue where a few file descriptors would be leaked each time
a project was closed
This PR adds the ability to edit a queued message, which you can now do
by hitting `cmd-e` from the message editor, which will focus the first
queued message. To pull that off, I'm also making the queued messages
render as an editor, the same way we do with regular user messages. That
way, we ensure less layout shift when focusing in and out of the queued
message for editing and gain the ability to render context
buttons/creases the same way we do in the main message editor.
https://github.com/user-attachments/assets/fb68fd48-c0cd-491f-a7d9-5065a9151b0b
Note that in the video, I show the state in which you're still editing
in the moment in which the queued message would be sent. If that
happens, your queued message won't be sent even if you unfocus the
queued message editor. In this case, you need to explicitly hit "Send
Now".
Release Notes:
- Agent: Added the ability to edit queued messages.
Closes#31351
# Diagnostics Mention in New Threads
## Overview
Adds the `@diagnostics` mention to the new Agent Panel threads so users
can inject current LSP diagnostics (errors by default) without switching
to a text thread. The diagnostics mention is fully integrated into ACP
mention parsing, the context picker, and the message-editor pipeline so
it round-trips cleanly and shows up in the standard `@` menu.
## Context
- **Request:** bring `/diagnostics` parity to the “New Thread” assistant
experience.
- **Scope:** diagnostics only; `/terminal` mention would be implemented
in a separate PR.
- **Docs:** updated Agent Panel docs + changelog.
## Implementation Details
1. **Mention plumbing**
- Added `MentionUri::Diagnostics` to `acp_thread`, including parsing
(`zed:///agent/diagnostics?include_warnings=true`) and icon/name
metadata.
- Tests ensure diagnostics links round-trip via Markdown mention
serialization.
2. **Context picker / completion**
- New `ContextPickerMode::Diagnostics` exposes an `@diagnostics` entry
in the mention menu.
- Completions turn `@diagnostics` into a fully fledged mention, reusing
the existing confirmation pipeline.
3. **Message editor + thread serialization**
- Resolving the mention calls the existing diagnostics collector from
`assistant_slash_commands`, embedding the tool output inline with other
context blocks (`<diagnostics>…</diagnostics>`).
- Thread-link handling ignores diagnostics backlinks so clicking them
doesn’t try to reopen nonexistent resources.
# How it looks
<img width="800" height="480" alt="image"
src="https://cf5gpe8lxo.ufs.sh/f/EmJ5Xl877qJO1mzC9Zrn8AmJZHeShC4RoUwvTMlF2tfPzj06"
/>
Release Notes:
- Allow mentioning diagnostics in the agent panel via `@diagnostics`
---------
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
