[BUG] Desktop app: concurrent Filesystem MCP access from parallel tabs times out (~4 min) and wedges the connector, requiring app restart (macOS)

Open 💬 1 comment Opened Jul 13, 2026 by moosepass

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

When two chat sessions run in parallel in separate tabs of the same desktop app instance and both need to access the local filesystem concurrently (via the Filesystem connector), one tab receives a timeout from the filesystem connector while the other proceeds. The filesystem work itself is valid; the connector call in the losing tab times out rather than completing or queueing cleanly.

Reproduced by retrying — the timeout recurs under concurrent filesystem access.

Likely related to #76552 (two concurrent in-flight prompts in separate tabs deadlock both sessions). Both point at the desktop app not safely handling concurrent sessions that contend for a shared resource — here specifically the Filesystem connector.

Account is on an Enterprise license.

What Should Happen?

Concurrent filesystem-connector access from two parallel sessions should either be serviced concurrently or serialized transparently — neither session should time out.

Error Messages/Logs

The model's own narration in the affected tab (raw MCP error string not surfaced to the user):

The Filesystem MCP dropped again mid-edit — same 4-minute timeout as earlier, so that hostsafety edit is in unknown state and further tool calls will likely hang. Before I continue writing: restart the MCP servers (quit and reopen Claude Desktop, or toggle the Filesystem connector off/on) …

Key facts from this:

  • Consistent ~4-minute timeout on the Filesystem MCP call.
  • Occurs mid-edit (during a Filesystem write/edit operation).
  • Recurring ("dropped again").
  • After the drop, the in-progress edit is left in an unknown state and subsequent tool calls hang.

⟨If possible, also attach the raw MCP/connector error from the app's developer console or log directory — the verbatim error string would help triage.⟩

Steps to Reproduce

  1. Open the Claude Code desktop app.
  2. Open two tabs (parallel "consultation"), each on a different project in a different directory.
  3. In both tabs, issue prompts that require the Filesystem connector to read/access local files at the same time.
  4. Observe: one tab returns a timeout from the filesystem connector; the other proceeds.
  5. Retry the same concurrent access → the timeout reproduces.

Claude Model

Fable 5 (high effort)

Is this a regression?

Don't know — first observed on the current (latest) version 1.19367.0; no confirmed prior working baseline.

Last Working Version

Unknown

Claude Code Version

Desktop app 1.19367.0 (1a5be1)

Platform

Desktop app

Operating System

macOS Tahoe 26.5

Terminal/Shell

N/A (desktop app)

Additional Information

  • Enterprise license.
  • Model: Fable 5 (high effort).
  • Reproduced consistently via retries.
  • Filesystem access is via the Filesystem connector (MCP).
  • Timeout duration is a consistent ~4 minutes, suggesting a fixed MCP call-timeout ceiling rather than random slowness.
  • After the timeout the connector appears wedged: the interrupted edit is left in an unknown state and subsequent tool calls hang until the MCP servers are restarted (quit/reopen the app, or toggle the Filesystem connector off/on).
  • Likely related: #76552 (concurrent tabs deadlock), #75561 (connector discovery stalls with no timeout).
  • The two tabs are on different projects in different directories (not same-path contention).
  • Random tab times out — no discernible pattern as to which of the two.
  • Never recovers on its own — an app restart is always required; toggling the connector / restarting MCP servers is the only way back to a working state.
  • First observed on version 1.19367.0 (the latest; same version as #76552).

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗