At this point, this tool rarely gets called and the agent can likely
figure out how to call these itself.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Removed open tool from built-in Agent tools.
Streamline the instructions around communication, tool use, planning,
and project roots.
Remove the `now` tool and also clean up several tool descriptions.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Closes#52042
Release Notes:
- agent: Added setting `subagent_model` to specify which model is used
when subagent is spawned
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
This fixes a race condition where the thread would not get the LSP tools
at startup if the feature flag was not resolved yet.
We now always add the tools, but filter them out when we start a new
turn if the feature flag is not set.
Release Notes:
- N/A
Fixed an issue where the leak detector would sometimes cause panics when
running unit evals. Fixed this by matching the tear-down logic that we
use in the `gpui::test` macro
> thread 'tools::evals::edit_file::eval_from_pixels_constructor'
(14336149) panicked at crates/gpui/src/app/entity_map.rs:1116:9:
Exited with leaked handles:
Leaked handle for entity language::buffer::Buffer (EntityId(50v1)):
Release Notes:
- N/A
In the case where the model would respond with `new_text` before
`old_text`, we would just emit an empty `old_text`, because the parsing
layer was operating under the assumption that `old_text` occurs before
`new_text`.
We now hold back new text chunks if we receive them first, and only emit
them once old_text is complete.
In addition to that we also need to handle the case where the first
chunk contains `old_text` and `new_text`. In that case we don't know
which one of the two fields have finished streaming, since we can't rely
on the ordering anymore. Therefore we hold back all events until we
receive the full edit, and emit a single OldTextChunk (done = true) and
a single NewTextChunk (done = true)
Closes#55398
Release Notes:
- agent: Fixed an issue where editing would sometimes fail for specific
models (Deepseek v4)
Splits the edit tool into two separate tools `write_file` (previously
`mode = write`), and `edit_file` (previously `mode = edit`).
This makes the JSON schema for the `edit_tool` much simpler. We've seen
models (especially older ones) struggle with providing `mode = edit +
edits` and `mode = write + content` fields. This seems to improve eval
scores for Sonnet 4.6 slightly.
Also added two unit evals to ensure that the model uses the tool to
create new/override existing files
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Fixes#54244
When the `read_file` tool is called with a path that points to a
directory instead of a file, it now returns a clear, actionable error
message telling the agent to use `list_directory` instead.
Previously the tool would fail with an unhelpful generic error. Now it
explicitly checks whether the path is a directory before attempting to
read it.
A test covering this case is also included.
Release Notes:
- Fixed `read_file` tool returning an unhelpful error when given a
directory path; it now suggests using `list_directory` instead.
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Fixes#55436
The create-directory agent tool was classified as a read tool, which
caused
the agent UI to render it with the search icon.
This PR marks `create_directory` as an edit tool and gives it a
folder-add
icon in the conversation tool card. Creating a directory mutates the
project,
so treating it as an edit tool better matches the behavior and avoids
the
misleading search icon.
Validation:
- `cargo build -p zed`
- `cargo test -p agent test_create_directory_tool_kind_is_edit --
--nocapture`
- `git diff --check`
- Manually verified in a local dev build that asking the agent to create
`tmp-
zed-icon-test-dir` shows a folder icon instead of a search icon, and
that the
directory is created successfully.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/
zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed create-directory agent tool cards showing a search icon.
<img width="593" height="281" alt="07547c9f-2cf2-432b-8c0f-86f336dce3c5"
src="https://github.com/user-attachments/assets/a5a277ee-56c5-4801-a7d8-27c347222169"
/>
<img width="594" height="157" alt="2b3f2b62-4782-42f1-a20d-c26f9cfe8940"
src="https://github.com/user-attachments/assets/37845785-5145-4701-9060-1dd1bdb60801"
/>
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Move guidance about pty-blocking commands from the `TerminalToolInput`
struct-level doc comment to the `command` field's doc comment so it's
surfaced more prominently to the model in the tool's JSON schema, and
call out `--no-pager` and `GIT_EDITOR=true` explicitly for git
operations.
In practice, the previous wording about `git --no-pager diff` was easy
for agents to overlook, leading to terminal calls that block waiting on
`less` (for `git log`/`git diff`/`git show`) or on an interactive editor
(for `git rebase`/`git commit`/`git merge`).
Unit eval change before/after wording change:
<img width="1662" height="740" alt="image"
src="https://github.com/user-attachments/assets/5f7921f3-87fa-4f88-9839-193ca4522572"
/>
Closes AI-154
Release Notes:
- Zed Agent's terminal tool now much more consistently uses `--no-pager`
and `GIT_EDITOR` with `git` commands
Previously schemars generated oneOf variants for these enums (because we
added inline comments), making the schemas more complicated than they
had to be.
E.g. `edit_file` `mode`
Before:
```json
{
"mode": {
"description": "The mode of operation on the file. Possible values:\n- 'write': Replace the entire contents of the file. If the file doesn't exist, it will be created. Requires 'content' field.\n- 'edit': Make granular edits to an existing file. Requires 'edits' field.\n\nWhen a file already exists or you just created it, prefer editing it as opposed to recreating it from scratch.",
"oneOf": [
{
"description": "Overwrite the file with new content (replacing any existing content).\nIf the file does not exist, it will be created.",
"type": "string",
"const": "write"
},
{
"description": "Make granular edits to an existing file",
"type": "string",
"const": "edit"
}
]
}
}
```
After:
```json
{
"mode": {
"description": "The mode of operation on the file. Possible values:\n- 'write': Replace the entire contents of the file. If the file doesn't exist, it will be created. Requires 'content' field.\n- 'edit': Make granular edits to an existing file. Requires 'edits' field.\n\nWhen a file already exists or you just created it, prefer editing it as opposed to recreating it from scratch.",
"type": "string",
"enum": ["write", "edit"]
}
}
```
Release Notes:
- N/A
We did not really use it in practice (we would only display it in the
tool card header until we received a path), so as is it just wastes
tokens. Therefore removing it.
Release Notes:
- agent: Reduce token usage when LLM edits file
Adds 4 (technically 5) new tools to the zed agent, corresponding to LSP
actions:
- `find_references`
- `goto_definition`
- `rename_symbol`
- `get_code_actions` and `apply_code_actions`
Notes:
- `rename_symbol` skips doing a `prepare_rename`. If there is nothing to
rename at the position, it will forward the error to the agent
- The code action tools are stateful. The state is stored in the
`get_code_actions` tool itself as a `PendingCodeActions`. It is not
passed into/out of subagents. Calling `apply_code_actions` without
calling `get_code_actions` first is an error, but I've never seen an
agent do this
Symbols are identified by:
- file name
- line number
- symbol
If there is no substring match on that line for the symbol text, it is
an error. If there are multiple, it chooses the first. This may not be
great if you have a line like: `fn convert(x: foo::Something) ->
bar::Something` - the second `Something` is a different symbol, but is
inacessible to these tools. Probably fine for now, but we can look into
improving
Release Notes:
- Added: New tools for the Zed Agent for interacting with language
servers
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Ports some changes introduced in #51165 out to make merge conflicts
easier to handle.
Splits the `Pipeline` into two separate types for mode edit/write so we
don't need to maintain that invariant inside the pipeline/in the parser
Also moves the parser to be a submodule of `edit_file_tool`
Release Notes:
- N/A
Does not actually seem useful to the LLM to include `Failed to receive
tool input: ...` in the error message. We now only include the actual
error.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- agent: Improve reliability when LLM edits file
Previously, we would always return an error if the LLM attempted to edit
a file that had been modified on disk or by the user in the meantime.
However, this often led to unnecessary failures and slowdowns. So,
instead of failing every time, we now attempt to resolve a match. If we
don't find one, we return an error to inform the LLM that the file has
been modified since the last read.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- agent: Do not fail edit tool if file has unsaved changes
cc: @danilo-leal
This setting is from when we had the git worktree picker in the agent
panel, now that it is in the menu bar it doesn't make sense to keep it.
We plan to add a similar feature in the future to handle the "new thread
== new git worktree" workflow
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
gpt-5.5 likes to call the `now` tool with upper-case "UTC", leading to
this error:
> Failed to receive tool input: tool input was not fully received
Release Notes:
- N/A
Updates our MCP implementation to support `2025-06-18` and `2025-11-25`
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#54458, #53456
Release Notes:
- Support latest MCP version (`2025-11-25`)
We already enabled the feature flag, but that only applies to logged in
users. Going to make sure that everyone gets the new tool as long as the
model supports it.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- agent: Improve edit tool performance for models that support streaming
tool calls.
Fixes#51537
`regex::escape()` escapes dashes, but dashes are only special inside
`[]` character classes in regex. This means tool_permissions patterns
end up with unnecessary backslashes:
**Before:** `^https?://typescript\-eslint\.io`, `^git\-lfs\s+pull(\s|$)`
**After:** `^https?://typescript-eslint\.io`, `^git-lfs\s+pull(\s|$)`
The fix adds a small `escape_for_pattern()` helper that calls
`regex::escape()` then strips the unnecessary dash escaping via
`.replace("\\-", "-")`. This is applied to all five call sites in
`pattern_extraction.rs`.
Tests updated to expect unescaped dashes, plus a new
`test_dashes_are_not_escaped` test covering terminal commands, URLs, and
paths with dashes.
This PR was developed with AI assistance.
Release Notes:
- Fixed unnecessary escaping of dashes in agent tool permission patterns
(e.g. `typescript\-eslint` is now `typescript-eslint`)
---------
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
NativeAgentServer::connect used `prompt_store.await?` which turned any
PromptStore initialization failure (permission denied, disk issues,
etc.) into a hard connection error, putting the ConversationView into
LoadError state and preventing all new native agent threads from being
created.
Changed to `.log_err()` so the error is logged at ERROR level but thread
creation proceeds with `prompt_store: None`. `NativeAgent::new` already
accepts `Option<Entity<PromptStore>>` and handles `None` gracefully —
user custom prompts won't load but threads still work.
Added a regression test that serializes a stale thread ID, loads the
panel (triggering the "last active thread not found in database"
warning), then dispatches NewThread through the real NativeAgentServer
path and verifies it produces a connected thread.
Release Notes:
- Agent panel now handles filesystem errors more gracefully
This change fixes a small bug where we were showing "Loading project..."
even when in fact we had already started the search.
It also refactors three booleans in the `SearchState` enum, so that it's
harder to make similar mistakes in the future.
Release Notes:
- N/A
When the agent issued several parallel tool calls that all required
confirmation, clicking "Always for en.wikipedia.org" (or similar) on the
first prompt would persist the new rule to settings but leave the
sibling prompts stuck waiting on their own oneshot channels. The same
happened across subagents, and whenever the user edited settings.json by
hand while prompts were on screen.
`ToolCallEventStream::authorize()` now takes full ownership of the
permission decision. It evaluates the tool-permission settings up front,
and on Confirm it spawns a task that races the user's response against a
`SettingsStore` observer. When settings change, it re-runs the decision;
a new Allow or Deny drops the response receiver, flips the tool call
status to dismiss the prompt UI, and resolves the task without user
input. Subagents fall out of this for free since each thread observes
`SettingsStore` independently.
A few tools (`copy_path`, `move_path`, `delete_path`,
`create_directory`, `save_file`, `restore_file_from_disk`, and the
`edit-file` helper) sometimes need to prompt even when settings say
Allow — for example, edits that target `.zed/settings.json`. For those,
a new `authorize_always_prompt()` method skips the settings check and
always waits for user input; tools pick between the two at the call site
based on whether the path is sensitive.
Closes#54101.
Release Notes:
- In the agent panel, when you click "Always allow" for a tool, this
decision now gets propagated to other pending calls to the same tool.
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Fixes#54618.
## Summary
After upgrading from `v0.232.x` to `v0.233.5+`, many users reported that
most
of their agent threads "disappeared" from the sidebar. The threads are
still
on disk in the legacy `threads.db` — but they never make it into
`sidebar_threads`, which is the only table the new sidebar UI reads
from, so
they're unreachable from the UI.
The root cause is a race between `ThreadStore::reload` and
`migrate_thread_metadata`:
- `ThreadStore::new` constructs with an empty in-memory `Vec` and kicks
off
`reload()` as a fire-and-forget task.
- `migrate_thread_metadata` runs during `agent_ui::init` and reads
`ThreadStore::global(cx).read(cx).entries()` synchronously, without
awaiting that reload.
- On cold boot the migration observes an empty iterator, early-returns
on
`to_migrate.is_empty()`, and never populates `sidebar_threads`. The
migration runs every launch, so it keeps losing the race forever.
Empirically, the only rows that *did* end up in `sidebar_threads` for
affected users came from `handle_conversation_event` writing rows when
the
user actively interacted with a thread. That's why users would typically
see
a handful of recently-touched threads rather than their full history.
## Fix
1. `ThreadStore` now tracks its current reload as a `Shared<Task<()>>`
and
exposes it via `reload_task()`. `migrate_thread_metadata` awaits this
before reading `entries()`.
2. Move the top-5-per-project unarchive pass out from under the
`is_first_migration` guard. Previously the rescue only ran when
`sidebar_threads` was empty, which meant any user who had even one
pre-existing row (e.g. from interacting with a thread on a prior launch)
got every subsequent batch of migrated threads archived with no rescue.
Running the rescue per-batch is stateless and idempotent — a user who
bounces between older releases and newer ones still gets their top 5 per
project surfaced each time a new batch is migrated.
No new KVP flag or one-shot backfill is needed: because the migration
already dedupes by session_id and runs on every launch, the next cold
boot
on a fixed build picks up any legacy threads that earlier launches
missed.
## Structure
The PR is split into two commits to make the diff easy to verify:
1. **Regression test** — fails on `main`, reproduces the cold-boot race
by
seeding the legacy DB, reinitializing `ThreadStore` to get a fresh empty
cache, and running the migration without parking first.
2. **The fix** — gates entries reads on `reload_task().await`, and
adjusts
the per-batch rescue policy. Updates one existing test's assertions to
match the new per-batch rescue policy.
## Validation
- The regression test fails on `main`, passes after the fix.
- All `agent_ui`, `agent::thread_store`, and `sidebar` lib tests pass.
- `./script/clippy -p agent -p agent_ui` is clean.
- End-to-end repro with a real on-disk data dir: launched `v0.230.2 →
v0.231.2 → v0.232.3 → v0.233.8` as a non-staff user, creating 15 threads
and interacting with one, reproduced the reported state (1 thread in
sidebar, 14 missing). Launched a debug build of this branch against the
same data dir: `Migrating 14 thread store entries` in the log, 15 rows
in
`sidebar_threads` with 6 unarchived (the interacted-with thread plus the
5 most recent), 9 archived and reachable from the archive view.
Release Notes:
- Fixed agent threads appearing to be missing after upgrading to the
parallel-agents sidebar. The thread-metadata migration was racing
against the on-disk thread store's async reload and skipping itself on
every launch. Upgrading to this build runs the migration successfully;
previously-missing threads are surfaced either in the sidebar (5 most
recent per project) or in the archive view.
No, sadly, the title is not a typo. See
https://www.githubstatus.com/incidents/zsg1lk7w13cf for the context.
I'll read with joy and popcorn through that root cause analysis.
It makes literally zero sense what happened here, but for some completly
bonkers reason GitHub completely messed up the merge queue with
https://github.com/zed-industries/zed/pull/54632.
I have no idea how it happened. It makes literally zero sense. A PR
going into the merge queue should have the same LoC when getting out of
it. GitHub obviously does not check this. GitHub causes extra work with
a feature that is supposed to save time.
Thanks, I guess.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR brings back the button to filter remote branches when accessing
the title bar's branch picker with the mouse. It was unintentionally
removed when we introduced the new worktree picker.
Release Notes:
- N/A
When starting a search on a project that is in the middle of a scan, we
used to miss results in files that had not yet been scanned.
This change makes the search wait for the scan to complete.
Closes#9858
Release Notes:
- Fixed incomplete search results when the project scan is incomplete
Testing out Niko's new SDK design
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Fixes#52453Fixes#53246
Both issues were introduced by #51208 ("Handle Linux FS Rescan Events"),
which added `PathEventKind::Rescan` handling.
## Rules files not loading (#52453)
`load_worktree_info_for_system_prompt` called `load_worktree_rules_file`
synchronously, which uses `entry_for_path()` on the current worktree
snapshot. If the background scanner hasn't finished its initial scan,
the entry doesn't exist yet and the lookup returns `None` — the code
concludes no rules file exists. This was always a latent race condition,
but became more visible after Rescan events were introduced, since they
can trigger additional `WorktreeUpdatedEntries` churn that interacts
with the refresh mechanism.
The fix awaits `scan_complete()` on local worktrees before performing
the rules file lookup, ensuring the full directory tree is indexed
first.
## Config file rescan clearing OAuth tokens (#53246)
The `Rescan` handlers in `watch_config_dir` used
`fs.load(file_path).await.unwrap_or_default()`, which turns any
file-read error into an empty string. This empty string flows to
consumers like `CopilotChat`, where `extract_oauth_token("")` returns
`None`, causing the OAuth token to be unconditionally overwritten with
`None` — triggering re-authentication.
The fix changes both Rescan handlers to skip files that fail to load
(using `if let Ok(contents) = ...`), matching the pattern already used
by the `Created`/`Changed` handler.
Release Notes:
- Fixed rules files (AGENTS.md, CLAUDE.md, .rules, etc.) sometimes not
being applied in agent threads.
- Fixed GitHub Copilot re-prompting for authentication after filesystem
rescan events.
Closes#54313
**Before:**
- Favoriting a model only stored `provider`, `model`, and hardcoded
`enable_thinking` to `false`.
- Selecting a favorited model would not restore your preferred
`enable_thinking`, `effort`, or `speed` settings.
This means that if you'd like to use, say, GPT 5.4 your favorite model
on `xhigh` effort every single time, switching to it would set effort to
`medium` (the default for the model) instead.
**After:**
- Favoriting a model captures your current `enable_thinking`, `effort`,
and `speed` when it matches the currently-selected model. Otherwise, it
falls back to the model's own defaults, i.e. thinking-capable models are
no longer favorited with `enable_thinking` forced to `false`.
- Selecting a favorited model applies its stored thinking / effort /
speed.
- Toggling thinking, changing effort, or toggling fast mode on a
favorited model updates the favorite entry in settings (along with the
existing `default_model` setting), so the preference doesn't drift.
Release Notes:
- Agent favorite models now remember and restore per-model thinking,
effort level, and fast mode preferences.
Follow up to https://github.com/zed-industries/zed/pull/52730.
This PR adds a boolean setting `limit_content_width` in the Agent Panel
settings that allows turning off the content max-width entirely, which
was added for better readability. We had a handful of requests for it,
so it feels fair.
<img width="500" alt="Screenshot 2026-04-20 at 8 57@2x"
src="https://github.com/user-attachments/assets/d2540b35-3fa8-4424-895d-dc499ac4839c"
/>
Release Notes:
- Agent: Added a new `limit_content_width` setting in the agent panel
that allows turning off the content max-width limit.
Reimplements #36722 while fixing the race that required the revert in
#36932.
When no default model is configured, this picks an environment fallback
by authenticating all providers. It always prefers the Zed cloud
provider when it's authenticated, and waits for its models to load
before picking another provider as the fallback, so we don't flicker
from Zed models to Anthropic while sign-in is in flight.
The fallback is recomputed whenever provider state changes (via
`ProviderStateChanged`/`AddedProvider`/`RemovedProvider` events), so the
selection becomes correct as soon as cloud models arrive.
### What changed vs. the original PR
- `language_models::init` now owns `authenticate_all_providers`
(previously done in `LanguageModelPickerDelegate` and `agent`'s
`LanguageModels`).
- After all authentications settle, and on any subsequent provider state
change, `update_environment_fallback_model` recomputes the fallback.
- The fallback logic prefers Zed cloud: if the cloud provider is
authenticated, only use it (waiting for its models to load). Otherwise,
fall through to the first authenticated provider with a default or
recommended model.
- `LanguageModelRegistry::default_model()` falls back to
`environment_fallback_model` when no explicit default is set.
- Existing `Thread`s that are empty are updated to the new default when
`DefaultModelChanged` fires, so a blank thread started before sign-in
switches to Zed models once the user signs in.
Release Notes:
- agent: Automatically select a model when there's no selected model or configured default
Follow up to #53999
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
The `user_message_id` parameter on `AgentConnection::prompt` was
`Option<UserMessageId>`, but `NativeAgentConnection::prompt` immediately
called `.expect()` on it, crashing when the value was `None`.
Because the `expect` message said `UserMessageId` was required, this PR
makes the parameter not optional which makes the panic impossible.
This means we also need to unconditionally generate an ID in `send`,
where before we gated this on whether `truncate` returned `Some`.
Generating IDs unconditionally should be find, especially because the
prompt requires them.
Release Notes:
- N/A
Ben Brandt