Chat sessions route local MCP to the agent-mode stack, which silently drops the Filesystem extension (no tools/call, no log)

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?

Claude Desktop 1.24012.1 (build 0adcae, macOS 15.6.1, Apple Silicon, 1p Max account)

Symptom

Filesystem MCP tool calls from chat sessions are never delivered. The server
receives initialize and tools/list and answers both; tools/call never arrives.
UI shows an instant failure. Nothing is logged in mcp.log, mcp-server-*.log, or
main.log — on either side.

Same server, same machine, same minute, works from Cowork.

Evidence (mcp.log, adjacent calls)

06:31:39.817 [Read and Write Apple Notes] Message from client: method="tools/call" id=2
06:31:45.300 [Read and Write Apple Notes] Message from server: id=2 result(1 blocks)
[Filesystem] ...nothing after tools/list

Last successful filesystem tools/call: 2026-07-21T20:53:32Z. 4,408 successful
calls logged in the preceding four months, zero since. Auto-update to 1.24012.1
landed at 21:14Z; that build is timestamped 2026-07-21T20:59:53Z.

Scope

Dispatches fine: Apple Notes, Control Chrome, Shadcn UI
Never dispatches: Filesystem extension, plus two config-defined
@modelcontextprotocol/server-filesystem instances under different names
iMessage: never dispatches, 4-min timeout instead (cf. #44032)

Ruled out

App version (fails on 1.24012.1 and 1.2581.0), virgin support directory,
different account on same machine, TCC (FDA granted; also full tccutil reset +
re-grant), App Translocation (found and fixed, unrelated), extension
reinstall, full extension-state wipe, tool permissions set to Always allow,
MCP protocol version (2025-11-25 both sides), built-in vs homebrew node,
npx vs direct path, server name, tool descriptions/approvalHash, tool names,
new conversations, macOS updates, MDM, system extensions.

Static analysis of the shipped bundle

createAllServers (index.chunk-DCqEa0V-, ~:5860) drops servers where
extensionId === "ant.dir.ant.anthropic.filesystem" when filterFilesystemMcp is
set. It returns without logging — the only silent server-exclusion in the
dispatch chain. filterFilesystemMcp: true is hardcoded at four call sites
(index.chunk-DtBjckUd :4223, :10107; index.chunk-CKqp-KzK :7751, :11890).

mcp.log has exactly one writer: the DFn relay built by launchMcpServer
(index.chunk-D5Kys2dl ~:106195). The agent-mode/cowork stack uses a different
transport and never writes it. So a call routed there fails silently by
construction.

buildLocalMcpBridgeTools (index.chunk-BBqcVvH6) does NOT apply the filter,
which is consistent with Cowork working.

Open question: the filter keys on extensionId, so it cannot explain why
config-defined servers (no extensionId) also fail. There appears to be a second
silent gate — possibly the dual-prefix isToolUserDisabled check gated on flag
2246535838.

Likely regression

Chat sessions appear to have moved onto a stack that was built to exclude the
DXT filesystem extension by design. If that routing change was intentional,
the filesystem extension is now unusable in chat and should say so rather than
failing silently. If it wasn't, this is the regression.

Related

#66726 (identical signature, closed as duplicate), #36319 (silent stdio drop),
#44032 (4-min cancel), #22299

What Should Happen?

Filesystem MCP tool calls issued from a chat session should be delivered to the
connected MCP server and return a result, as they did continuously for four
months prior to 2026-07-21 (4,408 logged calls).

Specifically:

1. A tools/call from chat should reach the server and appear in mcp.log, the

same way Apple Notes, Chrome, and Shadcn calls still do.

1. If the filesystem extension is intentionally excluded from the stack that now

services chat sessions, the tools should not be advertised to the model at
all, and any call should return an explicit error naming the reason — not
fail silently with nothing logged on either side.

The current behaviour is the worst of both: the tools appear available, calls
fail instantly, and no log on either side records that anything was attempted.

Error Messages/Logs

No error is logged anywhere. That is the bug.

mcp.log, two calls seconds apart in the same session:
06:31:39.817 [Read and Write Apple Notes] Message from client: method="tools/call" id=2
06:31:45.300 [Read and Write Apple Notes] Message from server: id=2 result(1 blocks)
[Filesystem] — nothing after tools/list

Last successful filesystem tools/call: 2026-07-21T20:53:32Z
4,408 successful calls in the prior four months, zero since.
UI shows an instant generic failure; no entry in mcp.log,
mcp-server-*.log, or main.log on either side.

Steps to Reproduce

1. Install the Filesystem extension in Claude Desktop 1.24012.1 (macOS),

configure an allowed directory, confirm it is enabled.

1. Confirm the server is healthy: ~/Library/Logs/Claude/mcp-server-filesystem.log

shows initialize and tools/list succeeding on every launch.

1. In a normal chat session, ask Claude to list a file in an allowed directory.
2. Observe: instant failure. No tools/call in any log. Server never receives it.
3. In the same session, ask Claude to use an Apple Notes or Chrome MCP tool.

Observe: dispatches, logs, returns normally.

1. In a Cowork session, call the same Filesystem tool. Observe: it works.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Desktop 1.24012.1 broke it; last working was the build immediately prior (broke 2026-07-21 ~20:53 UTC, bundle replaced 21:14 UTC)

Claude Code Version

N/A — this is Claude Desktop 1.24012.1 (build 0adcae), not Claude Code

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_