This small change *may* help with #39211, #35025 or #39031 although I'm
not positive it will fix it entirely. At a minimum, it should prevent
sending invalid requests to the Mistral API, which return a 400 error
and can prevent the thread from progressing if it gets stuck in a retry
loop.

This should prevent sending a message like `{ "role": "assistant",
"content": "" }` if for some reason the thread contains a message with
an empty text content and no tool calls.

Some users (including myself) have encountered this with the Devstral 2
models, although it doesn't seem trivial to reproduce:
https://github.com/zed-industries/zed/issues/37021#issuecomment-3728902562

When it occurs, error logs look something like this:
```
2026-01-24T19:53:35-08:00 ERROR [crates/agent/src/thread.rs:984] invalid type: string "Failed to connect to Mistral API: 400 Bad Request {\"object\":\"error\",\"message\":\"Assistant message must have either content or tool_calls, but not none.\",\"type\":\"invalid_request_assistant_message\",\"param\":null,\"code\":\"3240\"}", expected struct EditFileToolOutput
2026-01-24T19:53:35-08:00 ERROR [crates/agent/src/thread.rs:984] invalid type: string "Failed to connect to Mistral API: 400 Bad Request {\"object\":\"error\",\"message\":\"Assistant message must have either content or tool_calls, but not none.\",\"type\":\"invalid_request_assistant_message\",\"param\":null,\"code\":\"3240\"}", expected struct EditFileToolOutput
2026-01-24T19:53:35-08:00 ERROR [crates/agent/src/thread.rs:984] invalid type: string "Failed to connect to Mistral API: 400 Bad Request {\"object\":\"error\",\"message\":\"Assistant message must have either content or tool_calls, but not none.\",\"type\":\"invalid_request_assistant_message\",\"param\":null,\"code\":\"3240\"}", expected struct EditFileToolOutput
```

Release Notes:

- Fixed agent sometimes sending invalid messages to Mistral API

Release Notes:

- N/A

Closes #N/A (no existing issue - implemented to enable image input for
Bedrock models)

This PR enables the "@" image mention feature for Bedrock models that
support vision capabilities.

**Changes:**
- Added `supports_images()` method to Bedrock `Model` enum
- Wired up image support in the Bedrock language model provider
- Added `MessageContent::Image` handling to convert base64 images to
Bedrock's expected format
- Added tool result image support

**Supported models:** Claude 3/3.5/4 family, Amazon Nova Pro/Lite, Meta
Llama 3.2 Vision, Mistral Pixtral

Release Notes:

- Added image input support for Amazon Bedrock models with vision
capabilities

Closes #48732

- [X] Tests or screenshots needed? 
- [X] Code Reviewed
- [X] Manual QA
The fix enables interactive mode during task execution, resolving the
Conda activation error. However, enabling this mode adds some overhead.
In my environment, the task startup time increased by approximately 1
seconds due to the loading of ~/.zshrc.


[录屏 2026-02-08
23-49-53.webm](https://github.com/user-attachments/assets/4064e366-b0d2-4a8c-9599-c4108e76af9f)

Release Notes:

- Fixed conda activation error appears during task execution.

Follow-up to https://github.com/zed-industries/zed/pull/41111.

PR #41111 introduced combined injection handling, but cursor language
queries still relied on layer range selection alone. For combined
injections this can surface a language from the outer combined layer
even when the cursor is outside that language's actual included
sub-range. So, we just need to add sub-range filtering based on
anchor-aware boundary checks in the same way we did in the previous PR.
That means: apply it in `Buffer::language_at`,
`Buffer::languages_at`, and `BufferSnapshot::language_scope_at`. All
places that rely on the described behavior.

I also added some additional test cases for the `HTML+ERB` lang to
verify language resolution for HTML and Ruby positions.
Thank you!

Closes https://github.com/zed-industries/zed/issues/48358

Release Notes:

- Respect combined injection sub-ranges for language queries

Closes #45107

Release Notes:

- Fixed soft wrap prematurely wrapping with certain fonts

---------

Co-authored-by: Lukas Wirth <lukas@zed.dev>

Closes https://github.com/zed-industries/zed/issues/10696

Adds support for rendering Mermaid diagrams in the markdown preview
using
[mermaid-rs-renderer](https://github.com/1jehuang/mermaid-rs-renderer)
(with [a
patch](https://github.com/1jehuang/mermaid-rs-renderer/pull/35)).

- Renders mermaid diagrams on background task
- Shows the previously cached image while re-computing
- Supports a scale parameter i.e. default 100
- Falls back to raw mermaid source code when render fails

<img width="1512" height="897" alt="image"
src="https://github.com/user-attachments/assets/9157625d-bb62-402f-8a8b-517f28d43f95"
/>

Release Notes:

- Added mermaid diagram rendering support to the markdown preview panel.

---------

Co-authored-by: oscarvarto <contact@oscarvarto.mx>
Co-authored-by: oscarvarto <oscarvarto@users.noreply.github.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>

Release Notes:

- N/A

---------

Co-authored-by: Lena <241371603+zelenenka@users.noreply.github.com>

In writing PHP snippets, I ran into this issue and only discovered this
has to be done through reviewing examples of other PHP snippets.

I think it would be useful to include some mention of this behavior in
the documentation - although I'm not great at writing docs and not sure
if this is the best place or way to write this out.

Open to any feedback on this or perfectly okay if maintainers find this
unnecessary.

Release Notes:

- N/A

---------

Co-authored-by: Kunall Banerjee <hey@kimchiii.space>

While the 60 days of inactivity works for a lot of the issues, with
other (more stubborn and popular) bugs it's too noisy to nag people
every eight weeks.

Also changing days-before-close after seeing a few cases of people
getting back to us after more than two weeks since the bot's question.

Release Notes:

- N/A

The blade graphics library is a mess and causes several issues for both
Zed users as well as other 3rd party apps using GPUI. This PR removes
blade and implements the linux platform using `wgpu` which is the
de-facto standard in the rust UI and graphics ecosystem. This will not
just fix [issues that Zed users have
today](https://github.com/YaLTeR/niri/issues/2335), but also profit from
wgpu improvements in the futures, from other projects contributing (such
as the bevy game engine, Iced, or pretty much every other relevant
project).

This will close several related issues on the zed repo as well. See
https://github.com/zed-industries/zed/issues?q=frozen%20nvidia%20linux
(probably not all of them, have only tested the freeze on nvidia and
Smithay-based wayland compositors).

Some related issues:
https://github.com/zed-industries/zed/issues/44814
https://github.com/zed-industries/zed/issues/40481
https://github.com/YaLTeR/niri/issues/2335
https://github.com/zortax/zlaunch/issues/15

Would appreciate feedback if this is something the zed maintainers would
be interested in.

Release Notes:

- N/A

---------

Co-authored-by: John Tur <john-tur@outlook.com>

Support stdin from Jupyter kernels AKA `input()` and `getpass()` in
IPython.

<img width="460" height="380" alt="image"
src="https://github.com/user-attachments/assets/3b26457f-d651-4514-94b4-8cbb6ff52003"
/>

<img width="391" height="243" alt="image"
src="https://github.com/user-attachments/assets/255bd388-5622-4521-ab93-f9ef7fe861aa"
/>

Closes #22746

Release Notes:

- Added STDIN support (`input` / `raw_input`) to REPL

Remove GPT-4o, GPT-4.1, GPT-4.1-mini, and o4-mini from BYOK model
options in Zed before OpenAI retires these models.

These models are being retired by OpenAI (ChatGPT workspace support ends
April 3, 2026), so they have been removed from the available models list
in Zed's BYOK provider.

Closes AI-4

Release Notes:

- Removed deprecated GPT-4o, GPT-4.1, GPT-4.1-mini, and o4-mini models
from OpenAI BYOK provider

Reverts zed-industries/zed#49034

This proved to be a bit disruptive, we should re-land once we have more
of the pieces together.

Release Notes:

- N/A

Follow-up of https://github.com/zed-industries/zed/pull/48780

Fixes incorrect multi byte characters treatment in the symbol range when
highlighting:
<img width="1728" height="507" alt="image"
src="https://github.com/user-attachments/assets/c6639220-f08a-4ea8-bf99-926566e356ae"
/>

Fixes multiple language servers' duplicate data display:
<img width="1726" height="925" alt="image"
src="https://github.com/user-attachments/assets/ca98ee29-732e-4c8e-adf4-21a9523a5a9c"
/>


Release Notes:

- N/A

Closes #48308.

Before:

![zed-#48308-before](https://github.com/user-attachments/assets/3da194c1-6e86-4743-8194-94dd1a17682c)

After:

![zed-#48308-after](https://github.com/user-attachments/assets/4f52ff38-bcb8-4f07-8e44-55c57ff16002)

Release Notes:
- Fixed file changes not being discarded when closing a tab with "Don't
Save" or "Discard all".

Closes #49055

**Heads up**: This might be a naïve solution. I ran into the issue after
merging latest main into
https://github.com/zed-industries/zed/pull/48896, and confirming that it
was unrelated to that PR and incoming from upstream.

Agent one-shot the fix, it works and tests pass. But I'm still wrapping
my head around the changes that led to the bug. I figured the breakage
is bad enough (I couldn't open devcontainers at all) to submit a
possibly naïve fix.

## Fix 

Hoists the `find_devcontainer_configs` call out of `new_dev_container`
and into the call site, where we already have a direct `&mut Workspace`
reference that doesn't go through the entity map. The computed configs
are passed into `new_dev_container` as an argument.

## What was happening

After #48800 ("Re-add MultiWorkspace"), `with_active_or_new_workspace`
nests a `Workspace` entity lease inside a `MultiWorkspace` entity lease.
The `OpenDevContainer` handler was also changed from async to sync in
the same PR, so `RemoteServerProjects::new_dev_container` now runs while
`Workspace` is leased. Inside `new_dev_container`, a
`WeakEntity<Workspace>::read_with` call tries to read `Workspace`
through the entity map, finds it already leased, and panics.

Release Notes:

- Fixed a panic when opening the dev container modal via the
`OpenDevContainer` action.

Release Notes:

- N/A

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>

This PR uses the already-existing `ListSubHeader` component for the
section subheader as opposed to a custom label.

<img width="350" height="942" alt="Screenshot 2026-02-12 at 8  30@2x"
src="https://github.com/user-attachments/assets/a86ce59d-9d3b-4b10-87c8-69da1469743d"
/>

- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- N/A

Release Notes:

- N/A (still featured flag)


Operations as follows:
1. Click to select
2. Double-click to open diff

Operation demo:


https://github.com/user-attachments/assets/15e583c1-37ea-4166-972d-d2247b9c5fff

---------

Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Co-authored-by: Anthony Eid <anthony@zed.dev>

If you have Zed open and the sidebar open, don't show a notification
when a thread finishes.

Closes AI-18

(No release notes because multi-agent is still feature-flagged.)

Release Notes:

- N/A

Closes https://github.com/zed-industries/zed/issues/33430

Two changes:

1. Fix `observe_global_in` to not permanently remove observers when the
window is transiently unavailable (e.g. temporarily taken during a
nested update). Previously this returned false and silently removed the
observer from the subscriber set. Now it checks whether the entity is
actually dropped before removing — if the entity is alive but the window
is just unavailable, it keeps the observer alive.

2. Extend `dock_to_preserve` in `handle_pane_focused` to also preserve
docks whose active panel has focus, not just docks whose panel's inner
pane matches the focused pane. Panels like `AgentPanel` don't implement
`pane()` (only panels like `TerminalPanel` that contain panes do), so
the existing preservation logic never identified the agent panel's dock
as needing protection. This meant that when the agent panel was zoomed
and a center pane received focus (e.g. during macOS window activation
events), `dismiss_zoomed_items_to_reveal` would close the dock, making
the panel disappear unexpectedly.

Closes AI-16

Release Notes:

- Fixed agent panel unexpectedly closing when zoomed and the window
regains focus.

When the agent panel (or any dock panel) is open and
fullscreened/zoomed, switching to a different workspace in the sidebar
and then switching back caused the panel to close. It should remain both
open and zoomed.

The root cause was in `MultiWorkspace::focus_active_workspace()` — it
always focused the center pane of the active workspace. This triggered
`dismiss_zoomed_items_to_reveal(None)`, which closed any zoomed dock
panel (the same behavior as when a user intentionally clicks away from a
zoomed panel).

The fix checks if any dock has a zoomed panel before deciding what to
focus. If a zoomed panel exists, it focuses that panel instead of the
center pane, preventing the dismiss logic from firing.

Closes AI-22

Release Notes:

- Fixed panels losing their fullscreen state when switching between
workspaces.

Release Notes:

- Fix a potential crash around multibyte characters in edit predictions

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>

Closes https://github.com/zed-industries/zed/issues/49060

Release Notes:

- Fixed semantic highlights not cleared when disabled in settings

Remove the `AgentsPanel` (from the `agent_ui_v2` crate) and the utility
pane infrastructure from the codebase.

The Agents Panel was a separate panel gated behind the `agent-v2`
feature flag that was redundant with the existing Agent Panel. Utility
panes were a layout concept (secondary panes next to the editor,
separate from dock panels) whose only consumer was `AgentThreadPane` in
the Agents Panel.

### Changes
- Deleted the entire `agent_ui_v2` crate (`agents_panel.rs`,
`agent_thread_pane.rs`)
- Deleted `workspace/src/utility_pane.rs`
- Removed `UtilityPane`, `UtilityPaneHandle`, `UtilityPanePosition`,
`MinimizePane`, `ClosePane` from `workspace/src/dock.rs`
- Removed all utility pane fields, methods, and render blocks from
`workspace.rs`
- Removed all aside toggle code from `pane.rs` and `pane_group.rs`
- Removed `agents_panel_dock` setting from agent settings and
`default.json`
- Removed all `agent_ui_v2` references from `main.rs`, `zed.rs`, and
Cargo.toml files
- Cleaned up test code in `tool_permissions.rs` and `agent_ui.rs`

Closes AI-17

(No release notes because this was all feature-flagged.)

Release Notes:

- N/A

These prompts can be used to automatically diagnose and fix crashes
report in Sentry.

Usage:
1. Find a crash in Sentry. It will have an ID like ZED-123
2. In an agent, do a prompt like `Follow the instructions in
@investigate.md to investigate ZED-123`
3. Once the agent finds a repro, fix it in a new thread by saying
`Follow the instructions in @fix.md`

Release Notes:
- N/A

---------

Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>

This PR adds basic support for keyboard navigation for the git graph
panel.

**Back and forward**:


https://github.com/user-attachments/assets/5015b0d9-bf83-4944-8c9b-1c5b9badfdb4

**Scrolling**:


https://github.com/user-attachments/assets/451badb5-59df-48a2-aa73-be5188d28dae

- [x] Tests or screenshots needed?
- [x] Code Reviewed
- [x] Manual QA
- Do we need to add keybinds for it, or is falling back to the default
keybindings enough?
 
 **TODO**:
 - [x] Add auto scroll when you select the last visible item

Release Notes:

- N/A (no release notes since its behind a feature flag)

- [ ] Tests or screenshots needed?
- [ ] Code Reviewed
- [ ] Manual QA

Release Notes:

- N/A

---------

Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>

It is maybe possible that, if a process's parent dies, the PID can be
reused by a different process. This could cause an infinite loop in
`is_descendant_of`. To fix this, break out of the loop when a cycle is
detected.

- [ ] Tests or screenshots needed?
- [X] Code Reviewed
- [X] Manual QA

Release Notes:

- N/A

---------

Co-authored-by: Eric Holk <eric@zed.dev>

Release Notes:

- Changed the way context window is set for ollama at the provider level
instead of per model.

---------

Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>

Bash:
<img width="469" height="149" alt="bash"
src="https://github.com/user-attachments/assets/179c9157-58b4-49a3-a166-78486eee5334"
/>

Bash output:
<img width="319" height="77" alt="bash_output"
src="https://github.com/user-attachments/assets/2f5f6582-8538-4508-81cc-84007779d359"
/>

Zsh:
<img width="414" height="139" alt="zsh"
src="https://github.com/user-attachments/assets/23cbb61c-6af1-4956-91a6-39d00319d4fc"
/>

Zsh output:
<img width="326" height="69" alt="zsh_output"
src="https://github.com/user-attachments/assets/beb76f68-fb0c-4140-91ea-bf66a50294fc"
/>

Dash:
<img width="343" height="121" alt="dash"
src="https://github.com/user-attachments/assets/47f44fda-2130-4076-9f65-12c5b1094a53"
/>

Dash output:
<img width="343" height="75" alt="dash_output"
src="https://github.com/user-attachments/assets/176459a2-9dd7-4bd9-8a3d-a7fe39d3b7c3"
/>

- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- Added runnable support for bash.

Co-authored-by: ozacod <ozacod@users.noreply.github.com>

Implements automatic label generation for VSCode tasks that don't have
explicit 'label' fields, matching VSCode's behavior.

Changes:
- Made label field optional in VsCodeTaskDefinition deserialization
- Implemented custom deserializer to auto-generate labels:
  - npm tasks: 'npm: {script}' (e.g., 'npm: start')
  - shell tasks: first word of command (e.g., 'echo')
  - gulp tasks: 'gulp: {task}' (e.g., 'gulp: build')
  - fallback: 'Untitled Task'
- Added test data file with tasks without labels
- Added test cases

Closes #47749

Release Notes:

- Fixed: VSCode tasks.json files with tasks missing explicit `label`
fields now parse correctly. Labels are auto-generated matching VSCode's
behavior (e.g., "npm: start").

When two Zed instances share the same data directory (e.g. a release
build and a dev build running simultaneously), SQLite operations can
fail with "database is locked" (error code 5), surfacing as a "Failed to
Launch" error in the agent panel.

The root cause is `PRAGMA busy_timeout=1` in `crates/db/src/db.rs`,
which gives SQLite only 1ms to wait for a write lock before giving up.
With WAL mode, the actual lock hold times are microseconds — the problem
isn't long-held locks, it's that we give up before even trying to wait.
During startup, both instances hit the DB heavily for workspace
restoration, so even tiny overlaps fail.

This changes `busy_timeout` from 1ms to 500ms, giving SQLite more room
to retry without (hopefully) any perceptible delay to the user.

Closes AI-20

Release Notes:

- N/A

This PR actually fixes two issues:
- the thread title being overridden even after it's been manually
edited; as you go and come back from the thread history view, the edited
title would get swapped for the auto-summarized one
- the parent thread title sometimes displaying the title of a subagent
thread; this would also override the manual edit

- - -

- [x] Tests
- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- Agent: Fixed thread titles being overridden even when manually edited.

---------

Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>

Closes #ISSUE

- [ ] Tests or screenshots needed?
- [ ] Code Reviewed
- [ ] Manual QA

Release Notes:

- N/A

When users have the `multi-workspace` feature flag enabled (agent-v2),
the default dock position for the agent panel is changed from right to
left.

This adds a `update_default_settings` method to `SettingsStore` that
allows mutating defaults in place, then observes the
`AgentV2FeatureFlag` to update the agent dock default accordingly.
Because this modifies the defaults layer, user-configured dock positions
still take precedence.

Closes AI-15

(No release notes because multi-agent is feature-flagged.)

Release Notes:

- N/A

## Fix incorrect context size limits for GitHub Copilot Chat models

Fixes #44909

### Problem

The agent panel was displaying incorrect token limits for GitHub Copilot
models. Users reported that:
- The agent panel always showed a **128K token limit** for all GitHub
Copilot models, regardless of their actual context window size
- Claude models (e.g., Claude 3.7 Sonnet, Claude Opus 4.5) were showing
~90K instead of their actual 200K context window
- GPT-4o was showing 110K instead of its actual 128K context window
- Users could continue using models beyond the displayed limit, which
worked but was confusing

### Root Cause

The `max_token_count()` method in `copilot_chat.rs` was returning
`max_prompt_tokens` instead of `max_context_window_tokens`:

```rust
// Before (incorrect)
pub fn max_token_count(&self) -> u64 {
    self.capabilities.limits.max_prompt_tokens
}
```

GitHub's API returns three different token-related fields:
- `max_context_window_tokens`: The **full context window size** (e.g.,
200K for Claude 3.7)
- `max_prompt_tokens`: GitHub's limit for prompt input (e.g., 90K for
Claude 3.7)
- `max_output_tokens`: Maximum output tokens (e.g., 16K)

The `max_token_count()` method in the `LanguageModel` trait is expected
to return the **full context window size** — this is consistent with all
other providers (Anthropic returns 200K for Claude, OpenAI returns 128K
for GPT-4o, etc.).

### Solution

<img width="583" height="132" alt="Screenshot 2026-01-25 at 1 07 53 AM"
src="https://github.com/user-attachments/assets/847e2fdb-635d-44bc-a630-2d4867ba8c32"
/>


Changed `max_token_count()` to return `max_context_window_tokens`:

```rust
// After (correct)
pub fn max_token_count(&self) -> u64 {
    self.capabilities.limits.max_context_window_tokens as u64
}
```

### Impact

| Model | Before | After |
|-------|--------|-------|
| Claude 3.7 Sonnet | 90,000 | **200,000** |
| Claude Opus 4.5 | 90,000 | **200,000** |
| GPT-4o | 110,000 | **128,000** |

### Testing

Added a new test
`test_max_token_count_returns_context_window_not_prompt_tokens` that:

1. Deserializes model JSON with distinct `max_context_window_tokens` and
`max_prompt_tokens` values
2. Verifies Claude 3.7 Sonnet returns 200,000 (context window), not
90,000 (prompt tokens)
3. Verifies GPT-4o returns 128,000 (context window), not 110,000 (prompt
tokens)

All existing tests continue to pass:
```
running 4 tests
test tests::test_unknown_vendor_resilience ... ok
test tests::test_max_token_count_returns_context_window_not_prompt_tokens ... ok
test tests::test_resilient_model_schema_deserialize ... ok
test result: ok. 4 passed; 0 failed
```


Release Notes:

- copilot: Fixed incorrect context window size displayed for GitHub
Copilot Chat models in the agent panel.

Closes #46556

  ## Summary

- Fix "Property `ty` is not allowed" warning in `settings.json` for LSP
adapters registered via `register_available_lsp_adapter()`
- Add `available_lsp_adapter_names()` method to include these adapters
in schema generation
- Support `initialization_options` schema lookup for available adapters

  ## Problem

LSP adapters registered via `register_available_lsp_adapter()` were not
included in the settings JSON schema. This caused validation warnings
like:

  Property ty is not allowed

Even though `ty` is a built-in Python language server that works
correctly.

  **Affected adapters:**
  - `ty`, `py`, `python-lsp-server`
  - `eslint`, `vtsls`, `typescript-language-server`
  - `tailwindcss-language-server`, `tailwindcss-intellisense-css`

  ## Solution

  Schema generation now queries both:
  1. `all_lsp_adapters()` - adapters bound to specific languages
2. `available_lsp_adapter_names()` - adapters enabled via settings (new)

  Related: #43104, #45928 
  
  Release Notes:

- Fixed an issue where not all LSP adapters would be suggested for
completion, or recognized as valid in `settings.json`

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>

Just some relatively small UI adjustments, like adding the forward arrow
to make it clearer there's a hierarchy between the parent thread and the
subagent thread, and a check icon to comunicate the subagent thread is
done.

<img width="500" height="612" alt="Screenshot 2026-02-12 at 11  47@2x"
src="https://github.com/user-attachments/assets/d49319b5-9c19-435a-b5c7-424060fa0629"
/>

- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- N/A

Release Notes:

- Fixed an issue where a request could fail if an MCP server with names
containing whitespace was used

## Summary

When multiple MCP servers expose tools with the same name, Zed
disambiguates them by prefixing the tool name with the server ID from
settings.json. If the server ID contains spaces or special characters
(e.g., `"Azure DevOps"`), the resulting tool name like `Azure
DevOps_echo` violates Anthropic's API pattern `^[a-zA-Z0-9_-]{1,128}$`,
causing API errors:

> "Received an error from the Anthropic API: tools.0.custom.name: String
should match pattern '^[a-zA-Z0-9_-]{1,128}$'"

## Solution

Convert server IDs to snake_case (using the `heck` crate already
available in the workspace) before using them as prefixes during tool
name disambiguation.

| Server ID in settings.json | Disambiguated Tool Name |
|---------------------------|------------------------|
| `"Azure DevOps"` | `azure_dev_ops_echo` |
| `"My MCP Server"` | `my_mcp_server_echo` |

## Test plan

- [x] Added test case for server name with spaces ("Azure DevOps") in
`test_mcp_tool_truncation`
- [x] Verified existing tests pass
- [x] Manually tested with two MCP servers having overlapping tool names

After (left), Before (right):

<img width="2880" height="1800" alt="Screenshot_20251228_163249"
src="https://github.com/user-attachments/assets/09c4e8f0-e282-4620-9db3-3e2c7d428d15"
/>


🤖 Generated with (some) help from [Claude
Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>

Release Notes:

- Added `allow_extended_context` to the Bedrock settings which enables
1M context windows on models that support it

---------

Co-authored-by: Ona <no-reply@ona.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>

Normalize handling of empty tool call arguments across all LLM
providers. Many providers return empty strings for tool calls with no
arguments, which would previously fail JSON parsing.

- Created shared parse_tool_arguments() helper in provider/util.rs that
treats empty strings as empty JSON objects ({})
- Refactored 10 occurrences across 9 provider files to use the helper
- Ensures consistent behavior across all providers (anthropic, bedrock,
copilot_chat, deepseek, lmstudio, mistral, open_ai, open_router)

Closes: #48955

Release Notes:

- Fixed tool calls with no arguments failing when using certain LLM
providers

Closes #37525

By default, thread summary uses default_fast_model (if set), otherwise
default_model, which resolves to openrouter/auto for openrouter
provider. This may cause the summary to be generated by a different
model than the one used by the agent, potentially leading — in cases
such as Claude Opus 4.5 — to summary costs exceeding main agent
execution costs.
The current logic in registry.rs prioritizes default_fast_model over
default_model, which overrides the user-selected model (assigned only to
default_model). Setting default_fast_model = None for the OpenRouter
provider preserves the fallback to openrouter/auto when no model is
chosen, while respecting the user's explicit model selection when one is
provided.

```rust
    pub fn set_default_model(&mut self, model: Option<ConfiguredModel>, cx: &mut Context<Self>) {
        match (self.default_model.as_ref(), model.as_ref()) {
            (Some(old), Some(new)) if old.is_same_as(new) => {}
            (None, None) => {}
            _ => cx.emit(Event::DefaultModelChanged),
        }
        self.default_fast_model = maybe!({
            let provider = &model.as_ref()?.provider;
            let fast_model = provider.default_fast_model(cx)?;
            Some(ConfiguredModel {
                provider: provider.clone(),
                model: fast_model,
            })
        }); // This sets default fast model (in our case openrouter/auto)
        self.default_model = model;  //This sets default_model to user selected model
    }
```

And latter on :
```rust
    pub fn thread_summary_model(&self) -> Option<ConfiguredModel> {
        #[cfg(debug_assertions)]
        if std::env::var("ZED_SIMULATE_NO_LLM_PROVIDER").is_ok() {
            return None;
        }

        self.thread_summary_model
            .clone()
            .or_else(|| self.default_fast_model.clone()) // We pick fast_model over default model here
            .or_else(|| self.default_model.clone())
    }
```
Which results in user choice being ignored.

Proposed behavior:

Use the model explicitly selected by the user in Zed agent
configuration.
If no model is specified, fall back to the configured default.

The resolution is to set in :  provider/open_router.rs
```rust
fn default_fast_model(&self, _cx: &App) -> Option<Arc<dyn LanguageModel>> {
     None
}
```
This will have a consequence of default_fast_model not being provided
and falling back to user choice - but once the fast model is set via for
example a configuration property - the default_fast_model is picked over
default_model

Release Notes:

- open_router: Use user's default model when comments and thread summary

Closes #47404

Release Notes:

- Fixed MCP tool results not displaying after restarting Zed

Previously, when an MCP server returned a tool response with
`is_error: true`, the error content was incorrectly treated as
a successful result. This could mislead the LLM into thinking
the tool call succeeded when it actually failed.

Now we check the `is_error` flag and propagate the error message
properly, allowing the agent to handle failures appropriately.

Release Notes:

- N/A

---------

Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>

Small thing here, but there's no actual link back to the ruby-lsp docs,
like there is for other languages or ruby LSPs (like solargraph). This
should help users find the correct docs for configuring.

Release Notes:

- N/A