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>
This makes sure all of the new granular permission logic and ui only
applies to the zed agent and doesn't affect the UI of external agents.
Release Notes:
- N/A
Previously, `always_confirm` patterns would force confirmation even when
`always_allow_tool_actions` was set to true. This was counterintuitive
since the global setting should provide a way to skip all confirmations.
The new precedence order is:
1. **`always_deny`** - still blocks for security
2. **`always_allow_tool_actions`** - when true, allows all non-denied
actions
3. **`always_confirm`** - prompts if `always_allow_tool_actions` is
false
4. **`always_allow`** - allows without prompting
5. **`default_mode`** - fallback behavior
This means setting `always_allow_tool_actions=true` will now skip
confirmation prompts from `always_confirm` patterns and override
`default_mode: Deny` settings, while still respecting `always_deny`
patterns for security.
(No release notes because granular tool permissions are still
feature-flagged.)
Release Notes:
- N/A
This feature cost $12
Release Notes:
- Changed the behavior of queued messages to gracefully wait for the
current activity to complete.
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Closes #ISSUE
Reproduction steps:
- Zed main branch
- Use Ollama (likely provider agnostic) in the agent panel with the
following prompt: "Explore the codebase with subagents"
- Panic
```
thread 'main' (36268) panicked at C:\Users\username\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\futures-util-0.3.31\src\stream\unfold.rs:108:21:
Unfold must not be polled after it returned `Poll::Ready(None)`
```
Following the stack trace we get to `Thread::run_turn_internal`. I
believe the panic happens in the following code which was introduced in
#46802
```rust
// Collect all immediately available events to process as a batch
let mut batch = vec![first_event];
while let Some(event) = events.next().now_or_never().flatten() {
batch.push(event);
}
```
Both `Option`s get flattened, however the inner `Option` represents the
end of the stream, after which polling the stream using `.next()` will
result in a panic.
We could fix the logic in this particular spot, but I believe the
simpler solution is to `.fuse()` the stream, which stops the stream from
panic'ing even after it has ended. This also prevents misuse in the
future.
The panic was introduces on main and did not land on a release yet, so
no release notes.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This PR removes the code for the legacy plans.
No more users will be on this plan as of January 17th, so it's fine to
land these changes now (as they won't be released until the 21st).
Closes CLO-76.
Release Notes:
- N/A
Release Notes:
- Opening bundled files, keymap, and local release notes now opens in
remote windows instead of opening a new local zed window
- Opening the settings files, keymap files, task files, debug files and
logs will now open within wsl windows instead of opening a new local zed
window
This feature cost $15.
Up -> Tokens we're sending to the model
Down -> Tokens we've received from the model.
<img width="377" height="69" alt="Screenshot 2026-01-14 at 12 31 01 PM"
src="https://github.com/user-attachments/assets/fc15824f-de5d-466b-8cc1-329f3c1940bb"
/>
Release Notes:
- Changed the display of tokens for OpenAI models to reflect the
input/output limits.
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Closes https://github.com/zed-industries/zed/issues/34402
Release Notes:
- MCP servers can now be run on the remote server when using remote
development. This can be enabled by setting the `"remote": true`
property in the settings entry for the MCP server.
---------
Co-authored-by: localcc <kate@zed.dev>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
## Summary
This PR adds the UI for displaying subagent tool calls:
### Thread view changes
- Add `expanded_subagents` state HashMap for tracking expanded cards
- Implement `render_subagent_tool_call()` for collapsed card with label
and chevron
- Add subagent detection via `is_subagent()` and `tool_name` field
- Handle `SubagentThread` content type in tool call rendering
- Add expand/collapse toggle button for subagent cards
- Style collapsed cards similar to terminal tool calls
- Support inline image rendering in content blocks
### Agent panel changes
- Add `open_external_thread_with_server()` for testing with stubbed
servers
### Test support
- Add `acp_thread/test-support` feature to agent_ui
- Add base64 dev dependency for image tests
Release Notes:
- N/A
---------
Co-authored-by: Amp <amp@ampcode.com>
## Problem
Profiling showed that during agent streaming, `thread.rs:1393:23` was
appearing constantly as a hotspot. The issue was that every single token
from the model triggered:
1. `this.update(cx, ...)`
2. `handle_text_event()` (or thinking/redacted_thinking)
3. `cx.notify()`
4. UI re-render
This created significant foreground thread pressure, contributing to
~500ms delays visible in the profiler.
## Solution
Batch all immediately-available events using `now_or_never()` and
process them in a single `update()` call with one `notify()` at the end.
This approach is deterministic - it processes exactly what's available
right now, adapting naturally to network speed:
- When tokens arrive slowly, you get one at a time
- When they arrive in bursts, they batch automatically
## Changes
- Remove `cx.notify()` from `handle_text_event`,
`handle_thinking_event`, and `handle_redacted_thinking_event`
- Batch events in the streaming loop using `now_or_never()`
- Call `cx.notify()` once per batch instead of per-event
- Keep `cx.notify()` in `handle_tool_use_event` for immediate tool
feedback
Release Notes:
- Improve streaming tool call performance by batching UI updates.
Closes#40322
When users run multi-line terminal commands, the confirmation dialog was
only showing the first line with '- N more lines' truncated. This meant
dangerous commands like 'rm -rf' or 'sudo' operations could be hidden
from view, creating a security risk.
Now terminal commands always display in full, with scroll support for
very long commands (20+ lines) to keep the confirmation buttons visible.
Other tools continue using truncation for better UI efficiency since
they don't pose the same security concerns.
Release Notes:
- Agent: Fixed terminal command truncation in the agent panel to better
expose long commands (e.g., potentially dangerous multi-line commands
are now fully visible before execution)
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: dino <dinojoaocosta@gmail.com>
Feature flagged for now as we test this out with actual agents to see if
we need to provide any more feedback to the RFD before committing to the
current setup.
Release Notes:
- N/A
This should move almost all access of the threadstore behind the trait,
which unlocks external agents supplying the list
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Add permission checking to the remaining 7 tools that require granular
permissions:
- `edit_file`: Checks path against permission rules
- `delete_path`: Checks path against permission rules
- `move_path`: Checks both source and destination paths
- `create_directory`: Checks path against permission rules
- `save_file`: Checks all paths, denies if any are blocked
- `fetch`: Checks URL against permission rules
- `web_search`: Checks query against permission rules
Each tool follows the pattern established in PR #46155 (terminal tool):
- `Allow` = proceed without prompting
- `Deny` = return error immediately
- `Confirm` = prompt user for confirmation
The deny > confirm > allow precedence is enforced by the
`decide_permission_from_settings()` function.
Release Notes:
- N/A
---------
Co-authored-by: Amp <amp@ampcode.com>
PR #46306 changed cancellation to wait for tools to complete before
returning. This was correct behavior - it allows tools like terminal to
capture their output on cancellation. The real issue was that many tools
didn't check for cancellation, so they would continue running until they
finished.
## The Problem
When the user pressed Escape to cancel during a tool operation, tools
would continue running because they never checked for the cancellation
signal. The thread correctly waited for tools to complete (so terminal
could capture output), but tools like edit_file, grep, fetch, etc. would
just keep going.
## The Fix
Add cancellation handling to all tools using the same pattern as
`terminal_tool`: use `select!` to race between the tool's main work and
`event_stream.cancelled_by_user()`. When cancelled, tools break out of
their loops or return early.
## All Tools Now Cancellation-Aware
| Tool | Change |
|------|--------|
| `edit_file_tool` | Checks cancellation in edit event processing loop |
| `terminal_tool` | Already handled cancellation |
| `grep_tool` | Checks cancellation in search result iteration loop |
| `fetch_tool` | Checks cancellation during HTTP fetch |
| `web_search_tool` | Checks cancellation during web search |
| `find_path_tool` | Checks cancellation during path search |
| `read_file_tool` | Checks cancellation during buffer open |
| `copy_path_tool` | Checks cancellation during file copy |
| `move_path_tool` | Checks cancellation during file move/rename |
| `delete_path_tool` | Checks cancellation during delete operation |
| `create_directory_tool` | Checks cancellation during directory
creation |
| `save_file_tool` | Checks cancellation during buffer open and save |
| `restore_file_from_disk_tool` | Checks cancellation during buffer open
and reload |
| `open_tool` | Checks cancellation during authorization |
| `diagnostics_tool` | Checks cancellation during buffer open |
| `ContextServerTool` (MCP) | Checks cancellation during external server
calls |
**Synchronous tools (no async work, return immediately):**
- `list_directory_tool` - Reads worktree snapshot synchronously
- `now_tool` - Returns current time immediately
- `thinking_tool` - Returns immediately
## MCP Tools Automatically Handled
MCP tools (user-defined tools via context servers) are now automatically
cancellation-aware without any user action. The `ContextServerTool`
wrapper races the external server request against
`event_stream.cancelled_by_user()`.
## Testing
- Added `CancellationAwareTool` test helper that mirrors the
cancellation pattern
- Updated `test_cancellation_aware_tool_responds_to_cancellation` to
properly await the cancel task and verify the tool detected cancellation
Release Notes:
- Fixed a regression where pressing Escape wouldn't immediately cancel
in-progress tool operations
## Motivation
This PR unifies the async execution infrastructure between GPUI and
other components that depend on the `scheduler` crate (such as our cloud
codebase). By having a scheduler that lives independently of GPUI, we
can enable deterministic testing across the entire stack - testing GPUI
applications alongside cloud services with a single, unified scheduler.
## Summary
This PR completes the integration of the `scheduler` crate into GPUI,
unifying async execution and enabling deterministic testing of GPUI
combined with other components that depend on the scheduler crate.
## Key Changes
### Scheduler Integration (Phases 1-5, previously completed)
- `TestDispatcher` now delegates to `TestScheduler` for timing, clock,
RNG, and task scheduling
- `PlatformScheduler` implements the `Scheduler` trait for production
use
- GPUI executors wrap scheduler executors, selecting `TestScheduler` or
`PlatformScheduler` based on environment
- Unified blocking logic via `Scheduler::block()`
### Dead Code Cleanup
- Deleted orphaned `crates/gpui/src/platform/platform_scheduler.rs`
(older incompatible version)
## Intentional Removals
### `spawn_labeled` and `deprioritize` removed
The `TaskLabel` system (`spawn_labeled`, `deprioritize`) was removed
during this integration. It was only used in a few places for test
ordering control.
cc @maxbrunsfeld @as-cii - The new priority-weighted scheduling in
`TestScheduler` provides similar functionality through
`Priority::High/Medium/Low`. If `deprioritize` is important for specific
test scenarios, we could add it back to the scheduler crate. Let me know
if this is blocking anything.
### `start_waiting` / `finish_waiting` debug methods removed
Replaced by `TracingWaker` in `TestScheduler` - run tests with
`PENDING_TRACES=1` to see backtraces of pending futures when parking is
forbidden.
### Realtime Priority removed
The realtime priority feature was unused in the codebase. I'd prefer to
reintroduce it when we have an actual use case, as the implementation
(bounded channel with capacity 1) could potentially block the main
thread. Having a real use case will help us validate the design.
## Testing
- All GPUI tests pass
- All scheduler tests pass
- Clippy clean
## Architecture
```
┌─────────────────────────────────────────────────────────────┐
│ GPUI │
│ ┌──────────────────────┐ ┌────────────────────────────┐ │
│ │ gpui::Background- │ │ gpui::ForegroundExecutor │ │
│ │ Executor │ │ - wraps scheduler:: │ │
│ │ - scheduler: Arc< │ │ ForegroundExecutor │ │
│ │ dyn Scheduler> │ └────────────┬───────────────┘ │
│ └──────────┬───────────┘ │ │
│ │ │ │
│ └──────────┬──────────────────┘ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ Arc<dyn Scheduler> │ │
│ └───────────┬───────────┘ │
│ ┌──────────────┴──────────────┐ │
│ ▼ ▼ │
│ ┌──────────────────┐ ┌────────────────────┐ │
│ │ PlatformScheduler│ │ TestScheduler │ │
│ │ (production) │ │ (deterministic) │ │
│ └──────────────────┘ └────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Yara <git@yara.blue>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This PR adds the foundation for the subagents feature:
- Add `SubagentsFeatureFlag` with staff-disabled default
- Create `SubagentTool` struct with input schema for
task/summary/context-low prompts
- Register `SubagentTool` conditionally when feature flag is enabled
- Tool returns stub message 'not yet implemented' for now
Release Notes:
- N/A
---------
Co-authored-by: Amp <amp@ampcode.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Yara <yara@zed.dev>
This builds on https://github.com/zed-industries/zed/pull/46112 (which
should be merged first) and adds the permission evaluation logic and
integrates it with the terminal tool as part of the tool permissions
feature. This is a separate PR for [stacked
diffs](https://newsletter.pragmaticengineer.com/p/stacked-diffs) to make
review easier.
## Changes
- **Add `tool_permissions.rs`** with `decide_permission()` function that
implements:
- `deny > confirm > allow` precedence hierarchy (security-critical)
- Case-sensitive and case-insensitive regex matching
- Integration with existing `always_allow_tool_actions` setting
- Comprehensive unit tests (15 tests)
- **Integrate with terminal tool**:
- Commands matching deny rules are blocked immediately with an error
- Commands matching allow rules proceed without confirmation dialog
- Commands requiring confirmation show the dialog as before
- Added integration tests for deny and allow rule scenarios
Co-Authored-By: Claude Opus 4.5
Release Notes:
- N/A
---------
Co-authored-by: Amp <amp@ampcode.com>
I really enjoyed this feature in Claude Code. Helps me get a sense of
how effortful something is.
Release Notes:
- Added a "show_turn_stats" setting, default to false, that shows the
timer and the number of tokens down.
<img width="707" height="778" alt="Screenshot 2026-01-07 at 8 34 00 PM"
src="https://github.com/user-attachments/assets/59842820-079b-4d47-9bdd-f77300f8a60e"
/>
When the user presses Esc or the Stop button to interrupt a thread,
terminal tools now capture their output and include it in the tool
result. This allows the model to see what was happening in the terminal
when the user interrupted, so it can answer questions about the output.
## Changes
- `Thread::cancel()` now returns a `Task` that waits for tools to
respond to cancellation before flushing pending messages
- Terminal tool uses `select!` to detect cancellation signal and
immediately kills the terminal and captures output
- `run_turn_internal` uses `select!` to break out of event loop on
cancel
- Added test for terminal tool cancellation output capture
This is a follow-up to #46218 which added similar functionality for the
"Stop" button on individual terminal tool cards.
Release Notes:
- Interrupting the agent now captures terminal output so the model can
see what was running when you stopped it
Previously, if you stopped the terminal prematurely, the agent would
assume the terminal process had timed out. Now it knows what happened
and can see the output:
<img width="718" height="885" alt="Screenshot 2026-01-07 at 12 40 23 AM"
src="https://github.com/user-attachments/assets/a5ea14b2-249c-4ada-9f20-d6b608f829e5"
/>
Release Notes:
- Stopping the terminal tool now allows the agent to see its output up
to that point.
Now when the agent reads images (which the tool now explicitly
advertises to agents that it is capable of; previously the tool said it
could only read text even though it can actually read images), we see
them in the thread, and also they are auto-expanded by default so you
can see them when scrolling through:
<img width="725" height="1019" alt="Screenshot 2026-01-06 at 2 57 11 PM"
src="https://github.com/user-attachments/assets/5c908bad-48f2-46c2-afaa-7f189a178e05"
/>
This also adds a visual regression test that verifies images render
correctly in the agent thread view.
Unlike our previous visual tests, this one only renders the agent panel,
not the entire Zed window.
The "screenshot" it generates (rendered to a Metal texture) is from
completely mocked/simulated data structures, and looks like this:
<img width="546" height="984" alt="Screenshot 2026-01-06 at 2 54 41 PM"
src="https://github.com/user-attachments/assets/89a0921f-59e9-4dfe-94b2-4c3b625a851b"
/>
## Changes
- **New visual test**: `agent_thread_with_image` renders an
`AcpThreadView` containing a tool call with image content (the Zed app
icon)
- **Test infrastructure**: Added `StubAgentServer` helper and required
feature flags for visual testing
- **Test-support API**: Added `expand_tool_call()` method to
`AcpThreadView` to allow expanding tool calls for visual testing
- **Baseline screenshot**: Included baseline image showing the Zed logo
rendered in a tool call output
## How to run
```bash
# Run the visual tests
cargo run -p zed --bin visual_test_runner --features visual-tests
# Update baselines if UI intentionally changed
UPDATE_BASELINE=1 cargo run -p zed --bin visual_test_runner --features visual-tests
```
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Amp <amp@ampcode.com>
- **search: Make search cancellation more responsive (again)**
- **Fix project benchmarks build**
- **Less scoping and lifetimes for workers**
Related to #45300
Release Notes:
- Project search will consume less resources immediately after
cancellation.
---------
Co-authored-by: Max Brunsfeld <max@zed.dev>
This PR adds the ability to favorite models for external agents—writing
to the settings in the `agent_servers` key—as well as a handful of other
improvements:
- Make the cycling keybinding `alt-enter` work for the inline assistant
as well as previous user messages
- Better organized the keybinding files removing some outdated
agent-related keybinding definitions
- Renamed the inline assistant key context to "InlineAssistant" as
"PromptEditor" is old and confusing
- Made the keybindings to rate an inline assistant response visible in
the thumbs up/down button's tooltip
- Created a unified component for the model selector tooltip given we
had 3 different places creating the same element
- Make the "Cycle Favorited Models" row in the tooltip visible only if
there is more than one favorite models
Release Notes:
- agent: External agents also now support the favoriting model feature,
which comes with a handy keybinding to cycle through the favorite list.
<img width="500" height="830" alt="Screenshot 2025-12-17 at 10 10@2x"
src="https://github.com/user-attachments/assets/057fe20b-50b3-44de-96b8-8a6e3d9239df"
/>
Release Notes:
- agent: Added the ability to regenerate the auto-summarized title of
threads to the "Regenerate Thread Title" button available the ellipsis
menu of the agent panel.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
## Summary
This PR adds support for the MCP (Model Context Protocol)
`notifications/tools/list_changed` notification, enabling dynamic tool
discovery when MCP servers add, remove, or modify their available tools
at runtime.
## Release Notes:
- Improved: MCP tools are now automatically reloaded when a context
server sends a `tools/list_changed` notification, eliminating the need
to restart the server to discover new tools.
## Changes
- Register a notification handler for `notifications/tools/list_changed`
in `ContextServerRegistry`
- Automatically reload tools when the notification is received
- Handler is registered both on initial server startup and when a server
transitions to `Running` status
## Motivation
The MCP specification includes a `notifications/tools/list_changed`
notification to inform clients when the list of available tools has
changed. Previously, Zed's agent would only load tools once when a
context server started. This meant that:
1. If an MCP server dynamically registered new tools after
initialization, they would not be available to the agent
2. The only way to refresh tools was to restart the entire context
server
3. Tools that were removed or modified would remain in the old state
until restart
## Implementation Details
The implementation follows these steps:
1. When a context server transitions to `Running` status, register a
notification handler for `notifications/tools/list_changed`
2. The handler captures a weak reference to the `ContextServerRegistry`
entity
3. When the notification is received, spawn a task that calls
`reload_tools_for_server` with the server ID
4. The existing `reload_tools_for_server` method handles fetching the
updated tool list and notifying observers
This approach is minimal and reuses existing tool-loading
infrastructure.
## Testing
- [x] Code compiles with `./script/clippy -p agent`
- The notification handler infrastructure already exists and is tested
in the codebase
- The `reload_tools_for_server` method is already tested and working
## Benefits
- Improves developer experience by enabling hot-reloading of MCP tools
- Aligns with the MCP specification's capability negotiation system
- No breaking changes to existing functionality
- Enables more flexible and dynamic MCP server implementations
## Related Issues
This implements part of the MCP specification that was already defined
in the type system but not wired up to actually handle the
notifications.
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Closes#38533
<img width="807" height="425" alt="Screenshot 2025-12-16 at 2 32 21 PM"
src="https://github.com/user-attachments/assets/6ebb915c-91d3-4158-a2b9-9fe17d301dd6"
/>
Release Notes:
- Use up-to-date token counts from LLM responses when reporting tokens
used per thread
---------
Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>
This PR solves my main pain point with Zed agent: I have a long list of
available models from different providers, and I switch between a few of
them depending on the context and the project. In particular, I use the
same models from different providers depending on whether I'm working on
a personal project or at my day job. Since I only care about a few
models (none of which are in "recommended") that are scattered all over
the list, switching between them is bothersome, even using search.
This change adds a new option in `settings.json`
(`agent.favorite_models`) and the UI to manipulate it directly from the
list of available models. When any models are marked as favorites, they
appear in a dedicated section at the very top of the list. Each model
has a small icon button that appears on hover and allows to toggle
whether it's marked as favorite.
I implemented this on the UI level (i.e. there's no first-party
knowledge about favorite models in the agent itself; in theory it could
return favorite models as a group but it would make it harder to
implement bespoke UI for the favorite models section and it also
wouldn't work for text threads which don't use the ACP infrastructure).
The feature is only enabled for the native agent but disabled for
external agents because we can't easily map their model IDs to settings
and there could be weird collisions between them.
https://github.com/user-attachments/assets/cf23afe4-3883-45cb-9906-f55de3ea2a97
Closes https://github.com/zed-industries/zed/issues/31507
Release Notes:
- Added the ability to mark language models as favorites and pin them to
the top of the list. This feature is available in the native Zed agent
(including text threads and the inline assistant), but not in external
agents via ACP.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Fixes#43165
## Problem
MCP prompts were only available in text threads, not agent threads.
Users with MCP servers that expose prompts couldn't use them in the main
agent panel.
## Solution
Added MCP prompt support to agent threads by:
- Creating `ContextServerPromptRegistry` to track MCP prompts from
context servers
- Subscribing to context server events to reload prompts when MCP
servers start/stop
- Converting MCP prompts to available commands that appear in the slash
command menu
- Integrating prompt expansion into the agent message flow
## Testing
Tested with a custom MCP server exposing `explain-code` and
`write-tests` prompts. Prompts now appear in the `/` slash command menu
in agent threads.
Release Notes:
- Added MCP prompt support to agent threads. Prompts from MCP servers
now appear in the slash command menu when typing `/` in agent threads.
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Closes#26823
Release Notes:
- Added support for customising the prompt used for generating commit
message in the rules library
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This re-introduces the `save_file` and `restore_file_from_disk` agent
tools that were reverted in #44949.
I pushed that original PR without trying it just to get the build off my
machine, but I had missed a step: the tools weren't added to the default
profile settings in `default.json`, so they were never enabled even
though the code was present.
## Changes
- Add `save_file` and `restore_file_from_disk` to the "write" profile in
`default.json`
- Add `Thread::has_tool()` method to check tool availability at runtime
- Make `edit_file_tool`'s dirty buffer error message conditional on
whether `save_file`/`restore_file_from_disk` tools are available (so the
agent gets appropriate guidance based on what tools it actually has)
- Update test to match new conditional error message behavior
Release Notes:
- Added `save_file` and `restore_file_from_disk` agent tools to handle
dirty buffers when editing files
