Claude Desktop 1.24012.x (Windows Store/MSIX): MCP filesystem mount transport becomes unresponsive with cross-chat propagation — signature consistent with client-side connection-pool exhaustion

### What happened?

On Claude Desktop Windows Store/MSIX build **1.24012.1 (0adcae)**, local MCP filesystem mounts (node-based `@modelcontextprotocol/server-filesystem`) intermittently become unresponsive.

Failures present as one of three flavors, all pointing at one underlying fault:

1. **Multi-minute timeout** — call eventually returns a timeout (approximately 4 minutes observed)
2. **Indefinite hang** — call never returns
3. **Instant fast-fail** — "Tool execution failed" immediately

Failures are **cross-chat**: activity in one open Desktop chat degrades or kills MCP mount capability for other open chats using the same mount, indicating MCP server connections are shared at the application level rather than per-chat. Recurrence is approximately every 2–3 sessions of normal use. The only external remedy is force-quit and relaunch of Claude Desktop, which occasionally requires a second attempt.

Also observed on Claude Desktop **1.24012.9 (03c61d)** — same failure family.

Cross-reference to internal Anthropic support ticket: **Conversation ID 215475233878353** (Fin messenger, filed 2026-07-25, escalated to human specialist).

### What did you expect to happen?

Activity in one Desktop chat should not affect MCP mount availability in any other open chat using the same mount. An aborted or failed operation should leave the transport in a healthy state.

Under normal use, the MCP filesystem mount should remain responsive across an entire Claude Desktop session without periodic wedging, and should not require force-quit-and-relaunch of the application as an external remedy.

### Steps to reproduce

1. Launch Claude Desktop with two or more chats/seats configured to use the same filesystem MCP mount.
2. In seat A, perform activity through the mount. A write or write-attempt accelerates failure, but sustained reads alone at enough volume also reach failure.
3. In seat B — and often A — attempt reads or writes through the same mount.
4. Observe: operations hang, time out, or fast-fail across seats.
5. Remedy: force-quit and relaunch Claude Desktop. Approximately 75% of outages recover on first reset; approximately 25% require a second (which has never been observed to fail across 40+ hard-reset script runs).

Recurrence cadence: approximately every 2–3 sessions of normal use.

### Area

Session / Connection Management

### MCP Server (if applicable)

@modelcontextprotocol/server-filesystem (node-based filesystem server, via stdio transport)

### Error messages or logs

```shell
Three failure signatures observed at the tool-call layer:
- Multi-minute timeout (approximately 4 minutes)
- Indefinite hang (call never returns)
- Instant "Tool execution failed"

No specific error strings from the MCP client are surfaced in the Desktop UI. Detailed logs from `%APPDATA%\Claude\logs` (main.log, mcp-server-*.log) will be captured at the next observed failure and attached or forwarded — they were not preserved from prior outages before the reset script wiped state.
```

### Additional context

## Novel observations (not documented in existing public issues)

**Cross-chat / cross-seat propagation.** A write or heavy-read pattern in one Desktop chat kills mount capability in other open chats using the same mount. This is essentially unreported in existing public issues surveyed and is the primary reason for this filing. Independent corroboration for the app-level shared lifecycle it implies: [claude-code #64671](https://github.com/anthropics/claude-code/issues/64671) reports "toggling one connector restarts ALL enabled servers" — same class of app-scoped coupling.

**Teardown-survival signature.** A single force-quit-and-relaunch clears the fault approximately 75% of the time. The remaining ~25% require a second full teardown-and-relaunch cycle, which has never been observed to fail. If the fault were purely in-memory state that died with the process, one clean relaunch would be deterministic. That it occasionally survives one complete teardown and reassembles on relaunch suggests some client state is being persisted (cache file, unfinalized queue, serialized routing table) and rehydrated on startup rather than always spawned fresh.

**Cold-boot MCP server over-provisioning.** Task Manager snapshot immediately after a clean Windows reboot with Claude Desktop launched (no chats opened yet) shows:
- 32 processes in the `Claude` process group total
- ~8 `Claude` processes (Electron helpers)
- 11 `Console Window Host` processes
- 12+ `Node.js JavaScript Runtime` processes

For a filesystem mount configuration that should require only 3–5 node MCP servers, 12+ observed at cold boot indicates either boot-time over-provisioning or multiple node processes per configured server.

## Mechanism hypothesis: client-side connection-pool exhaustion

The signature — three failure flavors, load-proportional time-to-failure, correlation with concurrent chat count, cross-seat propagation, recovery only via full restart — is structurally consistent with connection-pool exhaustion in the MCP client transport. This is a well-known pathology from database driver history: a shared bounded client-side resource leaks under load and manifests as hangs, long timeouts, and fast-fails.

Candidate concrete mechanism: the client's pending-request map (JSON-RPC `id` → callback) is app-scoped rather than chat-scoped, and entries are not always reclaimed on response, timeout, cancel, or failed-write-in-flight. Threshold crossings under load produce the observed flavors:
- **Hang** = pipe alive, map won't route this request
- **Timeout** = same, with upper-layer give-up
- **Fast-fail** = client has already marked the shared transport dead

Presented as a hypothesis consistent with all observations, not a proven mechanism.

## Control: Claude Code on the same machine is unaffected

Claude Code (CLI) on the same machine — same OS, same node runtime, same PostgreSQL instance — is entirely unaffected through every observed outage. Claude Code accesses the filesystem via native OS I/O and PostgreSQL via direct `psql`, bypassing the Desktop MCP transport entirely. This isolates the fault to Desktop's own MCP client implementation rather than to the OS, MCP server processes, the node runtime, or the network.

## Falsified hypothesis: orphaned MCP server processes

Across 40+ hard-reset script runs, no MCP server process survives Desktop's exit. A snapshot immediately after Desktop force-quit consistently shows zero surviving processes matching the pattern `server-filesystem|modelcontextprotocol|dbhub`. The wedged state lives inside the Desktop process itself, not in orphaned server processes.

## Related public issues (same failure family, different signatures — establishing this is a distinct variant, not a duplicate)

- [anthropics/claude-code #80094](https://github.com/anthropics/claude-code/issues/80094) — macOS Desktop 1.24012.0, filesystem tool calls fail after handshake. Version-line match on a different OS.
- [anthropics/claude-code #64671](https://github.com/anthropics/claude-code/issues/64671) — Windows MSIX; toggling one connector restarts all enabled servers. Independent evidence of app-level shared MCP lifecycle.
- [anthropics/claude-code #22451](https://github.com/anthropics/claude-code/issues/22451) — Windows; all MCP tool calls hang ~5 min then "No result received from client-side tool execution." Timeout-flavor match.
- [anthropics/claude-code #22299](https://github.com/anthropics/claude-code/issues/22299) — Windows; tool-call responses dropped by client after first successful round-trip. Response-routing failure in the same subsystem.
- [anthropics/claude-code #15060](https://github.com/anthropics/claude-code/issues/15060) — Filesystem connector write operations report success but silently fail to persist. Closest public analog for the write-in-flight failure mode.
- [anthropics/claude-ai-mcp #664](https://github.com/anthropics/claude-ai-mcp/issues/664) — Independent conclusion that "the regression is in Desktop's client-side MCP routing after the handshake, not in the server implementation." Closest architectural corroboration.

## Diagnostic questions for engineering

1. Are MCP server connections instantiated per-application (shared across chat windows) versus per-chat?
2. Is the JSON-RPC pending-request map app-scoped or chat-scoped?
3. How are pending-request-map entries reclaimed on timeout, cancel, and failed-write-in-flight?
4. Is there bounded-queue backpressure on the MCP client transport?
5. What client-side MCP state is serialized to disk on shutdown and rehydrated on launch? (Candidate mechanism for the ~25% teardown-survival signature.)
6. What is the expected node MCP server count for a given mount configuration? Is 12+ processes at cold boot (versus expected 3–5) consistent with design?
7. Are MCP servers spawned for a chat reaped when that chat is closed?

## Evidence available (on request)

- Cold-boot Task Manager process-census screenshot
- Hard-reset PowerShell/batch script with before/after process snapshots (40+ runs, invariant "AFTER clean" result)
- `%APPDATA%\Claude\logs` excerpts (main.log, mcp-server-*.log) — will be captured at next observed failure
- Version-tracking data across observed builds (1.24012.1 / 0adcae and 1.24012.9 / 03c61d)

## Environment

- OS: Windows (Store/MSIX Claude Desktop build)
- Claude Desktop version: 1.24012.1 (0adcae); also observed on 1.24012.9 (03c61d)
- Desktop AUMID: `Claude_pzs8sxrjxfjjc!Claude`
- MCP transport: stdio; node-based filesystem servers + one DB connector (dbhub)
- Claude Code (control): latest available; unaffected on same machine
- PostgreSQL access (control): direct `psql`; does not traverse Desktop