[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 6 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 ↗

3 Comments

MilkyWay008 · 1 month ago

The draft-07 vs 2020-12 $schema error is the MCP client's Ajv validator getting stricter in the new build, not your config...... so re-adding the filesystem server isn't going to fix it, that's why it keeps failing the same way. The thin stdio proxy you wrote that rewrites $schema is honestly the cleanest workaround until @modelcontextprotocol/client beta.4 gets patched, I'd stick with that for now. Oh also, btw, I built a portable Hermes OTG and keep it on a USB stick as my rescue agent, super handy for poking at half-broken installs like this, check it, imo it'll help you. https://github.com/MilkyWay008/Hermes-OTG

brunotorresdigital · 1 month ago

Confirming this on a second, unrelated MCP server, with a new data point: on the same day, the same schemas pass in one bundled client and fail in the other — direct evidence this splits by client build, not by anything in the schemas themselves.

Upstream status changed

This issue cites modelcontextprotocol/typescript-sdk#2532 as still open. It was closed as completed on 2026-08-19: fixed in modelcontextprotocol/typescript-sdk#2534, merged 2026-07-27 and released in @modelcontextprotocol/client@2.0.0. Both default validators now dispatch on the declared dialect — declared draft-07/06 compiles with classic Ajv, 2020-12 stays the default when $schema is absent, and only genuinely unknown dialects still throw.

The closing note asks anyone still hitting it on client@2.0.0 or later to open a new issue. Test below shows that's exactly what's going on here: two different bundled copies of the client, two different outcomes.

Split confirmed: Claude Code's client accepts draft-07, the desktop app's client (serving Chat and Cowork) still rejects it

Both rows below hit the same n8n MCP server (/mcp-server/http), on the same day (2026-08-20), with the same unmodified schemas — 33 tools, 66 schema declarations, every one stamping "$schema": "http://json-schema.org/draft-07/schema#" on both inputSchema and outputSchema.

| Client | Config | Result |
|---|---|---|
| Claude Code's bundled client | .mcp.json, raw mcp-remote, no proxy | ✅ registers cleanly, search_workflows returns real data (92 workflows) |
| Desktop app's bundled client — serves both the Chat UI and Cowork (exposed there via the mcp__remote-devices__<server>__* bridge) | claude_desktop_config.json → mcpServers, raw mcp-remote, no proxy | ❌ fails at registration with this issue's exact error |

The failing case's literal error, from a Cowork (cloud) session calling through the bridge:

Tool 'search_workflows' 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 AjvJs

get_sdk_reference — a static reference lookup that never contacts the n8n instance — fails identically, isolating the failure to client-side registration, independent of server, credentials, or network.

Reverting that same desktop-app config entry to the workaround below (same server, same schemas, only the proxy layer added) registers all 33 tools cleanly. That rules out anything server- or credential-specific and leaves the client build as the only variable.

This is the cleanest evidence I have that the remaining gap is a client-bundling lag, not a validator regression: identical schemas, same day, two different bundled copies of @modelcontextprotocol/client in the same desktop install, two different outcomes. Claude Code appears to already ship ≥2.0.0; the desktop app's own client (which Chat and Cowork both sit behind) does not yet.

The declared dialect is the only incompatibility

Inspecting those same schemas for constructs that actually differ between draft-07 and 2020-12:

3 $ref, all plain JSON Pointers into #/properties/... — none resolve through definitions
exclusiveMinimum present 10 times, all in the numeric (draft-06+) form, identical in both dialects
no dependencies, no $defs

So the schema bodies are already valid under 2020-12. Only the $schema string causes the rejection — which matches this issue's finding that a server declaring only inputSchema works fine in the same session.

Independent confirmation of the workaround

A stdio proxy arrived at independently before finding this report, now in daily use on the surfaces that still need it (Chat, Cowork). A ~100-line wrapper that spawns mcp-remote, passes stdin through untouched, and deletes $schema from each tool's inputSchema/outputSchema in tools/list responses restores all 33 tools, with real tools/call succeeding. Deleting the key is enough; rewriting it to the 2020-12 URI is not required. On Claude Code itself the proxy has since become unnecessary (see the table above), so it's now scoped to only the surfaces that still need it.

Three operational details that made this expensive to diagnose — the first matches a note already in this report:

MCP servers register at session start, so a config change appears to do nothing until a brand-new session is opened. A first test with the working folder connected after session start produced a false negative.
On the desktop app, claude_desktop_config.json is read at launch and held in memory, and any preference change writes that in-memory copy back over the file. An edit made while the app is running is therefore ignored and silently erased later — in my case restoring an inline credential I had just moved out of it. Quitting the app completely before editing is what finally made a config change take effect.
Cowork sessions do not read a project-level .mcp.json. They consume the app's local MCP servers through the desktop bridge — the tools surface as mcp__remote-devices__<server>__* in a cloud session — so whatever claude_desktop_config.json points at is what both Chat and Cowork inherit, for better or worse.

---
_Investigation, measurements and draft produced in a Claude Code session; reviewed and posted by me._

Loosp258 · 1 month ago

Confirming this is still present in Claude Desktop 1.52386.6.0. I inspected the bundled app.asar / .vite/build/mcp-runtime/directMcpHost.js; the Desktop runtime still contains the pre-#2534 validator behavior that rejects declared draft-07 schemas.
Comparing it against the published MCP client builds and upstream history, the relevant client/validator path is runtime-equivalent to the beta.5-era implementation and predates f130e1a / #2534. So the bundling lag described above appears to still be present in 1.52386.6.0.

Showing cached comments. Read the full discussion on GitHub ↗