Closes#43162
Implements the OAuth 2.0 Authorization Code + PKCE authentication flow
for remote MCP servers using Streamable HTTP transport, as specified by
the [MCP auth
specification](https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization).
Previously, connecting to a remote MCP server that required OAuth would
silently fail with a timeout — the server's 401 response was never
handled. Now, Zed detects the 401, performs OAuth discovery, and guides
the user through browser-based authentication.
Step-up authentication and pre-registered clients are not in scope for
this PR, but will be done as follow-ups.
## Overview
- **401 detection** — When the HTTP transport receives a 401 during
server startup, it surfaces a typed `TransportError::AuthRequired` with
parsed `WWW-Authenticate` header info.
- **OAuth discovery** — Protected Resource Metadata (RFC 9728) and
Authorization Server Metadata (RFC 8414) are fetched to locate the
authorization and token endpoints.
- **Client registration** — Zed first tries CIMD (Client ID Metadata
Document) hosted at `zed.dev`. If the server doesn't support CIMD, falls
back to Dynamic Client Registration (DCR).
- **Browser flow** — A loopback HTTP callback server starts on a
preferred fixed port (27523, listed in the CIMD), the user's browser
opens to the authorization URL, and Zed waits for the callback with the
authorization code.
- **Token exchange & persistence** — The code is exchanged for
access/refresh tokens using PKCE. The session is persisted in the system
keychain so subsequent startups restore it without another browser flow.
- **Automatic refresh** — The HTTP transport transparently refreshes
expired tokens using the refresh token, and persists the updated session
to the keychain.
## UI changes
- Servers requiring auth show a warning indicator with an
**"Authenticate"** button
- During auth, a spinner and **"Waiting for authorization..."** message
are shown
- A **"Log Out"** option is available in the server settings menu for
OAuth-authenticated servers
- The configure server modal handles the auth flow inline when
configuring a new server that needs authentication.
Release Notes:
- Added OAuth authentication support for remote MCP servers. Servers
requiring OAuth now show an "Authenticate" button when they need you to
log in. You will be redirected in your browser to the authorization
server of the MCP server to go through the authorization flow.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
## Summary
This PR extends the `always_allow` tool permission patterns to work with
Nushell, Elvish, and Rc shells. Previously, these shells were
incorrectly excluded because they don't use `&&`/`||` operators for
command chaining. However, brush-parser can safely parse their command
syntax since they all use `;` for sequential execution.
## Changes
- Add `ShellKind::Nushell`, `ShellKind::Elvish`, and `ShellKind::Rc` to
`supports_posix_chaining()`
- Split `ShellKind::Unknown` into `ShellKind::UnknownWindows` and
`ShellKind::UnknownUnix` to preserve platform-specific fallback behavior
while still denying `always_allow` patterns for unrecognized shells
- Add comprehensive tests for the new shell support
- Clarify documentation about shell compatibility
## Shell Notes
- **Nushell**: Uses `;` for sequential execution. The `and`/`or`
keywords are boolean operators on values, not command chaining.
- **Elvish**: Uses `;` to separate pipelines. Does not have `&&` or `||`
operators. Its `and`/`or` are special commands operating on values.
- **Rc (Plan 9)**: Uses `;` for sequential execution and `|` for piping.
Does not have `&&`/`||` operators.
## Security
Unknown shells still return `false` from `supports_posix_chaining()`, so
`always_allow` patterns are denied for safety when we can't verify the
shell's syntax.
(No release notes because granular tool permissions are still
feature-flagged.)
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
### Closes
- Maybe https://github.com/zed-industries/zed/issues/38252 (there might
be something going on with NPX too)
- Also addresses
https://github.com/zed-industries/zed/pull/39021#issuecomment-3644818347
### Why
Some more involved MCP servers timeout often, especially on first setup.
I got tired of having to set timeouts manually per server. I also
noticed a timeout could not be set for http context servers, which
causes Context7 or GitHub's remote servers to timeout at 60s sometimes.
### Overview
MCP Timeout Configuration Feature
This PR adds additional configurable timeout settings for Model Context
Protocol servers including a global timeout and the addition of timeouts
for http servers, addressing issues where servers were timing out after
a fixed 60 seconds regardless of user needs.
**Key Features:**
- **Global timeout setting** (`context_server_timeout`) - default
timeout for all MCP servers (default: 60s, max: 10min)
- **Per-server timeout overrides** - individual servers can specify
custom timeouts via `timeout` field
- **Precedence hierarchy** - per-server timeout > global timeout >
default (60s)
- **Automatic bounds checking** - enforces 10-minute maximum to prevent
resource exhaustion
- **Support for both transports** - works with stdio and HTTP-based
context servers
- **Comprehensive test coverage** - 3 new tests validating global,
override, and stdio timeout behavior
- **Full backward compatibility** - existing configurations work
unchanged with sensible defaults
### Release Notes:
- Added the ability to configure timeouts for context server tool calls.
The new global `context_server_timeout` setting controls the default
timeout (default is 60s, max: 10min). Additionally, per-server timeouts
can be configured using the `timeout` field within servers defined in
the `"context_servers" setting
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes#45211
This ensures that all sub-processes that were launched by the ACP server
are terminated. One scenario where this is easily reproducible:
- Start a new Claude Code ACP session
- Submit a prompt
- While Claude-code is still responding, start a new session
- The `claude-code` subprocess is leaked from the previous session (The
Claude-code SDK runs the Claude-code binary in a sub process)
This PR fixes this by using process groups on Unix.
It does not fix the process leaks on Windows yet (will follow up with
another PR)
Release Notes:
- Fixed an issue where subprocesses of ACP servers could be leaked after
starting a new session
## Summary
This PR adds support for the MCP (Model Context Protocol)
`notifications/tools/list_changed` notification, enabling dynamic tool
discovery when MCP servers add, remove, or modify their available tools
at runtime.
## Release Notes:
- Improved: MCP tools are now automatically reloaded when a context
server sends a `tools/list_changed` notification, eliminating the need
to restart the server to discover new tools.
## Changes
- Register a notification handler for `notifications/tools/list_changed`
in `ContextServerRegistry`
- Automatically reload tools when the notification is received
- Handler is registered both on initial server startup and when a server
transitions to `Running` status
## Motivation
The MCP specification includes a `notifications/tools/list_changed`
notification to inform clients when the list of available tools has
changed. Previously, Zed's agent would only load tools once when a
context server started. This meant that:
1. If an MCP server dynamically registered new tools after
initialization, they would not be available to the agent
2. The only way to refresh tools was to restart the entire context
server
3. Tools that were removed or modified would remain in the old state
until restart
## Implementation Details
The implementation follows these steps:
1. When a context server transitions to `Running` status, register a
notification handler for `notifications/tools/list_changed`
2. The handler captures a weak reference to the `ContextServerRegistry`
entity
3. When the notification is received, spawn a task that calls
`reload_tools_for_server` with the server ID
4. The existing `reload_tools_for_server` method handles fetching the
updated tool list and notifying observers
This approach is minimal and reuses existing tool-loading
infrastructure.
## Testing
- [x] Code compiles with `./script/clippy -p agent`
- The notification handler infrastructure already exists and is tested
in the codebase
- The `reload_tools_for_server` method is already tested and working
## Benefits
- Improves developer experience by enabling hot-reloading of MCP tools
- Aligns with the MCP specification's capability negotiation system
- No breaking changes to existing functionality
- Enables more flexible and dynamic MCP server implementations
## Related Issues
This implements part of the MCP specification that was already defined
in the type system but not wired up to actually handle the
notifications.
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Fixes#43165
## Problem
MCP prompts were only available in text threads, not agent threads.
Users with MCP servers that expose prompts couldn't use them in the main
agent panel.
## Solution
Added MCP prompt support to agent threads by:
- Creating `ContextServerPromptRegistry` to track MCP prompts from
context servers
- Subscribing to context server events to reload prompts when MCP
servers start/stop
- Converting MCP prompts to available commands that appear in the slash
command menu
- Integrating prompt expansion into the agent message flow
## Testing
Tested with a custom MCP server exposing `explain-code` and
`write-tests` prompts. Prompts now appear in the `/` slash command menu
in agent threads.
Release Notes:
- Added MCP prompt support to agent threads. Prompts from MCP servers
now appear in the slash command menu when typing `/` in agent threads.
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
### Summary:
- Ensure the external agents with ACP servers start via non-interactive
shells to prevent shell startup noise from corrupting JSON-RPC.
- Apply the same tweak to MCP stdio transports so remote context servers
aren’t affected by prompts or greetings.
### Description:
Switch both ACP and MCP stdio launch paths to call
`ShellBuilder::non_interactive()` before building the command. This
removes `-i` on POSIX shells, suppressing prompt/title sequences that
previously prefixed the first JSON line and caused `serde_json` parse
failures. No functional regressions are expected: both code paths only
need a shell for Windows/npm script compatibility, not for
interactivity.
Release Notes:
- Fixed external agents that hung on “Loading…” when shell startup
output broke JSON-RPC initialization.
`npx`, and any `npm install`-ed programs, exist as batch
scripts/PowerShell scripts on the PATH. We have to use a shell to launch
these programs.
Fixes https://github.com/zed-industries/zed/issues/41435
Closes https://github.com/zed-industries/zed/pull/42651
Release Notes:
- windows: Custom MCP and ACP servers installed through `npm` now launch
correctly.
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
### 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>
We've been considering removing workspace-hack for a couple reasons:
- Lukas ran into a situation where its build script seemed to be causing
spurious rebuilds. This seems more likely to be a cargo bug than an
issue with workspace-hack itself (given that it has an empty build
script), but we don't necessarily want to take the time to hunt that
down right now.
- Marshall mentioned hakari interacts poorly with automated crate
updates (in our case provided by rennovate) because you'd need to have
`cargo hakari generate && cargo hakari manage-deps` after their changes
and we prefer to not have actions that make commits.
Currently removing workspace-hack causes our workspace to grow from
~1700 to ~2000 crates being built (depending on platform), which is
mainly a problem when you're building the whole workspace or running
tests across the the normal and remote binaries (which is where
feature-unification nets us the most sharing). It doesn't impact
incremental times noticeably when you're just iterating on `-p zed`, and
we'll hopefully get these savings back in the future when
rust-lang/cargo#14774 (which re-implements the functionality of hakari)
is finished.
Release Notes:
- N/A
Prior we only logged the crate in `log_err`, which is not too helpful.
We now assemble the module path from the file system path.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
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>
serde 1.0.221 introduced serde_core into the build graph, which should
render explicitly depending on serde_derive for faster build times an
obsolote method.
Besides, I'm not even sure if that worked for us. My hunch is that at
least one of our deps would have `serde` with derive feature enabled..
and then, most of the crates using `serde_derive` explicitly were also
depending on gpui, which depended on `serde`.. thus, we wouldn't have
gained anything from explicit dep on `serde_derive`
Release Notes:
- N/A
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>
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
- Return unified diff from `Edit` tool so model can see the final state
- Format on save if enabled
- Provide `Write` tool
- Disable `MultiEdit` tool
- Better prompting
Release Notes:
- N/A
This fixes an issue where we were not setting the context server working
directory at all.
Release Notes:
- Context servers will now be spawned in the currently active project
root.
---------
Co-authored-by: Danilo Leal <danilo@zed.dev>
This will prepare us for running the protocol over MCP
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
This changes the context server crate so that the input/output for a
request are encoded at the type level, similar to how it is done for LSP
requests.
This also makes it easier to write tests that mock context servers, e.g.
you can write something like this now when using the `test-support`
feature of the `context-server` crate:
```rust
create_fake_transport("mcp-1", cx.background_executor())
.on_request::<context_server::types::request::PromptsList>(|_params| {
PromptsListResponse {
prompts: vec![/* some prompts */],
..
}
})
```
Release Notes:
- N/A
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
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
This PR implements the `ToolCard` for the edit file tool, which allow us
to display an editor with a diff in the thread view with the changes
performed by the model.
- [x] Fix buffer sometimes displaying empty
- [x] Stop buffer from scrolling together with the thread
- [x] Fix multibuffer header sometimes appearing
- [x] Fix buffer height issue
- [x] Implement "full height" expand button
- [x] Add "Jump To File" functionality
- [x] Polish and refine styles
Release Notes:
- agent: Added diff preview cards in the thread view for edits performed
by the agent.
---------
Co-authored-by: João Marcos <marcospb19@hotmail.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This is just a refactor which adds no functionality.
We now return a `ToolResult` from `Tool > run(...)`. For now this just
wraps the output task in a struct. We'll use this to implement custom
rendering of tools, see #28621.
Release Notes:
- N/A
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.
To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.
Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)
One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.
TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
