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>
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.
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>
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
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
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>
## 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.
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.
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>
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
Release Notes:
- Added `save_file` and `restore_file_from_disk` tools to the agent,
allowing it to resolve dirty buffer conflicts when editing files. When
the agent encounters a file with unsaved changes, it will now ask
whether you want to keep or discard those changes before proceeding.
Adds an optional `timeout_ms` parameter to the terminal tool that allows
bounding the runtime of shell commands. When the timeout expires, the
running terminal task is killed and the tool returns with the partial
output captured so far.
## Summary
This PR adds the ability for the agent to specify a maximum runtime when
invoking the terminal tool. This helps prevent indefinite hangs when
running commands that might wait for network, user prompts, or long
builds/tests.
## Changes
- Add `timeout_ms` field to `TerminalToolInput` schema
- Extend `TerminalHandle` trait with `kill()` method
- Implement `kill()` for `AcpTerminalHandle` and `EvalTerminalHandle`
- Race terminal exit against timeout, killing on expiry
- Update system prompt to recommend using timeouts for long-running
commands
- Add test for timeout behavior
- Update `.rules` to document GPUI executor timers for tests
## Testing
- Added `test_terminal_tool_timeout_kills_handle` which verifies that
when a timeout is specified and expires, the terminal handle is killed
and the tool returns with partial output.
- All existing agent tests pass.
Release Notes:
- agent: Added optional `timeout_ms` parameter to the terminal tool,
allowing the agent to bound command runtime and prevent indefinite hangs
Uses the latest version of the SDK + schema crate. A bit painful because
we needed to move to `#[non_exhaustive]` on all of these structs/enums,
but will be much easier going forward.
Also, since we depend on unstable features, I am pinning the version so
we don't accidentally introduce compilation errors from other update
cycles.
Release Notes:
- N/A
This PR simplifies error and event handling by removing the
`Ok(LanguageModelCompletionEvent::Status(CompletionRequestStatus::Failed)))`
state from the stream returned by `LanguageModel::stream_completion()`,
by changing it into an `Err(LanguageModelCompletionError)`. This was
done by collapsing the valid `CompletionRequestStatus` values into
`LanguageModelCompletionEvent`.
Release Notes:
- N/A
---------
Co-authored-by: Michael Benfield <mbenfield@zed.dev>
Since we removed the filtering step during context gathering, we want
the model to perform more targeted searches. This PR tweaks search tool
schema allowing the model to search within syntax nodes such as `impl`
blocks or methods.
This is what the query schema looks like now:
```rust
/// Search for relevant code by path, syntax hierarchy, and content.
#[derive(Debug, Clone, Serialize, Deserialize, JsonSchema)]
pub struct SearchToolQuery {
/// 1. A glob pattern to match file paths in the codebase to search in.
pub glob: String,
/// 2. Regular expressions to match syntax nodes **by their first line** and hierarchy.
///
/// Subsequent regexes match nodes within the full content of the nodes matched by the previous regexes.
///
/// Example: Searching for a `User` class
/// ["class\s+User"]
///
/// Example: Searching for a `get_full_name` method under a `User` class
/// ["class\s+User", "def\sget_full_name"]
///
/// Skip this field to match on content alone.
#[schemars(length(max = 3))]
#[serde(default)]
pub syntax_node: Vec<String>,
/// 3. An optional regular expression to match the final content that should appear in the results.
///
/// - Content will be matched within all lines of the matched syntax nodes.
/// - If syntax node regexes are provided, this field can be skipped to include as much of the node itself as possible.
/// - If no syntax node regexes are provided, the content will be matched within the entire file.
pub content: Option<String>,
}
```
We'll need to keep refining this, but the core implementation is ready.
Release Notes:
- N/A
---------
Co-authored-by: Ben <ben@zed.dev>
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Closes#41478
Release Notes:
- Fixed#41478
<img width="459" height="916" alt="Screenshot 2025-10-29 at 1 31 26 PM"
src="https://github.com/user-attachments/assets/1d5b9fdf-9800-44e4-bdd5-f0964f93625f"
/>
> caused by using haiku 4.5 from the anthropic provider and then
swapping to sonnet 3.7 through zed, doing this does mess with prompt
caching but a model swap already invalidates that so it shouldn't have
any cost impact on end users
Was previously sending all of the tools to the LLM on the first message
of a conversation regardless of the selected agent profile. This added
extra context, and tended to create scenarios where the LLM would
attempt to use the tool and it would fail since it was not available.
To reproduce, create a new conversation where you ask the Minimal mode
which tools it has access to, or try to write to a file.
Release Notes:
- Fixed an issue in the agent where all tools would be presented as
available even when using the `Minimal` profile
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
After #38882 we were always including file/directory mentions as
`zed:///agent/file?path=a/b/c.rs`.
However, for most resource links (files/directories/symbols/selections)
we want to use a common format, so that ACP servers don't have to
implement custom handling for parsing `ResourceLink`s coming from Zed.
This is what it looks like now:
```
[@index.js](file:///Users/.../projects/reqwest/examples/wasm_github_fetch/index.js)
[@wasm](file:///Users/.../projects/reqwest/src/wasm)
[@Error](file:///Users/.../projects/reqwest/src/async_impl/client.rs?symbol=Error#L2661:2661)
[@error.rs (23:27)](file:///Users/.../projects/reqwest/src/error.rs#L23:27)
```
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
In practice this just hides the web search tool when not using the Zed
provider
Release Notes:
- Fixed an issue where the web search tool would show up in the profile
selector even when not using a model via Zed Pro
