docs: MCP auth extensions frozen at stable 2026-07-28 (target these, not draft); Desktop plugin OAuth MCP needs managedMcpServers mirror for Cowork/Chat

content/claude/third-party/claude-desktop/chat.md

@@ -25,6 +25,7 @@ Chat conversations run against your configured inference provider, and their his
 | Project folders | For a conversation inside a project, read-only access to folders added to the project in Claude Desktop. Claude can list and read files in them. See [Project folders in Chat](#project-folders-in-chat). |
 | Scratch directory | A per-conversation working directory where Claude can create and edit files (documents, data files, HTML artifacts) and offer them to the user for download or preview. |
 | Managed MCP servers | The servers you provision via [`managedMcpServers`](https://claude.com/docs/third-party/claude-desktop/configuration#managedmcpservers) are available in Chat with the same approval model as Cowork sessions: a tool's `toolPolicy` of `"allow"` pre-approves it, `"blocked"` blocks it, and `"ask"` requires user approval on every call. A tool with no policy asks the user, who can allow it once or grant standing approval, as in Cowork. |
+| Remote MCP servers in plugins | In a conversation that loads the plugin, Claude can use a remote MCP server that a marketplace plugin or a user-added plugin bundles if the server needs no sign-in, but not if it requires OAuth sign-in. To make a server that requires OAuth sign-in available in Chat, see [Remote MCP servers in plugins](https://claude.com/docs/third-party/claude-desktop/extensions.md#remote-mcp-servers-in-plugins). To limit these servers, see [Controlling user extensions](https://claude.com/docs/third-party/claude-desktop/extensions.md#controlling-user-extensions). |
 | Clarifying questions | Claude can present multiple-choice questions to the user (the `AskUserQuestion` tool). |
 | Plugin skills and hooks | Skills from the plugins you provision through [organization plugins](https://claude.com/docs/third-party/claude-desktop/extensions.md#organization-plugins-admin) or [plugin marketplaces](https://claude.com/docs/third-party/claude-desktop/extensions.md#plugin-marketplaces-admin) are available in Chat, including as slash commands. Hooks from those plugins also run in Chat conversations as they do in Cowork sessions, as described under [Plugin hooks](https://claude.com/docs/third-party/claude-desktop/extensions.md#plugin-hooks). Plugin sub-agents do not run in Chat, and a skill that runs scripts needs [advanced file analysis](#advanced-file-analysis). Plugin skills require Claude Desktop 1.44121.4 or later, and plugin hooks run in Chat on Claude Desktop 1.52386.0 or later. |
 | Code execution | Off by default. When you enable [advanced file analysis](#advanced-file-analysis), Claude can additionally run code in a local sandbox against attached files and, inside a project, files in the project's folders. See [Sandbox network access](#sandbox-network-access). |

content/claude/third-party/claude-desktop/code.md

@@ -186,4 +186,6 @@ A Code session can run its Claude Code engine on a remote host over SSH while th
 
 To turn off Code, set `isClaudeCodeForDesktopEnabled` to `false` in your Claude Desktop on 3P configuration. Users can no longer open Code. Cowork is unaffected, and so is [Chat](https://claude.com/docs/third-party/claude-desktop/chat.md#configuration) if you have enabled it.
 
+With Code off, Claude can't use a remote MCP server that requires OAuth sign-in if a marketplace plugin or a user-added plugin bundles it. With Code on, Claude can use such a server in local Code sessions that load the plugin, once the user has signed in, but still not in Cowork sessions or Chat conversations. To make it available in Cowork sessions and Chat conversations, with Code on or off, add a `managedMcpServers` entry with the same `url`, as described under [Remote MCP servers in plugins](https://claude.com/docs/third-party/claude-desktop/extensions.md#remote-mcp-servers-in-plugins).
+
 If you set `desktopHome` to `off`, keep Code on. For what `desktopHome` does, see [Unified Claude](https://claude.com/docs/third-party/claude-desktop/unified-claude.md).

content/claude/third-party/claude-desktop/extensions.md

@@ -406,6 +406,19 @@ To roll out a new version of a plugin:
 
 To withdraw a plugin, remove its folder from `org-plugins/`. On Claude Desktop 1.46388.1 or later, each user's installed copy is unregistered the next time the app syncs organization plugins (at launch or when a session starts); earlier versions leave the copy installed.
 
+## Remote MCP servers in plugins
+
+A plugin can declare remote MCP servers in its `.mcp.json` file. Claude Desktop connects to the servers in [`managedMcpServers`](#managed-mcp-servers-admin) and to the servers of plugins in the [`org-plugins/` directory](#organization-plugins-admin). For a plugin from one of your [marketplaces](#plugin-marketplaces-admin), or a plugin that a user added, a session that loads the plugin connects to the plugin's servers when the session starts:
+
+* **If the server needs no sign-in**: Claude can use it in the Cowork sessions, Chat conversations, and Code sessions that load the plugin
+* **If the server requires OAuth sign-in**: Claude can use it in local Code sessions that load the plugin, once the user has signed in, but not in Cowork sessions or Chat conversations
+
+To make a plugin's server that requires OAuth sign-in available in Cowork sessions and Chat conversations, add a [`managedMcpServers`](#managed-mcp-servers-admin) entry with a `transport`, the same `url` as the plugin's server, and [OAuth sign-in](#oauth-sign-in) set up. Claude Desktop then connects to the server through your entry. Each user clicks **Connect** next to your entry's name under **Customize > Connectors** and signs in, whether [Code is on or off](https://claude.com/docs/third-party/claude-desktop/code.md#disabling-code). After that, Claude can use the server in Cowork sessions, Chat conversations, and Code sessions.
+
+Without a `managedMcpServers` entry for the server, users sign in to it from **Code**, and the sign-in applies to local Code sessions. In **Code**, the user starts a local session that loads the plugin, goes to **Customize > Plugins**, selects the plugin, selects the server on the **Connectors** tab, clicks **Connect**, and completes the sign-in in the browser. With Code on, while no local Code session that loads the plugin is running, the **Connect** button is unavailable, and its tooltip reads "Open a Code session that loads this connector, then try again". With Code turned off, users can't sign in this way, so Claude can't use the server.
+
+To limit plugin-bundled servers, see [Controlling user extensions](#controlling-user-extensions).
+
 ## Plugin hooks
 
 [Hooks](https://code.claude.com/docs/en/hooks) bundled in a plugin, under `hooks/` or declared in its manifest, run wherever the plugin itself loads:
@@ -449,7 +462,7 @@ Unless restricted by an admin, end users can add their own extensions through th
 * **Skills:** create and upload their own [skills](https://claude.com/docs/skills/overview.md), including by asking Claude to save one in a conversation
 * **Local MCP servers:** add local MCP server processes from **Settings → Developer**
 
-End users cannot add remote MCP servers from the app's settings or install desktop extension files (`.mcpb`) themselves. Remote servers come from admin-provisioned `managedMcpServers`, from organization plugins, and from other plugins that bundle them, including plugins users install. A Code session can also load the servers a user defines in Claude Code's own configuration (`~/.claude.json`, a project's `.mcp.json`, or `claude mcp add`). To limit plugin-bundled servers, see [Controlling user extensions](#controlling-user-extensions). To limit the servers a Code session loads, see [Applied as managed policy](https://claude.com/docs/third-party/claude-desktop/code.md#applied-as-managed-policy).
+End users cannot add remote MCP servers from the app's settings or install desktop extension files (`.mcpb`) themselves. Remote servers come from admin-provisioned `managedMcpServers`, from organization plugins, and from other plugins that bundle them, including plugins users install. If a marketplace plugin or a user-added plugin bundles a remote MCP server that requires OAuth sign-in, Claude can't use that server in Cowork sessions or Chat conversations. To make it available there, add a `managedMcpServers` entry with the same `url`, as described under [Remote MCP servers in plugins](#remote-mcp-servers-in-plugins). A Code session can also load the servers a user defines in Claude Code's own configuration (`~/.claude.json`, a project's `.mcp.json`, or `claude mcp add`). To limit plugin-bundled servers, see [Controlling user extensions](#controlling-user-extensions). To limit the servers a Code session loads, see [Applied as managed policy](https://claude.com/docs/third-party/claude-desktop/code.md#applied-as-managed-policy).
 
 User-added extensions are stored in the user's [local data directory](https://claude.com/docs/third-party/claude-desktop/data-storage.md) and apply only to that device.
 

content/mcp/community/working-groups/filesystems.md

@@ -12,49 +12,66 @@
 
 ## Mission Statement
 
-The Filesystems Working Group exists to make MCP Resources bidirectional, so that an agent can write a result back to
-the server it reads its inputs from. Agent platforms are converging on presenting services to models as filesystems, and
-Resources already addresses content by URI under a [`file://` scheme the specification defines as identifying "resources
-that behave like a filesystem"](https://modelcontextprotocol.io/specification/draft/server/resources#common-uri-schemes). Currently, Resources carries
-that surface in the read direction. The WG will produce a single Extensions Track SEP covering write operations,
-optimistic concurrency control, and the interaction with change notification and caching.
+The Filesystems Working Group exists to align MCP Resources with general filesystem semantics, so that MCP clients have
+one interface for discovering, retrieving and modifying filesystem-shaped resources across sources, and can do so
+efficiently. Agent platforms are converging on presenting services to models as filesystems, and Resources already
+addresses content by URI under a [`file://` scheme the specification defines as identifying "resources that behave like
+a filesystem"](https://modelcontextprotocol.io/specification/draft/server/resources#common-uri-schemes). The WG will determine which filesystem
+semantics fit MCP and produce one or more Extensions Track SEPs that apply those semantics consistently to Resources.
 
 ## Scope
 
 ### In Scope
 
-* **Specification Work**: One Extensions Track SEP, provisionally titled Filesystem Operations for Resources, covering:
-  1. **Operations.** Define create, update, delete, and a metadata read (`stat`) that answers existence, size and
-     last-modified for one URI without fetching the body.
-  2. **Optimistic concurrency control.** Specify how two writers avoid a lost update, and how a client creates a
+* **Specification Work**: One or more Extensions Track SEPs defining resource operations, covering:
+  1. **Scoped listing and directory traversal.** Investigate hierarchy-aware listing scoped to a URI, including an
+     operation that enumerates one level below a URI, analogous to `readdir`, traversal of a whole subtree, and how
+     both relate to the existing flat `resources/list` operation.
+  2. **Server-side search.** Investigate search and glob matching evaluated by the server, so a client can find content
+     without listing and reading every resource. This goes beyond resource templates, which describe the URIs a server
+     accepts. Together with scoped listing and traversal, this covers how a client discovers content on a server.
+  3. **Read semantics.** Investigate which filesystem read semantics fit MCP, including bulk reads of several URIs in
+     one request and whether the protocol can support a `seek` operation.
+  4. **Write and metadata operations.** Define create, update, delete, and a metadata read (`stat`) that answers
+     existence, size and last-modified for one URI without fetching the body.
+  5. **Optimistic concurrency control.** Specify how two writers avoid a lost update, and how a client creates a
      resource under a create-if-absent precondition.
-  3. **Change notification and caching.** Specify how a write interacts with `notifications/resources/updated`, the
-     time-to-live and cache scope fields `ttlMs` and `cacheScope`, and the `lastModified` annotation.
+  6. **Typed errors.** Define errors for resource operations, e.g. not found, already exists, precondition failed and
+     permission denied, so a client handles a failure the same way across servers. Currently, a missing resource
+     returns the generic `-32602` (Invalid Params).
+  7. **Change notification and caching.** Specify how filesystem operations interact with
+     `notifications/resources/updated`, the time-to-live and cache scope fields `ttlMs` and `cacheScope`, and the
+     `lastModified` annotation.
 * **Cross-Cutting Concerns**: Reconcile the proposals that extend this primitive into one coherent design.
   [SEP-2571, Resource Submission for Agent Coordination](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2571)
   proposes `resources/create` and `resources/delete`.
   [SEP-2532, Resource Streaming for Binary Content Delivery](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2532)
   proposes `resources/stream`.
   [SEP-1708, MCP Client-Brokered Filesystem Access](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1708)
   proposed a `files/*` method family standing beside Resources, and closed on 23 January 2026.
-* **Documentation**: Document the new operations in the specification, and give server authors guidance on choosing
-  between a resource write path and a tool-based one.
+* **Documentation**: Document the adopted filesystem semantics in the specification, and give server authors guidance
+  on choosing between a resource operation and a tool-based one.
 
 ### Out of Scope
 
 * A parallel `files/*` primitive standing beside Resources. The WG broadens the existing Resources primitive.
+* A complete mapping of POSIX or another operating system's filesystem API. The WG will select the semantics that fit a
+  client-server protocol and document the rationale for any exclusions.
 * Host-side sandbox and local-disk semantics. The WG standardizes the client and server wire format. How a host
   materializes resources into a filesystem for the model stays a host concern.
-* Authorization policy for writes, beyond stating where the existing MCP authorization specification applies.
+* Authorization policy for filesystem operations, beyond stating where the existing MCP authorization specification
+  applies.
 
 ### Related Groups
 
-* **File Uploads WG.** Both groups transfer content to a server. Coordination needed on where an upload-oriented flow
-  ends and a resource write operation begins.
+* **File Uploads WG.** Both groups transfer content to a server. Coordination is needed on where an upload-oriented flow
+  ends and a resource write operation begins. Discovery, search, metadata and small inline writes do not depend on
+  large-content transfer, and can progress independently of it. Tools already return resource links, so the groups
+  should also agree on whether a tool input that takes a file can take a reference to a Resource.
 * **[Skills Over MCP WG](https://modelcontextprotocol.io/community/working-groups/skills-over-mcp.md).** The published
   [Skills extension](https://modelcontextprotocol.io/extensions/skills/overview.md) uses Resources for file reads and defines optional directory reading.
   It does not depend on filesystem write operations; coordinate on future resource operations that affect skills.
-* **Agents IG.** Multi-agent and job orchestration systems are the motivating consumers of a shared write path.
+* **Agents IG.** Multi-agent and job orchestration systems are the motivating consumers of shared filesystem semantics.
 
 ## Leadership
 
@@ -106,16 +123,19 @@ The group's first act is to take up SEP-2571 with its author, since it already c
 
 ### Success Criteria
 
-* An accepted Extensions Track SEP covering create, update, delete and `stat`, with a defined optimistic concurrency
-  control mechanism and a specified interaction with `notifications/resources/updated`, `ttlMs`, `cacheScope` and
-  `lastModified`.
+* One or more accepted Extensions Track SEPs defining scoped listing and directory traversal, server-side search, and
+  the supported read, write and metadata semantics, including bulk reads. The accepted work must record the WG's
+  conclusion on `seek`, define an optimistic concurrency control mechanism and a set of typed errors, and specify the
+  interaction with `notifications/resources/updated`, `ttlMs`, `cacheScope` and `lastModified`.
 * Each proposal in this space resolved. SEP-2571 and SEP-2532 are open at time of writing, and each should end up folded
   in, superseded, or explicitly scoped out.
 * Reference implementations in at least two Tier 1 SDKs.
-* Two independent server implementations exercising the write path against a common client.
+* Two independent server implementations exercising the adopted filesystem operations against a common client.
 
 ## Changelog
 
 | Date | Change |
 | - | - |
+| 2026-10-27 | Add search, bulk reads and typed errors to resource scope |
+| 2026-09-10 | Broaden scope to filesystem semantics |
 | 2026-08-24 | Initial charter |