[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Bug report: Cowork cloud session cannot reach a healthy local filesystem MCP server
Summary

A locally-configured MCP server (@modelcontextprotocol/server-filesystem, launched via npx from the user's claude_desktop_config.json) is confirmed healthy and responsive at all times tonight via its own logs, yet Cowork cloud sessions on the same device (p1-mark, Windows 10/11, Claude Desktop v1.30096.0, Electron 42.7.0, Node 24.18.0) cannot reach its tools. Two independent sessions reproduced the same failure within minutes of each other, against a server the Local MCP Servers settings screen reports as "running."

Environment
Claude Desktop app version: 1.30096.0 (Electron 42.7.0, Node 24.18.0)
OS: Windows 10/11, x64
MCP server: filesystem, command npx -y @modelcontextprotocol/server-filesystem[@2025.7.1] <12 allowed directories>
Config file: user's claude_desktop_config.json (mcpServers.filesystem), confirmed syntactically valid and unchanged in structure throughout
Symptom timeline (all times UTC, from device log clipboard_dump.txt, ~10,000 lines, Apr 3 2026 – Aug 13 2026)
Apr 3 2026 (and every session sampled through Aug 13, until tonight): Server starts cleanly, tools/list returns full tool set. Every tool's outputSchema carries an explicit "$schema":"http://json-schema.org/draft-07/schema#" stamp — this has been present for months and is not new.
2026-08-13T00:08–02:35Z: ~20 successful tools/call invocations (real file reads/writes) in a working session, each returning a clean result(1 blocks). Confirms the server and this exact config were fully functional earlier today.
2026-08-13T21:16:09Z: A cloud session calls tools/list; local log shows a clean result at .601s. From the Cowork session side, however, calling list_directory/search_files on this server produced a client-side validation failure: 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 This is a client-side error (Ajv validator config), not anything the local server logged or could see.
2026-08-13T21:48:24Z and 21:54:25Z: Two full app restarts (one after pinning the server to @2025.7.1, one via the user's own clean-restart script). Both times: local log shows Initializing server... → Server started and connected successfully → clean initialize and tools/list round-trips, zero errors. From both this Cowork session and a second, independent Cowork session on the same device, the filesystem server's tools were not present at all in tool discovery after these restarts (not erroring — simply absent, a different symptom from step 3).
Local MCP Servers settings screen (Settings → Developer → Local MCP servers) shows filesystem status as "running" throughout, with the correct pinned command/arguments visible.
Two distinct failure modes observed, same root cause
Mode A (early): Server tools ARE discovered by the cloud session, but a tool call's response is rejected client-side because its declared outputSchema.$schema is JSON Schema draft-07 and the session's Ajv instance is configured for 2020-12 only, with no fallback/tolerance.
Mode B (later, after restarts): Server tools are not discovered by the cloud session at all, despite the local process being alive, healthy, and responding correctly to tools/list on its own stdio transport (confirmed in local logs).

Both modes are inconsistent with the local server's own logs, which show zero errors and successful responses throughout. This strongly indicates the defect is in the relay/proxy layer between the Claude Desktop app's locally-running MCP server process and the Cowork cloud session (the mechanism that exposes it as mcp__remote-devices__filesystem__* tools to the cloud session) — not in the server, not in the npm package version, and not in the user's configuration.

What was ruled out
npm package version: Confirmed the outputSchema draft-07 stamp has been present since at least April 2026 (many working sessions in between). Pinning to @2025.7.1 did not change behavior (Mode B still occurred immediately after). The pin is very likely unnecessary and should be reverted.
User's config file: Verified byte-for-byte correct both before and after edits; mcpServers.filesystem args list is well-formed and unchanged apart from the (likely unnecessary) version pin.
Stale process / app state: Ruled out via the app's own clean-restart script (used twice) — same symptom recurred immediately after a verified-clean server start each time.
Device-level device_request_folder_access bridge: A separate, unrelated mechanism also tested during this session; it independently exhibited its own timing bug (dialog shown to the user, but the tool call resolves as "rejected" before the user can respond, and the grant never registers in connectedFolders). Reported here for completeness since it surfaced in the same troubleshooting session, but it is very likely a distinct defect from the filesystem server relay issue above.
Suggested areas to investigate on Anthropic's side
The Cowork↔local-MCP-server proxy's tool-discovery/result validation path: confirm whether it tolerates (or should tolerate) outputSchema/inputSchema declared under JSON Schema draft-07, given this is common in real-world MCP servers (including Anthropic's own reference @modelcontextprotocol/server-filesystem).
Why a tools/list call that the local server logs as successfully answered does not result in those tools becoming callable from the cloud session (Mode B) — this looks like a session-to-relay handoff/caching bug rather than a schema-validation rejection, since no error surfaced at all in Mode B.
The device_request_folder_access dialog/grant flow: confirm whether tool-call resolution is supposed to wait for the user's on-device response, since observed behavior was an immediate "rejected" result with no correlation to actual user action.
Supporting evidence available
Full local MCP server log (clipboard_dump.txt, ~10,000 lines, Apr 3 – Aug 13 2026) covering the full timeline above, obtained directly from the user via the app's Local MCP Servers → View Logs → copy-to-clipboard feature.
Screenshot of Settings → Developer → Local MCP servers showing filesystem status "running" with pinned command/arguments, taken during the incident.
Screenshot from a second, independent Cowork session on the same device reproducing Mode B minutes after this session did.

What Should Happen?

Not applicable

Error Messages/Logs

Not applicable

Steps to Reproduce

Not applicable

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.30096.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_