[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 applicableSteps 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_
3 Comments
Update / correction to the original report
After more investigation (including switching networks, a full reboot, and testing in a brand-new session), I believe the original framing of this report — "a healthy local filesystem MCP server that a Cowork cloud session should be able to reach via a relay, but can't due to a bug" — is likely the wrong diagnosis, at least for the largest part of what was observed. Correcting it here rather than leaving a misleading report open.
What actually seems to be going on
Cowork changed its default execution mode from local (task runs on the user's own machine) to cloud (task runs on Anthropic's infrastructure) on 2026-07-07, rolled out gradually over the following weeks, via the "Run new tasks in the cloud" setting in Settings → Cowork — which ships enabled by default. This was not clearly surfaced to existing users at the time of rollout. (Source: independent report, not an official Anthropic post — https://www.systemsofthought.com/silent-default-switch-a-concern-for-teams-researchers-and-practitioners-using-claude-cowork/ — flagging that I can't verify this against an official Anthropic changelog entry, but it matches everything observed below.)
Critically: local MCP servers do not run in remote/cloud Cowork sessions at all — this isn't a relay that's supposed to connect a cloud session to a locally-running MCP server and is currently broken; it's out of scope by design. My filesystem server (@modelcontextprotocol/server-filesystem, launched via npx from claude_desktop_config.json) had worked reliably for months, but that was because those sessions were running in local/on-computer mode (the then-default), not because the specific relay path was healthy. Once a task landed in the new cloud default, the local server was never going to be reachable, regardless of npm package version, schema dialect, restarts, reboots, or network path — all of which I spent considerable time ruling out before finding this.
This explains:
Local server logs showing the process healthy and responding correctly at all times, while cloud sessions never saw its tools (expected: cloud sessions don't run it at all).
The version pin (@2025.7.1) making no difference (expected: irrelevant to the actual constraint).
Two independent cloud sessions reproducing the identical failure (expected: same default applies to both).
Network changes (different carrier, hotspot, no ethernet) making no difference (expected: not a network-path issue).
What still looks like a real, separate issue
The device_request_folder_access grant flow (the officially-supported mechanism for a cloud session to read connected folders on a user's machine) did exhibit its own, distinct flakiness independent of the above: repeated calls returned an immediate "user rejected" result with no dialog the user could see or respond to, across multiple sessions, over roughly two hours — before eventually succeeding on retry (in both a brand-new session and, later, in the original session) with no configuration change in between. That inconsistency — silent, unexplained failures for an extended period, then success with no clear trigger — seems worth keeping open as its own, narrower issue, separate from the local-MCP-server question above.
Suggested resolution
The original "healthy local server unreachable via relay" framing can likely be closed or deprioritized — it reflects expected behavior under the current cloud-default architecture, not a defect.
If useful, a real product gap worth considering: local MCP servers configured in claude_desktop_config.json silently doing nothing under the cloud default, with no warning or fallback message to the user, was genuinely confusing and cost significant troubleshooting time. A clear signal (e.g. "N local MCP servers are configured but won't run in this cloud session — switch to on-computer mode to use them") would have saved hours here.
The device_request_folder_access timing/reliability issue (see above) still seems worth tracking separately if it isn't already covered elsewhere.
Apologies for the noise on the original framing — leaving this here for anyone else who hits the same "it worked for months, now it silently doesn't" pattern.
Correction to my own correction above
The device_request_folder_access behavior I described above as "flaky" (repeated instant "rejected" results, then working two hours later "with no configuration change in between") was not a bug. I had it wrong.
The repeated declines were the folder owner deliberately rejecting a broader grant request (the full KeyMan project root) because it would have also exposed an unrelated sensitive config file in that same tree — a reasonable, intentional call, not a stuck dialog or a silent failure. Once a narrower folder was requested (a subdirectory that doesn't include the sensitive file), it was approved and worked immediately.
So: device_request_folder_access was functioning correctly and honoring the user's actual choices the entire time. Retracting that part of my previous comment — there's no separate reliability issue to track here.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.