Follow up to #39021.
<img width="576" height="141" alt="image"
src="https://github.com/user-attachments/assets/c89885a4-e664-4614-9bb0-86442dff34ee"
/>
- Add migration to remove `source` tag because `ContextServerSettings`
is now untagged
- Fix typos in context server modal
- PR seems to have removed the `test_action_namespaces` test, which I
brought back in this PR
Release Notes:
- Fixed an issue where the `source` property of MCP settings would show
up as unrecognised
Closes _unknown_
<img width="1212" height="463" alt="image"
src="https://github.com/user-attachments/assets/ec00fcf0-7eb9-4291-b1e2-66e014dc30ac"
/>
This PR places the file_name before the file_path so that when the panel
is slim it is still usable, mirrors the behaviour of the file picker
(cmd+P)
Release Notes:
- Improved readability of files in the git changes panel
### What this solves
This PR adds support for HTTP and SSE (Server-Sent Events) transports to
Zed's context server implementation, enabling communication with remote
MCP servers. Currently, Zed only supports local MCP servers via stdio
transport. This limitation prevents users from:
- Connecting to cloud-hosted MCP servers
- Using MCP servers running in containers or on remote machines
- Leveraging MCP servers that are designed to work over HTTP/SSE
### Why it's important
The MCP (Model Context Protocol) specification includes HTTP/SSE as
standard transport options, and many MCP server implementations are
being built with these transports in mind. Without this support, Zed
users are limited to a subset of the MCP ecosystem. This is particularly
important for:
- Enterprise users who need to connect to centralized MCP services
- Developers working with MCP servers that require network isolation
- Users wanting to leverage cloud-based context providers (e.g.,
knowledge bases, API integrations)
### Implementation approach
The implementation follows Zed's existing architectural patterns:
- **Transports**: Added `HttpTransport` and `SseTransport` to the
`context_server` crate, built on top of the existing `http_client` crate
- **Async handling**: Uses `gpui::spawn` for network operations instead
of introducing a new Tokio runtime
- **Settings**: Extended `ContextServerSettings` enum with a `Remote`
variant to support URL-based configuration
- **UI**: Updated the agent configuration UI with an "Add Remote Server"
option and dedicated modal for remote server management
### Changes included
- [x] HTTP transport implementation with request/response handling
- [x] SSE transport for server-sent events streaming
- [x] `build_transport` function to construct appropriate transport
based on URL scheme
- [x] Settings system updates to support remote server configuration
- [x] UI updates for adding/editing remote servers
- [x] Unit tests using `FakeHttpClient` for both transports
- [x] Integration tests (WIP)
- [x] Documentation updates (WIP)
### Testing
- Unit tests for both `HttpTransport` and `SseTransport` using mocked
HTTP client
- Manual testing with example MCP servers over HTTP/SSE
- Settings validation and UI interaction testing
### Screenshots/Recordings
[TODO: Add screenshots of the new "Add Remote Server" UI and
configuration modal]
### Example configuration
Users can now configure remote MCP servers in their `settings.json`:
```json
{
"context_servers": {
"my-remote-server": {
"enabled": true,
"url": "http://localhost:3000/mcp"
}
}
}
```
### AI assistance disclosure
I used AI to help with:
- Understanding the MCP protocol specification and how HTTP/SSE
transports should work
- Reviewing Zed's existing patterns for async operations and suggesting
consistent approaches
- Generating boilerplate for test cases
- Debugging SSE streaming issues
All code has been manually reviewed, tested, and adapted to fit Zed's
architecture. The core logic, architectural decisions, and integration
with Zed's systems were done with human understanding of the codebase.
AI was primarily used as a reference tool and for getting unstuck on
specific technical issues.
Release notes:
* You can now configure MCP Servers that connect over HTTP in your
settings file. These are not yet available in the extensions API.
```
{
"context_servers": {
"my-remote-server": {
"enabled": true,
"url": "http://localhost:3000/mcp"
}
}
}
```
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
A small follow-up to the settings refactor of a few weeks ago to move
all the VSCode settings imports
to one place.
This should make it easier to spot missing imports, and easier to test
the importer.
Release Notes:
- N/A
It is now possible to configure logging level of CodeLLDB adapter via
envs specified in project settings like so:
```
{
"dap": {
"CodeLLDB": {
"envs": {
"RUST_LOG": "debug"
}
}
}
}
```
Release Notes:
- N/A
Closes #ISSUE
Annotated our `default.json` with `$schema` to get diagnostics, then
fixed the non-language not installed warnings.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Before this change the active theme and icon theme were retrofitted onto
the ThemeSettings.
Now they're in their own new global (GlobalTheme::theme(cx) and
GlobalTheme::icon_theme(cx))
This lets us remove cx from the settings traits, and tidy up a few other
things along the way.
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/38690Closes#37353
### Background
On Windows, paths are normally separated by `\`, unlike mac and linux
where they are separated by `/`. When editing code in a project that
uses a different path style than your local system (e.g. remoting from
Windows to Linux, using WSL, and collaboration between windows and unix
users), the correct separator for a path may differ from the "native"
separator.
Previously, to work around this, Zed converted paths' separators in
numerous places. This was applied to both absolute and relative paths,
leading to incorrect conversions in some cases.
### Solution
Many code paths in Zed use paths that are *relative* to either a
worktree root or a git repository. This PR introduces a dedicated type
for these paths called `RelPath`, which stores the path in the same way
regardless of host platform, and offers `Path`-like manipulation APIs.
RelPath supports *displaying* the path using either separator, so that
we can display paths in a style that is determined at runtime based on
the current project.
The representation of absolute paths is left untouched, for now.
Absolute paths are different from relative paths because (except in
contexts where we know that the path refers to the local filesystem)
they should generally be treated as opaque strings. Currently we use a
mix of types for these paths (std::path::Path, String, SanitizedPath).
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
In the settings refactor I'd assumed server settings were like project
settings. This is not the case, they are in fact the normal user
settings;
but just read from the server.
Release Notes:
- N/A
When we refactored settings to not pass JSON blobs around, we ended up
needing
to write *a lot* of code that just merged things (like json merge used
to do).
Use a derive macro to prevent typos in this logic.
Release Notes:
- N/A
Co-Authored-By: Ben K <ben@zed.dev>
Co-Authored-By: Anthony <anthony@zed.dev>
Co-Authored-By: Mikayla <mikayla@zed.dev>
Release Notes:
- settings: Major internal changes to settings. The primary user-facing
effect is that some settings which did not make sense in project
settings files are no-longer read from there. (For example the inline
blame settings)
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
This PR separates out the associated constant `KEY` from the `Settings`
trait into a new trait `SettingsKey`. This allows for the key trait to
be derived using attributes to specify the path so that the new
`SettingsUi` derive macro can use the same attributes to determine top
level settings paths thereby removing the need to duplicate the path in
both `Settings::KEY` and `#[settings_ui(path = "...")]`
Co-authored-by: Ben Kunkle <ben@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes: #32668
- Add
[tool_call_timeout_millis](https://github.com/cline/cline/pull/1904)
field to ContextServerCommand, like in Cline
- Update ModelContextServerBinary to include timeout configuration
- Modify Client to store and use configurable request timeout
- Replace hardcoded REQUEST_TIMEOUT with self.request_timeout
- Rename REQUEST_TIMEOUT to DEFAULT_REQUEST_TIMEOUT for clarity
- Maintain backward compatibility with 60-second default
Release Notes:
- context_server: Add support for configurable timeout for MCP tool
calls
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Closes #ISSUE
This PR includes the necessary work to get `EditorSettings` showing up
in the settings UI. Including making the `path` field on
`SettingsUiItem`'s optional so that top level items such as
`EditorSettings` which have `Settings::KEY = None` (i.e. are treated
like `serde(flatten)`) have their paths computed correctly for JSON
reading/updating.
It includes the first examples of a pattern I expect to continue with
the `SettingsUi` work with respect to settings reorganization, that
being adding missing defaults, and adding explicit values (or aliases)
to settings which previously relied on `null` being a value for optional
fields.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
## Goal
This PR creates the initial settings ui structure with the primary goal
of making a settings UI that is
- Comprehensive: All settings are available through the UI
- Correct: Easy to understand the underlying JSON file from the UI
- Intuitive
- Easy to implement per setting so that UI is not a hindrance to future
settings changes
### Structure
The overall structure is settings layer -> data layer -> ui layer.
The settings layer is the pre-existing settings definitions, that
implement the `Settings` trait. The data layer is constructed from
settings primarily through the `SettingsUi` trait, and it's associated
derive macro. The data layer tracks the grouping of the settings, the
json path of the settings, and a data representation of how to render
the controls for the setting in the UI, that is either a marker value
for the component to use (avoiding a dependency on the `ui` crate) or a
custom render function.
Abstracting the data layer from the ui layer allows crates depending on
`settings` to implement their own UI without having to add additional UI
dependencies, thus avoiding circular dependencies. In cases where custom
UI is desired, and a creating a custom render function in the same crate
is infeasible due to circular dependencies, the current solution is to
implement a marker for the component in the `settings` crate, and then
handle the rendering of that component in `settings_ui`.
### Foundation
This PR creates a macro and a trait both called `SettingsUi`. The
`SettingsUi` trait is added as a new trait bound on the `Settings`
trait, this allows the type system to guarantee that all settings
implement UI functionality. The macro is used to derived the trait for
most types, and can be modified through attributes for unique cases as
well.
A derive-macro is used to generate the settings UI trait impl, allowing
it the UI generation to be generated from the static information in our
code base (`default.json`, Struct/Enum names, field names, `serde`
attributes, etc). This allows the UI to be auto-generated for the most
part, and ensures consistency across the UI.
#### Immediate Follow ups
- Add a new `SettingsPath` trait that will be a trait bound on
`SettingsUi` and `Settings`
- This trait will replace the `Settings::key` value to enable
`SettingsUi` to infer the json path of it's derived type
- Figure out how to render `Option<T> where T: SettingsUi` correctly
- Handle `serde` attributes in the `SettingsUi` proc macro to correctly
get json path from a type's field and identity
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Removes `diagnostics.cargo.fetch_cargo_diagnostics` settings as those
are not needed for the flycheck diagnostics to run.
This setting disabled `checkOnSave` in rust-analyzer and allowed to
update diagnostics via flycheck in the project diagnostics editor with
the "refresh" button.
Instead, `"checkOnSave": false,` can be set manually as
https://zed.dev/docs/languages/rust#more-server-configuration example
shows and flycheck commands can be called manually from anywhere,
including the diagnostics panel, to refresh the diagnostics.
Release Notes:
- Removed redundant `diagnostics.cargo.fetch_cargo_diagnostics` settings
- **WIP: reorganize dispositions**
- **Introduce a LocalToolchainStore trait and use it for LspAdapter
methods**
Closes#35782Closes#27331
Release Notes:
- Python: Improved propagation of a selected virtual environment into
the LSP configuration. This should the make all language-related
features such as Go to definition or Find all references more reliable.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Just like with diagnostics, adding a configurable padding to inline
blame
Release Notes:
- Added configurable padding to inline blame
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
This PR adds a `severity` argument so severity can be defined when
navigating through diagnostics. This allows keybinds like the following:
```json
{
"] e": ["editor::GoToDiagnostic", { "severity": "error" }],
"[ e": ["editor::GoToDiagnostic", { "severity": "error" }]
}
```
I've added test comments and a test. Let me know if there's anything
else you need!
Release Notes:
- Add `severity` argument to `editor::GoToDiagnostic`,
`editor::GoToPreviousDiagnostic`, `project_panel::SelectNextDiagnostic`
and `project_panel::SelectPrevDiagnostic` actions
Closes#30017
* While generating the settings JSON schema, defaults all schema
definitions to reject unknown fields via `additionalProperties: false`.
* Uses `unevaluatedProperties: false` at the top level to check fields
that remain after the settings field names + release stage override
field names.
* Changes json schema version from `draft07` to `draft_2019_09` to have
support for `unevaluatedProperties`.
Release Notes:
- Added warnings for unknown fields when editing `settings.json`.
Custom arguments replace any arguments that we normally pass to the DAP.
For interpreted languages, they are passed to the interpreter after the
DAP path or module. They can be combined with a custom binary, or you
can omit `dap.binary` and just customize the arguments to the DAPs we
download.
This doesn't take care of updating the extension API to support custom
arguments.
Release Notes:
- debugger: Implemented support for passing custom arguments to a debug
adapter binary using the `dap.args` setting.
- debugger: Fixed not being able to use the `dap` setting in
`.zed/settings.json`.
- [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>
This changes the way context servers are organised. We now store a
`source` which indicates if the MCP server is configured manually or
managed by an extension.
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Follow-up of https://github.com/zed-industries/zed/pull/19230
* starts to send `result_id` in pull requests to allow servers to reply
with non-full results
* fixes a bug where disk-based diagnostics were offset after pulling the
diagnostics
* fixes a bug due to which pull diagnostics could not be disabled
* uses better names and comments for the workspace pull diagnostics part
Release Notes:
- N/A
Closes [#13107](https://github.com/zed-industries/zed/issues/13107)
Enabled pull diagnostics by default, for the language servers that
declare support in the corresponding capabilities.
```
"diagnostics": {
"lsp_pull_diagnostics_debounce_ms": null
}
```
settings can be used to disable the pulling.
Release Notes:
- Added support for the LSP `textDocument/diagnostic` command.
# Brief
This is draft PR that implements the LSP `textDocument/diagnostic`
command. The goal is to receive your feedback and establish further
steps towards fully implementing this command. I tried to re-use
existing method and structures to ensure:
1. The existing functionality works as before
2. There is no interference between the diagnostics sent by a server and
the diagnostics requested by a client.
The current implementation is done via a new LSP command
`GetDocumentDiagnostics` that is sent when a buffer is saved and when a
buffer is edited. There is a new method called `pull_diagnostic` that is
called for such events. It has debounce to ensure we don't spam a server
with commands every time the buffer is edited. Probably, we don't need
the debounce when the buffer is saved.
All in all, the goal is basically to get your feedback and ensure I am
on the right track. Thanks!
## References
1.
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_pullDiagnostics
## In action
You can clone any Ruby repo since the `ruby-lsp` supports the pull
diagnostics only.
Steps to reproduce:
1. Clone this repo https://github.com/vitallium/stimulus-lsp-error-zed
2. Install Ruby (via `asdf` or `mise).
4. Install Ruby gems via `bundle install`
5. Install Ruby LSP with `gem install ruby-lsp`
6. Check out this PR and build Zed
7. Open any file and start editing to see diagnostics in realtime.
https://github.com/user-attachments/assets/0ef6ec41-e4fa-4539-8f2c-6be0d8be4129
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Follow-up to #30565
This PR fixes the default settings values for the `DiagnosticsSettings`.
The issue here was that due to the `#[derive(Default)]`, `button` would
be false by default, which unintentionally hid the diagnostics button by
default. The `#[serde(default = `default_true`)]` would only apply iff
the diagnostics key was already present in the user's settings. Thus, if
you have
```json
{
"diagnostics": {...}
}
```
in your settings, the button would show (given it was not disabled).
However, if the key was not present, the button was not shown: Due to
the derived default for the entire struct, the value would be false.
This PR fixes this by implementing the default instead and moving the
`#[serde(default)]` up to the level of the struct.
I also did the same for the inline diagnostics settings, which already
had a default impl and thus only needed the serde default on the struct
instead of on all the struct fields.
Lastly, I simplified the title bar settings, since the serde attributes
previously had no effect anyway (deserialization happened in the
`TitlebarSettingsContent`, so these attributes had no effect) and we can
remove the `TitlebarSettingsContent` as well as the attributes if we
implement a proper default implementation instead.
Release Notes:
- Fixed the diagnostics status bar button being hidden by default.
* project search button in the status bar
```jsonc
"search": {
"button": false
},
```
* project diagnostics button in the status bar
```jsonc
"diagnostics": {
"button": false
}
```
* project name and host buttons in the title bar
```jsonc
"title_bar": {
"show_project_items": false
}
```
* git branch button in the title bar
```jsonc
"title_bar": {
"show_branch_name": false
}
```
Before:
<img width="1728" alt="before"
src="https://github.com/user-attachments/assets/4b13b431-3ac1-43b3-8ac7-469e5a9ccf7e"
/>
After:
<img width="1728" alt="after"
src="https://github.com/user-attachments/assets/baf2765a-e27b-47a3-8897-89152b7a7c95"
/>
Release Notes:
- Added more settings to hide buttons from Zed UI
Release Notes:
- Fixed a race condition that sometimes prevented a system-installed
`node` binary from being detected.
- Fixed a bug where the `node.path` setting was not respected when
invoking npm.
* Adds a `diagnostics_max_severity: null` editor settings that has
previous hardcoded default, `warning`
* Make inline diagnostics to inherit this setting by default (can be
overridden with its own max_severity setting)
* Allows to toggle diagnostics in the editor menu and via new action,
`editor::ToggleDiagnostics`
Closes https://github.com/zed-industries/zed/issues/4686
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Because we instantiated `ContextServerManager` both in `agent` and
`assistant-context-editor`, and these two entities track the running MCP
servers separately, we were effectively running every MCP server twice.
This PR moves the `ContextServerManager` into the project crate (now
called `ContextServerStore`). The store can be accessed via a project
instance. This ensures that we only instantiate one `ContextServerStore`
per project.
Also, this PR adds a bunch of tests to ensure that the
`ContextServerStore` behaves correctly (Previously there were none).
Closes#28714Closes#29530
Release Notes:
- N/A
Bennet Bo Fenner
Aaron Saunders
Artur ShirokovandConrad Irwin
Mikayla MakiandNia
Ben KunkleandDanilo
Julia Ryan
Jakub Konka
Anthony Eid
Lukas Wirth
Max BrunsfeldandCole Miller
Lev ZakharovandConrad Irwin
Kirill Bulatov
Rafał KrzyważniaandBen Brandt
Hilmar Wiegand
Michael Sloan
Joseph T. Lyons
Finn Evers