Previously we had `Context` and `ContextStore` in both `agent_ui` (used
to store context for the inline assistant) and `assistant_context` (used
for text threads) which is confusing.
This PR makes it so that the `assistant_context` concepts are now called
`TextThread*`, the crate was renamed to `assistant_text_thread`
Release Notes:
- N/A
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
Fixes ZED-1NX
This panic could occur when an `bulk_staging` was set to `Some(...)` and
`sort_by_path` was set to `true`.
When setting `sort_by_path: true`, we call `update_visible_entries(...)`
which then checks if `bulk_staging ` is `Some(...)` and calls
`entry_by_path`. That function accesses `entries`, which still consists
of both headers and entries. But the code
(`entry.status_entry().unwrap()`) assumes that there are no headers in
the entry list if `sort_by_path: true`.
```rust
if GitPanelSettings::get_global(cx).sort_by_path {
return self
.entries
.binary_search_by(|entry| entry.status_entry().unwrap().repo_path.cmp(path)) //This unwrap() would panic
.ok();
}
```
This has now been fixed by clearing all the entries when `sort_by_path`
changes, as this is the only case where our assumptions are invalid. I
also added a test which 1) actually tests the sort_by_path logic 2)
ensures that we do not re-introduce this panic in the future.
Release Notes:
- Fixed a panic that could occur when using `sort_by_path: true` in the
git panel
We've seen this panic come up in the last two weeks, which might be
caused by #33592. However, we are not sure what paths can cause this
`unwrap()` to fail. Therefore adding some logging around this, so that
the next time someone opens a bug report we can further diagnose the
issue.
Fixes ZED-1F6
Release Notes:
- Fixed an issue where Zed could crash when including specific paths in
a global `.gitignore` files
This removes the `gemini-and-native` and `claude-code` feature flags.
Also, I removed a bunch of unused agent1 code that we do not need
anymore.
Initially I wanted to remove much more of the `agent` code, but noticed
some things that we need to figure out first:
- The inline assistant + context strip use `Thread`/`ContextStore`
directly
- We need some replacement for `ToolWorkingSet`, so we can access
available tools (as well as context server tools) in other places, e.g.
the agent configuration and the configure profile modal
Release Notes:
- N/A
Previously we would still show a completion menu even when the user
typed an unrecognised mode with an argument,
e.g. `@something word`.
This PR ensures that we only show the completion menu, when the part
after the `@` is a known mode (e.g. `file`/`symbol`/`rule`/...)
Release Notes:
- Fix an issue where completions for `@mentions` in the agent panel
would sometimes not be dismissed when typing a space
TODO:
- [x] Double-check if we like the naming of the new actions
- [x] Only show keybinding hint once per option (e.g. if there are two
`allow_once` buttons only show it on the first one)
- [x] If there are multiple tool calls that need authorisation, only
show keybindings on the first tool call
- [x] Figure out which keybindings to use
- [x] Add linux keybindings
- [x] Add windows keybindings
- [x] Bug: long keybindings can make the buttons overflow
Release Notes:
- Add keybindings for authorizing tool calls (`agent: Allow once`,
`agent: Allow always`, `agent: Reject once`) in the agent panel
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
### First issue
In the scenario where you have an API key configured in Zed and you run
`/logout`, clicking on `Use Anthropic API Key` would show `Method not
implemented`.
This happened because we were only intercepting the `Use Anthropic API
Key` click if the provider was NOT authenticated, which would not be the
case when the user has an API key set.
### Second issue
When clicking on `Reset API Key` the modal would be dismissed even
though you picked no Authentication Method (which means you still would
be unauthenticated)
---
This PR fixes both of these issues
Release Notes:
- N/A
TODO
- [x] OpenAI Compatible API Icon
- [x] Docs
- [x] Link to docs in OpenAI provider section about configuring OpenAI
API compatible providers
Closes#33992
Related to #30010
Release Notes:
- agent: Add support for adding multiple OpenAI API compatible providers
---------
Co-authored-by: MrSubidubi <dev@bahn.sh>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Release Notes:
- agent: Fixed an issue where clicking on "Start New Thread" in the
agent configuration would not always switch to the correct
provider/model
This introduces a new field `thinking_allowed` on `LanguageModelRequest`
which lets us control whether thinking should be enabled if the model
supports it.
We permit thinking in the Inline Assistant, Edit File tool and the Git
Commit message generator, this should make generation faster when using
a thinking model, e.g. `claude-sonnet-4-thinking`
Release Notes:
- N/A
Closes#33894
After #33635 Gemini Integration was broken because we now produce
`const` fields for enums, which are not supported.
Changing this to `openapi3` fixes the issue.
Release Notes:
- Fixed an issue where Gemini Models would not work because of
incompatible tool schemas
Closes#33792
Follow up to #33237 - Turns out my fix for this was not correct
Release Notes:
- agent: Fixed an issue where tools would not work when two MCP servers
provided a tool with the same name
This reverts some parts of #33372, as it will break the settings for
users running stable and preview at the same time. We can add it back
once the changes make it to stable.
Release Notes:
- N/A
As we are in the process of improving our Onboarding UX for Zed AI, I
added component previews for the Zed AI Configuration section. This
should make it easier to inspect the different states we can run into.
<img width="1198" alt="image"
src="https://github.com/user-attachments/assets/eb774f27-9091-450d-bfae-c688d533c25e"
/>
Release Notes:
- N/A
Previously we would always run `maintain_servers` even if the settings
did not change. While this would not cause any MCP servers to restart,
we would still go through all configured servers and call the
`command(...)` function on each installed MCP extension. This can cause
lots of logs to show up when an MCP server is not configured correctly.
Release Notes:
- N/A
Seeing this come up in our server logs when sending requests to
Anthropic: `final assistant content cannot end with trailing
whitespace`.
Release Notes:
- agent: Fixed an issue where Anthropic requests would sometimes fail
because of malformed assistant messages
This cleans up our settings to not include any `version` fields, as we
have an actual settings migrator now.
This PR removes `language_models > anthropic > version`,
`language_models > openai > version` and `agent > version`.
We had migration paths in the code for a long time, so in practice
almost everyone should be using the latest version of these settings.
Release Notes:
- Remove `version` fields in settings for `agent`, `language_models >
anthropic`, `language_models > openai`. Your settings will automatically
be migrated. If you're running into issues with this open an issue
[here](https://github.com/zed-industries/zed/issues)
Follow up to previous PRs:
- Return `true` in `supports_images` - v0 supports images already
- Rename model id to match the exact version of the model `v0-1.5-md`
(For now we do not expose `sm`/`lg` variants since they seem not to be
available via the API)
- Provide autocompletion in settings for using `vercel` as a `provider`
Release Notes:
- N/A
cc @osyvokon
We were seeing a bunch of errors in our backend when people were using
Claude models with thinking enabled.
In the logs we would see
> an error occurred while interacting with the Anthropic API:
invalid_request_error: messages.x.content.0.type: Expected `thinking` or
`redacted_thinking`, but found `text`. When `thinking` is enabled, a
final `assistant` message must start with a thinking block (preceeding
the lastmost set of `tool_use` and `tool_result` blocks). We recommend
you include thinking blocks from previous turns. To avoid this
requirement, disable `thinking`. Please consult our documentation at
https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking
However, this issue did not occur frequently and was not easily
reproducible. Turns out it was triggered by us not correctly handling
[Redacted Thinking
Blocks](https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking#thinking-redaction).
I could constantly reproduce this issue by including this magic string:
`ANTHROPIC_MAGIC_STRING_TRIGGER_REDACTED_THINKING_46C9A13E193C177646C7398A98432ECCCE4C1253D5E2D82641AC0E52CC2876CB
` in the request, which forces `claude-3-7-sonnet` to emit redacted
thinking blocks (confusingly the magic string does not seem to be
working for `claude-sonnet-4`). As soon as we hit a tool call Anthropic
would return an error.
Thanks to @osyvokon for pointing me in the right direction 😄!
Release Notes:
- agent: Fixed an issue where Anthropic models would sometimes return an
error when thinking was enabled
Closes#31903
Release Notes:
- agent: Fix an issue where an error would occur when MCP servers
specified tools with the same name
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
- [x] Show disabled MCP servers in the list so you can enable them again
- [x] If MCP is not present in the settings, add it
Closes #ISSUE
Release Notes:
- agent: Allow to enable/disable context servers permanently in the
agent configuration view
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Ran into this while adding support for Vercel v0s models:
- The timestamp seems to be returned in Milliseconds instead of seconds
so it breaks the bounds of `created: u32`. We did not use this field
anywhere so just decided to remove it
- Sometimes the `choices` field can be empty when the last chunk comes
in because it only contains `usage`
Release Notes:
- N/A
Related to #32888, but will not fix the issue.
Turns out these assertions are wrong (Not sure if they were correct at
some point).
I tested with this code:
```
request = LanguageModelRequest {
messages: vec![
LanguageModelRequestMessage {
role: Role::User,
content: vec![MessageContent::Text("Give me 10 jokes".to_string())],
cache: false,
},
LanguageModelRequestMessage {
role: Role::Assistant,
content: vec![MessageContent::Text("Sure, here are 10 jokes:".to_string())],
cache: false,
},
],
..request
};
```
The API happily accepted this and Claude proceeded to tell me 10 jokes.
Release Notes:
- N/A
Bennet Fenner
