[BUG] Windows MSIX 1.32352.1.0: local filesystem MCP server unusable in Cowork sessions - draft-07 outputSchema rejected, and no server version passes both checks

Status Open

Maintainer reply None cached

Activity 2 comments · opened Aug 18, 2026

<html>
<body>
<html><head></head><body><h2>Summary</h2>
<p>After a <strong>silent MSIX auto-update to Claude Desktop 1.32352.1.0</strong>, the local <code>filesystem</code> MCP server can no longer be used by <strong>Cowork/Code sessions</strong>, which spawn their own copy of the server. The client rejects the server at registration because its schemas declare JSON Schema draft-07.</p>
<p>Critically, <strong>no version of <code>@modelcontextprotocol/server-filesystem</code> works</strong>: recent versions are rejected for their draft-07 <code>outputSchema</code>, and older versions are rejected because their <code>inputSchema</code> lacks <code>type: "object"</code>. The two defects swap places in the same release, so downgrading is not a workaround.</p>
<p>This appears to be the Cowork-proxy variant of the regression cluster reported in #80094, #79986 and anthropics/claude-ai-mcp#664, with the added data point of an <strong>exact install timestamp correlated with the moment of breakage</strong>.</p>
<h2>Environment</h2>

|
-- | --
Claude Desktop | 1.32352.1.0 (MSIX, Claude_1.32352.1.0_x64__pzs8sxrjxfjjc)
OS | Windows x64
Surface | Cowork session (remote container reaching the local MCP server through the desktop bridge)
MCP server | @modelcontextprotocol/server-filesystem, launched via npx

<p>The <code>inputSchema</code> fix and the <code>outputSchema</code> introduction landed in the <strong>same release</strong> (2025.11.25). There is no version in between to pin.</p>
<h2>This violates the spec the client implements</h2>
<p><a href="https://modelcontextprotocol.io/seps/1613-establish-json-schema-2020-12-as-default-dialect-f">SEP-1613</a> (status: <strong>Final</strong>) establishes 2020-12 as the <em>default</em> dialect, but explicitly states that schemas <strong>MAY</strong> declare a different dialect via <code>$schema</code>, and that clients <strong>MUST</strong> "validate schemas according to declared or default dialect".</p>
<p>Rejecting a schema <em>because</em> it declares draft-07 is therefore non-conformant. The underlying SDK bug is tracked in <a href="https://github.com/modelcontextprotocol/typescript-sdk/issues/2532">modelcontextprotocol/typescript-sdk#2532</a> — classified as a regression introduced in <code>@modelcontextprotocol/client@2.0.0-beta.4</code>, still open. As that issue notes, <code>zod-to-json-schema</code> stamps draft-07 on every schema produced by v1-era servers, so there is <strong>no server-side remedy</strong>.</p>
<h2>Reproduction</h2>
<ol>
<li>Configure a local MCP server: command <code>npx</code>, args <code>-y @modelcontextprotocol/server-filesystem@2026.1.14 <some folder></code>.</li>
<li>Confirm it works from a normal chat session (it does — the chat path does not apply this validation).</li>
<li>Open a Cowork session and call any filesystem tool.</li>
<li>Observe the <code>unsupported dialect</code> error; no request ever reaches the server process.</li>
<li>Re-pin to <code>@2025.8.21</code> and restart: the server now fails to register at all with the <code>inputSchema</code> error.</li>
</ol>
<h2>Workaround</h2>
<p>A thin stdio proxy that spawns the real server, passes everything through unchanged, and rewrites only the <code>$schema</code> field of <code>outputSchema</code> to <code>https://json-schema.org/draft/2020-12/schema</code> in the <code>tools/list</code> response. Verified end-to-end: 14 tools exposed, valid <code>inputSchema</code>, accepted dialect, real <code>tools/call</code> succeeding.</p>
<p>This matches the finding in #80094 that a custom server declaring only <code>inputSchema</code> works fine in the same session — the schemas themselves are not the problem, only the declared dialect is.</p>
<h2>Expected behavior</h2>
<p>The client should accept schemas that explicitly declare draft-07, as SEP-1613 requires — for example by dispatching to a validator matching the declared <code>$schema</code> instead of assuming 2020-12.</p>
<p>Secondarily: a schema-validation failure should not be reported to users as <em>"Couldn't start this server"</em>, and internal validator instructions (<code>pass a pre-configured Ajv instance</code>) should not appear in user-facing error text.</p>
<h2>Additional notes</h2>
<ul>
<li>The bridge enumerates local MCP servers <strong>at session start</strong> and does not re-register them live: after any connector change, a brand-new Cowork session is required to see the effect. This makes the failure considerably harder to diagnose.</li>
<li>Because updates arrive through MSIX in the background, there is no visible signal connecting the breakage to an app update. The only reliable check is <code>(Get-Item "<InstallLocation>").CreationTime</code>.</li>
</ul>
<h2>Related</h2>
<ul>
<li>#80094 — macOS, filesystem MCP unusable in both package generations</li>
<li>#79986 — Windows MSIX 1.24012.1, <code>tools/call</code> never sent</li>
<li>#25081 — client drops all tools when server includes <code>outputSchema</code></li>
<li>anthropics/claude-ai-mcp#664 — tool calls never reach filesystem servers</li>
<li>modelcontextprotocol/typescript-sdk#2532 — root cause in the default validator</li>
</ul></body></html>
</body>
</html>## Summary

After a silent MSIX auto-update to Claude Desktop 1.32352.1.0, the local filesystem MCP server can no longer be used by Cowork/Code sessions, which spawn their own copy of the server. The client rejects the server at registration because its schemas declare JSON Schema draft-07.

Critically, no version of @modelcontextprotocol/server-filesystem works: recent versions are rejected for their draft-07 outputSchema, and older versions are rejected because their inputSchema lacks type: "object". The two defects swap places in the same release, so downgrading is not a workaround.

This appears to be the Cowork-proxy variant of the regression cluster reported in #80094, #79986 and anthropics/claude-ai-mcp#664, with the added data point of an exact install timestamp correlated with the moment of breakage.

Environment

| | |
|---|---|
| Claude Desktop | 1.32352.1.0 (MSIX, Claude_1.32352.1.0_x64__pzs8sxrjxfjjc) |
| OS | Windows x64 |
| Surface | Cowork session (remote container reaching the local MCP server through the desktop bridge) |
| MCP server | @modelcontextprotocol/server-filesystem, launched via npx |

Timeline (exact)

| Time (2026-08-18, local) | Event |
|---|---|
| before ~09:59 | Local filesystem connector working normally from Cowork sessions, config without a version pin |
| 09:59:29 | Claude 1.32352.1.0 installed — (Get-Item <InstallLocation>).CreationTime. Silent MSIX background update, no prompt, no notification |
| 10:15:47 | %LOCALAPPDATA%\Claude-Data created (first launch of the new build) |
| after | Connector no longer usable from Cowork sessions |

No configuration was changed by the user between the working and broken states. Every other Claude installation directory on the machine dates from March–May 2026; only these two artifacts are from this morning.

Errors observed

With any version ≥ 2025.11.25 (tools appear, then every call fails):

Tool 'list_directory' has an invalid outputSchema: JSON Schema declares an unsupported
dialect ("$schema": "http://json-schema.org/draft-07/schema#"). The default validator
supports JSON Schema 2020-12 only; pass a pre-configured Ajv instance to Ajv...

With any version ≤ 2025.8.21 (server fails to register at all):

MCP filesystem: Couldn't start this server for Cowork and Code sessions (they run their
own copy of it), so they can't use its tools: Invalid result for tools/list:
[ { "code": "invalid_value", "values": [ "object" ],
    "path": [ "tools", 0, "inputSchema", "type" ],
    "message": "Invalid input: expected \"object\"" }, ... ]

Note the leaked internal validator message (pass a pre-configured Ajv instance) — this surfaces AjvJsonSchemaValidator from the TypeScript SDK directly to the end user.

Version matrix — no version passes both checks

Measured by launching each version and inspecting its tools/list response over raw stdio:

| version | tools | inputSchema missing type: "object" | outputSchema |
|---|---|---|---|
| 2025.7.1 | 12 | 11 of 12 | none |
| 2025.7.29 | 14 | 13 of 14 | none |
| 2025.8.18 | 14 | 13 of 14 | none |
| 2025.8.21 | 14 | 13 of 14 | none |
| 2025.11.25 | 14 | 0 | 14, draft-07 |
| 2025.12.18 | 14 | 0 | 14, draft-07 |
| 2026.1.14 | 14 | 0 | 14, draft-07 |
| 2026.7.10 | 14 | 0 | 14, draft-07 |

The inputSchema fix and the outputSchema introduction landed in the same release (2025.11.25). There is no version in between to pin.

This violates the spec the client implements

[SEP-1613](https://modelcontextprotocol.io/seps/1613-establish-json-schema-2020-12-as-default-dialect-f) (status: Final) establishes 2020-12 as the default dialect, but explicitly states that schemas MAY declare a different dialect via $schema, and that clients MUST "validate schemas according to declared or default dialect".

Rejecting a schema because it declares draft-07 is therefore non-conformant. The underlying SDK bug is tracked in [modelcontextprotocol/typescript-sdk#2532](https://github.com/modelcontextprotocol/typescript-sdk/issues/2532) — classified as a regression introduced in @modelcontextprotocol/client@2.0.0-beta.4, still open. As that issue notes, zod-to-json-schema stamps draft-07 on every schema produced by v1-era servers, so there is no server-side remedy.

Reproduction

Configure a local MCP server: command npx, args -y @modelcontextprotocol/server-filesystem@2026.1.14 <some folder>.
Confirm it works from a normal chat session (it does — the chat path does not apply this validation).
Open a Cowork session and call any filesystem tool.
Observe the unsupported dialect error; no request ever reaches the server process.
Re-pin to @2025.8.21 and restart: the server now fails to register at all with the inputSchema error.

Workaround

A thin stdio proxy that spawns the real server, passes everything through unchanged, and rewrites only the $schema field of outputSchema to https://json-schema.org/draft/2020-12/schema in the tools/list response. Verified end-to-end: 14 tools exposed, valid inputSchema, accepted dialect, real tools/call succeeding.

This matches the finding in #80094 that a custom server declaring only inputSchema works fine in the same session — the schemas themselves are not the problem, only the declared dialect is.

Expected behavior

The client should accept schemas that explicitly declare draft-07, as SEP-1613 requires — for example by dispatching to a validator matching the declared $schema instead of assuming 2020-12.

Secondarily: a schema-validation failure should not be reported to users as "Couldn't start this server", and internal validator instructions (pass a pre-configured Ajv instance) should not appear in user-facing error text.

Additional notes

The bridge enumerates local MCP servers at session start and does not re-register them live: after any connector change, a brand-new Cowork session is required to see the effect. This makes the failure considerably harder to diagnose.
Because updates arrive through MSIX in the background, there is no visible signal connecting the breakage to an app update. The only reliable check is (Get-Item "<InstallLocation>").CreationTime.

#80094 — macOS, filesystem MCP unusable in both package generations
#79986 — Windows MSIX 1.24012.1, tools/call never sent
#25081 — client drops all tools when server includes outputSchema
anthropics/claude-ai-mcp#664 — tool calls never reach filesystem servers
modelcontextprotocol/typescript-sdk#2532 — root cause in the default validator

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗