[BUG] Chat mode: MCP tools/call never sent to server (tools/list works), Cowork and Code MCP unaffected

Retrospective note (22/07/2026): A third investigation (below) identifies a specific, reproducible mechanism behind this failure, confirmed through direct client-side inspection rather than inference. See section 13, with the resulting next step in section 17.

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?

Environment:

• Claude Desktop version: 1.24012.1 (0adcae), build timestamp 2026-07-21T20:59:53.000Z
• OS: Windows 11
• Install type: MSIX (Store-installed)
• MCP server affected: @modelcontextprotocol/server-filesystem (official reference server), launched via npx -y, single filesystem entry in claude_desktop_config.json, standard local stdio transport

Summary:

An MCP server connected in Claude Desktop chat mode stops receiving tools/call requests entirely, while remaining fully healthy and responsive to tools/list. Claude reports every invocation attempt as a generic tool execution failure, with no corresponding entry ever appearing in the MCP log. The server itself is confirmed working via direct manual invocation and via successful initialize/tools/list round-trips in the logs.

What's confirmed working (ruled out as causes):

• Server binary/package integrity: running the exact command from the config manually (npx -y @modelcontextprotocol/server-filesystem <dirs>) starts cleanly; "Secure MCP Filesystem Server running on stdio", no errors.
• Config file: valid JSON, correct paths, no syntax issues; confirmed via direct inspection.
• npx cache: not stale/corrupted; manual run above proves current cached install works.
• User PATH: inspected directly ([Environment]::GetEnvironmentVariable("Path","User")); unremarkable, no duplication or truncation relevant to this.
• MSIX config virtualization: checked for a redirected config copy under %LOCALAPPDATA%\Packages\<PackageID>\LocalCache\Roaming\Claude\; not present, so not a stale-virtualized-config issue.
• Legacy-config vs. extension-manager conflict: checked logs for duplicate server launches / UtilityProcess/"not found in installed extensions" signatures (a known pattern in other reports); none present, single clean launch each time.
• Session/chat-level staleness: reproduced identically across multiple fresh chats and multiple full app restarts.
• App cache: used Desktop's built-in "clear cache and restart", no change.

Log evidence (from Developer -> MCP logs):

Every restart from a specific point onward shows the identical pattern - clean init, successful tools/list, and then no tools/call entries at all for the remainder of that session, despite repeated invocation attempts from the chat side:

[filesystem] [info] Initializing server...
[filesystem] [info] Using MCP server command: C:\WINDOWS\System32\cmd.exe with path: {...}
[filesystem] [info] Server started and connected successfully
[filesystem] [info] Message from client: method="initialize" id=0 params {...}
Secure MCP Filesystem Server running on stdio
[filesystem] [info] Message from server: id=0 result {...}
[filesystem] [info] Message from client: method="notifications/initialized" {...}
Client does not support MCP Roots, using allowed directories set from server args: [...]
[filesystem] [info] Message from client: method="tools/list" id=1 params {...}
[filesystem] [info] Message from server: id=1 result {...}
---(no further client messages until next shutdown)---

By contrast, an earlier, working session in the same log shows the expected pattern of repeated tools/call request/result pairs:

[filesystem] [info] Message from client: method="tools/call" id=20 params {...}
[filesystem] [info] Message from server: id=20 result(1 blocks) {...}
[filesystem] [info] Message from client: method="tools/call" id=21 params {...}
[filesystem] [info] Message from server: id=21 result(1 blocks) {...}

Scope: isolated to Chat mode:

Other Desktop subsystems with their own MCP filesystem access are unaffected:

• Cowork successfully reaches its default uploads directory.
• Claude Code (embedded in Desktop) successfully reaches the directory defined in its own settings.

This points specifically to Chat mode's tool-call routing rather than a Desktop-wide MCP failure (the underlying MCP transport/subsystem is clearly functional elsewhere in the same app, at the same time, on the same machine).

Timeline:

• Last confirmed working tools/call: 2026-07-21T16:43:06Z
• First subsequent session (tools/list OK, tools/call absent): 2026-07-21T22:35:29Z
• Symptom persists identically across at least 7 subsequent server restarts and multiple full Claude Desktop restarts, through 2026-07-22T01:50:34Z (time of writing)
• Notable correlation: the currently installed build's compile timestamp (2026-07-21T20:59:53.000Z) falls inside this window. Flagging as a timing correlation, not a confirmed cause; no independent confirmation that this build's install coincided exactly with the break, only that the build itself dates from inside the broken window.

Additional notes:

One unrelated crash appears in the log at 2026-07-22T01:42:29Z ("Server transport closed unexpectedly... process exiting early") — this was a manual Stop-Process kill performed during troubleshooting, not a spontaneous fault, and is not believed to be related to the underlying issue, which predates it by several hours.

What Should Happen?

Expected behavior:

Tools/call requests issued by Claude in a chat session should reach a connected, healthy MCP server, the same way tools/list requests do.

Actual behavior:

Tools/call requests are never transmitted to the server process at all (not sent-and-failed — simply absent from the server-side log), while tools/list continues to succeed. Claude reports a generic execution failure with no further detail exposed to the user.

Error Messages/Logs

Steps to Reproduce

1. Configure a local MCP server (e.g. @modelcontextprotocol/server-filesystem) in claude_desktop_config.json and confirm it connects (Developer settings shows it running, tools/list succeeds).
2. In a Chat mode conversation, ask Claude to use one of the connected tools (e.g. list a directory).
3. Observe: Claude reports a generic tool execution failure, and no corresponding tools/call entry appears in the MCP log for that request, only the earlier tools/list is present.
4. (Not independently reproducible on demand; see Timeline/Scope sections for when this state was first observed and what's been ruled out as a trigger.)

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.217 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

ADDITIONAL INFORMATION

Follow up after further investigation. This supersedes the Timeline section of the original report, corrects one statement in it, adds a timestamped reproduction, and records several lines of investigation that were pursued and ruled out.

No root cause was identified. Everything below is intended to narrow the search and to save anyone else from repeating the dead ends.

1. CLOCK REFERENCE (read this before correlating anything below)

Three log sources are involved and they do not share a clock:

mcp.log UTC, with explicit Z suffixes
main.log local time (BST, UTC+1 on these dates), no suffix
Event Viewer AppXDeploymentServer UTC (SystemTime is stored in UTC natively)

Every timestamp in this comment has been normalised to UTC. Subtract one hour from any raw main.log timestamp before comparing it with the other two sources. The mcp.log timestamps quoted in the original report were separately verified as genuine UTC, not local time mislabelled with a Z.

1. INSTALL BOUNDARY CONFIRMED, WITH FOUR DEPLOYMENTS RATHER THAN ONE

The original report flagged the installed build's compile timestamp as a timing correlation only. That correlation can now be replaced with actual deployment records, taken from AppXDeploymentServer event ID 613:

2026-07-21T21:00:43Z Claude_1.24012.0.0_x64
2026-07-21T22:35:26Z Claude_1.24012.0.0_x64 (same version again)
2026-07-21T23:14:37Z Claude_1.24012.1.0_x64
2026-07-22T00:29:37Z Claude_1.24012.1.0_x64 (same version again)

The version immediately prior was 1.22209.3.0. The second 1.24012.0.0 deployment was the run that finally removed the 1.22209.3.0 package folder, which suggests the first deployment registered without completing cleanup.

1. CORRECTION: THE 22:35:29Z SESSION WAS NOT AN OBSERVED FAILURE

The original report gave 2026-07-21T22:35:29Z as the first session exhibiting the fault. That is inaccurate and should be disregarded.

That entry is an MCP server init produced by the app restarting after the deployment that completed three seconds earlier. No tool invocations were attempted during it, because the machine was unattended. The absence of tools/call entries there is therefore expected rather than diagnostic, and conflates "session in which tools/call was absent" with "session in which tools/call failed".

The corrected sequence:

2026-07-21T16:43:06Z Last confirmed successful tools/call, under 1.22209.3.0
(four deployments, as above)
2026-07-22T00:24Z First confirmed failing invocation, under 1.24012.1.0
2026-07-22T08:37Z Still failing; see the reproduction below

1. ATTRIBUTION LIMIT, STATED DELIBERATELY

Chat mode was not used at all between the last successful tools/call and the first confirmed failure. All four deployments fall inside that gap, so it is not possible to determine from outside the app which build introduced the fault.

What can be stated with confidence:

the last healthy session ran under 1.22209.3.0
every session observed since the 1.24012.x deployments has exhibited the fault
the fault is reproducible in 1.24012.1.0, the current build

The earlier suggestion that this could be pinned to a single build should not be relied on.

1. TIMESTAMPED REPRODUCTION

A session with the failure pinned to a known moment on both sides:

2026-07-22T08:36:46.774Z Server started and connected successfully
2026-07-22T08:36:47.667Z Message from client: method="initialize" id=0
2026-07-22T08:37:27.211Z Message from server: id=0 result
2026-07-22T08:37:27.212Z Message from client: method="notifications/initialized"
2026-07-22T08:37:27.222Z Message from client: method="tools/list" id=1
2026-07-22T08:37:27.231Z Message from server: id=1 result

Two tool invocations were attempted from the chat side immediately after the tools/list round trip completed, at approximately 08:37:27Z. Neither produced a tools/call entry. Both returned a generic execution failure to the user.

1. THE FAILURE PRODUCES NO CLIENT SIDE LOG ENTRY AT ALL

This is the one new positive finding, and it may be the most useful thing here.

%APPDATA%\Claude\logs\main.log was examined across the reproduction above. Converted to UTC, it contains entries at 08:37:17, 08:37:18 and 08:37:24, then nothing until a routine process memory tick at 08:37:39 and an event logging flush at 08:37:49.

The failed invocations occurred at approximately 08:37:27Z, squarely inside that gap. No error, no warning, no exception, no stack trace.

The renderer side logs are not a candidate either: claude.ai-web.log and unknown-window.log had not been written to for several hours at the time of the reproduction, so they do not appear to be recording these sessions at all.

So the call is absent from the server side record and unlogged anywhere client side. That is consistent with a silent early return somewhere in dispatch, before any code that logs or throws is reached, rather than with a caught exception being swallowed and reported generically.

1. LINES OF INVESTIGATION RULED OUT

Duplicate installation or duplicate running instance. WindowsApps redirection to a secondary drive was configured on this machine at some point, and both C: and E: paths for Claude packages appear in the deployment log. This was investigated as a possible cause of two app instances competing over the MCP connection, and ruled out. Get-AppxPackage returns a single registration, 1.24012.1.0; all eleven running processes are under C:\Program Files, which is a normal single Electron process tree. The apparent contradiction between process paths on C: and stack trace paths on E: is explained by C:\Program Files\WindowsApps being a junction to E:\WindowsApps. One installation, two path representations.

Legacy config versus extension manager conflict. The original report ruled this out on the basis of mcp.log. For completeness: main.log does contain the warning "UtilityProcess Check: Extension filesystem not found in installed extensions" at every startup, alongside "Checking 0 extensions via can_install API". This looks like the known signature from other reports, and it is not. The same warning appears in startups from well before the break, in sessions where tools/call subsequently worked normally, so it is ordinary behaviour for a server defined in claude_desktop_config.json rather than installed as an extension. Recorded here explicitly because it is an easy false lead for anyone reading these logs. The server is registered under Developer and shown active under Connectors; no extensions are installed on this machine.

1. MINOR OBSERVATIONS

None of these are advanced as explanations. They are recorded in case they are meaningful to someone who can see the code.

The initialize request is logged at 08:36:47.667Z and the reply is not logged until 08:37:27.211Z, a gap of just under forty seconds on a handshake that should be near instantaneous. The three entries following it are clustered within twenty milliseconds, so this may be log flush batching rather than a real delay. main.log records main process event loop stalls during the same startup, of 2012ms, 1002ms and 1283ms, cumulative 4297ms, which accounts for part but not all of it.

Every line in main.log appears exactly twice, which suggests two logger transports writing to the same file. A duplicate instance has been ruled out, so this is presumed cosmetic.

Two unrelated startup errors appear in the same window. It has not been verified whether they also occur in pre break sessions, so treat them as unqualified:

[error] [Chrome Extension MCP] Failed to copy native host binary: Error: UNKNOWN: unknown error, copyfile ... chrome-native-host.exe
[warn] [watch-record] failed to subscribe to swift events i.on is not a function (TypeError)

The first may simply be a side effect of the WindowsApps junction described above.

1. PASSING COMMENT

It was the user who couldn't let this one go. Claude was the one who concluded that all productive lines of investigation on the user's system had been exhausted by the point this second troubleshooting session was at its conclusion.
22/07/2026: In a related project the user asked Claude Code to investigate further, which revealed the fault may lie in the connector activation at chat start rather than a transport/connection problem. Findings appended below, mostly written by Claude Code.

ADDITIONAL INFORMATION, PART 2

Second follow-up. This extends the first follow-up ("ADDITIONAL INFORMATION") rather than superseding it; nothing in that document is contradicted here, though section 6's hypothesis is refined by what follows. Investigation for this part was done from the client side: DevTools console and network inspection during a clean, isolated reproduction in chat, plus a static read-only extraction of the installed app package.

1. REPRODUCTION ISOLATED TO CHAT ONLY

The app was fully quit (confirmed no running processes) and relaunched. Without opening Cowork or Claude Code, chat alone was used to invoke a filesystem tool. It failed with the same generic on-screen error described in the original report. This rules out interference from another subsystem sharing the same MCP connection and confirms the fault reproduces in chat in isolation.

1. THE INSTALLED APP PACKAGE DOES NOT CONTAIN THE CODE RESPONSIBLE

app.asar was extracted read-only (npx asar extract, working copy only, installed package untouched) and searched exhaustively. It contains the main-process session orchestration, including a manager class that correctly builds MCP proxy tools with no chat-mode exclusion visible in its own code, and correctly implemented connection/error logging throughout. None of that code path is where the fault lives.

The user-visible error text, and the mechanism described in section 13 below, do not exist anywhere in app.asar. They come from a separate renderer bundle (observed as shared-0-VcElU0VQ.js, served from assets-proxy.anthropic.com) that is not packaged locally. Anyone continuing this from source should look there, not in the Electron main-process package.

1. CLIENT SIDE CONFIRMED SILENT — DEVTOOLS CONSOLE SHOWS NO ERROR AT ALL

Section 6 of the first follow-up established that main.log shows no entry at the moment of failure and inferred this was consistent with a silent early return before any logging or throwing code. This is now confirmed directly: with DevTools open and the console cleared immediately before reproducing the failure, the only lines logged for the entire failing turn were two ordinary completion-request lines (request started, request succeeded). No exception, no console.error, nothing red, before, during, or after the failure.

1. THE MECHANISM: MCP TOOLS ARE NEVER SYNCED INTO A CHAT SESSION

A renderer-side log line, tagged [MCP] [AutoSyncConnectorsToSession], announces the number of enabled MCP tools being wired into a session. Filtering the console for this tag:

• Absent, with certainty, across multiple full-console captures of the chat failure, including a brand new chat conversation created specifically to rule out session staleness.
• Present and firing normally, with the correct enabled tool count, when switching to a Claude Code session in the same window.

This was tested twice — once against an existing chat conversation and once against a freshly created one — with the same result both times. Chat-type sessions do not appear to receive this sync at all, at any point in their lifecycle, rather than receiving it late or with stale data.

This narrows the fault from "somewhere in dispatch" to one specific, named function and the condition that decides which session types it is called for. That condition lives in the renderer bundle described in section 11 and was not accessible for further inspection from outside the app.

1. THE "FAILURE" IS A FABRICATED RESULT, NOT A DISPATCH FAILURE

The outgoing network request for the failed tool call was inspected directly. The tool_result sent back to the model is:

{
"type": "tool_result",
"tool_use_id": "<redacted>",
"is_error": true,
"content": [{"type": "text", "text": "Tool execution failed"}]
}

This is a flat, generic value with no distinguishing detail, consistent with a hardcoded fallback rather than a real error surfaced from anywhere in the MCP stack. Combined with section 12, this refines the section 6 hypothesis: the failure is not an unhandled early return so much as a deliberate fallback path that is being reached unintentionally, because the tool the model is trying to call was never registered against the session in the first place (section 13). The fallback itself behaves correctly — it just should not be the normal outcome for every chat tool call.

1. RELOAD MCP CONFIGURATION RULED OUT AS A FIX

The Developer settings "Reload MCP configuration" option was tested. mcp.log confirms it performs a full, clean teardown and reconnect of the configured server (shutdown, reinit, successful initialize, successful tools/list). Both an already-open chat and a freshly created one were retried immediately afterward against this freshly reconnected server, and both failed identically. This rules out stale or cached connection state as the cause; the server side of the connection was never the problem.

1. MINOR, UNCONFIRMED — A SIMILAR-LOOKING BUT SEPARATE ISSUE IN COWORK

Recorded in case it is relevant to whoever has source access, not advanced as related.

Several historical main.log entries, all from Cowork local-agent-mode sessions rather than chat, show a tool permission request being explicitly emitted and explicitly approved by the user ("once"), with no corresponding tools/call entry ever appearing in mcp.log. This pattern was present in entries from well before the deployments described in section 2, as well as afterward, so it does not appear to be the same regression, and it does not affect chat, which per section 13 never reaches a permission prompt for MCP tools at all. It is recorded here only because "permission granted, then nothing dispatches" is a second, independently observed instance of tool invocation going nowhere without any log trace, and that similarity may or may not be coincidental.

1. WHAT WOULD HELP NEXT

The most useful next step is no longer unpacking the Electron app package — that has been done and ruled out (section 11). It is: from source, find every call site of AutoSyncConnectorsToSession (or its equivalent in the current source tree) and determine why chat-type sessions are excluded from it — whether by an explicit session-type check, a missing registration at chat-session creation, or a feature flag. That is now a small, targeted search rather than an open-ended one.

[filesystem] [info] Message from client: method="notifications/initialized"
Client does not support MCP Roots, using allowed directories set from server args: [ 'C:\Users\user-name\source\repos\target-repo' ]
[filesystem] [info] Message from client: method="tools/list" id=1 params
[filesystem] [info] Message from server: id=1 result