[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 #87633

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   area:mcp

   area:cowork

   platform:windowsIssue specifically occurs on WindowsIssue specifically occurs on Windows

   on Aug 18, 2026
2. MilkyWay008 commented on Aug 18, 2026

   

   MilkyWay008

   on Aug 18, 2026

   More actions

   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
3. brunotorresdigital commented on Aug 20, 2026

   

   brunotorresdigital

   on Aug 20, 2026

   More actions

   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.
4. Loosp258 commented on Sep 14, 2026

   

   Loosp258

   on Sep 14, 2026

   More actions

   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.
5. usethedata commented on Sep 18, 2026

   

   usethedata

   on Sep 18, 2026

   More actions

   I confirm that this issue is still present in Claude Desktop for Mac version 2.2553.1 (c38127) 2026-09-18T00:41:58.000Z
6. KDiamantidis commented on Sep 23, 2026

   

   KDiamantidis

   on Sep 23, 2026

   More actions

   Confirming this on Windows desktop app 2.7032.0 — still fully reproducible.

   Environment

   • Platform: Windows (win32/x64)
   • Claude desktop app: 2.7032.0
   • Electron 44.4.3, Node 24.21.0
   • Session type: Cowork session on a linked device

   Config (claude_desktop_config.json, paths redacted):

   {
     "mcpServers": {
       "my-vault": {
         "command": "npx.cmd",
         "args": [
           "-y",
           "@modelcontextprotocol/server-filesystem",
           "C:/Users/<user>/<some-folder>"
         ]
       }
     }
   }

   No version pinned, so npx resolves to the current published version.

   Behaviour
   The server starts and reports healthy — the host reports the server in announced state, and all 14 tools appear in the tool list. But every tool call fails client-side before dispatch with a byte-identical error. Verified on 5 different tools:

   • list_allowed_directories
   • list_directory
   • get_file_info
   • search_files
   • read_text_file

   Error: 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 AjvJs
   

   Tried, no effect

   • npx clear-npx-cache followed by a full app restart (not just closing the window) — the error afterwards was identical, ruling out a stale cached package.

   Possibly useful signal
   In the same session, the same directory is fully readable through the device file tools — a full recursive listing of the folder works without any issue. So the filesystem access itself, the path grant, and the folder connection are all fine; the failure is isolated to the MCP tool-schema validation layer.

   Workaround confirmed working
   The thin stdio proxy approach described above does resolve it. I wrapped the server in a ~100-line Node proxy that forwards everything verbatim except tools/list responses, where it deletes the $schema key from each tool's input/output schema (letting the client fall back to its 2020-12 default). It also sets type: "object" on schemas that have properties but no type, which covers the other half of the version trap described in this issue.

   Before the proxy: 28 draft-07 $schema occurrences in tools/list, every call rejected.
   After: 0 occurrences, all 14 tools accepted, and real tools/call operations return correct results.

   Also worth flagging
   #86142 was closed as non-reproducing after testing on Claude Code CLI (Linux), which uses the v1 validator that accepts draft-07. That path doesn't exercise the v2 desktop validator where this actually occurs, so the closure doesn't reflect the desktop behaviour reported here.
7. usethedata commented on Oct 6, 2026

   

   usethedata

   on Oct 6, 2026

   More actions

   MCP is working for me now in Claude Desktop for Mac version Claude 2.19675.1 (861368) 2026-10-05T16:14:31.000Z.
8. localden

   marked [BUG] Filesystem MCP server (remote-devices) fails all tool calls: outputSchema declares unsupported draft-07 dialect #88988 as a duplicate of this issue on Oct 11, 2026