Skip to content

[BUG] Filesystem server crashes completely when any configured path is invalid #2113

Closed as not planned

Description

@MikeyBeez

[BUG] Filesystem server crashes completely when any configured path is invalid

Description

The MCP filesystem server shuts down entirely if ANY path in the configuration becomes invalid (unmounted volume, disconnected network share, typo). This makes the protocol fragile and unsuitable for production use.

Current Behavior

When any path is inaccessible:

  • Entire filesystem server shuts down
  • ALL file access is lost (not just the invalid path)
  • No error recovery possible through Claude
  • Must restart Claude Desktop to restore functionality

Expected Behavior

  • Invalid paths should be skipped with a warning
  • Valid paths should continue working
  • Server should log errors but not crash
  • Graceful degradation, not total failure

Steps to Reproduce

  1. Configure MCP filesystem with a network mount:
"filesystem": {
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-filesystem",
    "/Users/username/Desktop",
    "/Volumes/NetworkDrive"  // This is a Samba mount
  ]
}
  1. Start Claude Desktop - filesystem works normally
  2. Disconnect network/unmount the Samba share
  3. Filesystem server crashes completely
  4. Cannot access even /Users/username/Desktop anymore

Impact

  • Severity: Critical
  • Frequency: Happens whenever network conditions change
  • Workaround: None - must restart Claude Desktop

Real-World Example

Working on a project with files on both local disk and a Samba mount. Network hiccup occurs:

  • Samba mount at /Volumes/Code becomes unavailable
  • MCP filesystem server completely dies
  • Cannot read local logs to debug
  • Cannot edit local config files to remove the bad path
  • Cannot continue any file-based work until full restart

Proposed Solution

// pseudocode
async function initializePaths(configuredPaths) {
  const validPaths = [];
  
  for (const path of configuredPaths) {
    try {
      await fs.access(path);
      validPaths.push(path);
      console.log(`✓ Registered path: ${path}`);
    } catch (error) {
      console.warn(`✗ Skipping inaccessible path: ${path} - ${error.message}`);
      // Continue with other paths instead of crashing
    }
  }
  
  if (validPaths.length === 0) {
    throw new Error("No valid paths found");
  }
  
  return validPaths;
}

Additional Context

This "all-or-nothing" approach contradicts basic fault tolerance principles. For MCP to be a production-ready standard for LLM tool integration, it must handle common scenarios like:

  • Network drives going offline
  • Typos in configuration
  • Permissions changes
  • Mounted volumes being unmounted

The current behavior makes MCP fragile and frustrating to use in real development environments.

Environment

  • OS: macOS [your version]
  • Claude Desktop: [your version]
  • MCP filesystem server version: [check package.json]

Related Issues

  • [Check if there are similar issues and reference them]

Note: This issue affects anyone using MCP with network storage, external drives, or complex file system configurations. The fix would significantly improve MCP's reliability and production readiness.

Activity

  1. added
    server-filesystemReference implementation for the Filesystem MCP server - src/filesystem
    on Jul 3, 2025
  2. sebastien-rosset commented on Aug 22, 2025

    @sebastien-rosset
    Contributor

    Related to #2483

  3. cliffhall commented on Oct 19, 2026

    @cliffhall
    Member

    Closing: superseded by the v2 release.

    Thank you for reporting this, and apologies for the long wait for a response.

    Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. The server now skips an inaccessible configured directory at startup with a warning, exits only when none is accessible, and per-call validation touches only the directory containing the requested path, so one missing or unmounted directory no longer takes the others down.

    This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.

    If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see CONTRIBUTING.md.

    Thanks for taking the time to report it.

  4. added
    closed-superseded-v2Closed: fixed or made obsolete by the v2 / 2026-07-28 refactor (#4875)
    on Oct 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingclosed-superseded-v2Closed: fixed or made obsolete by the v2 / 2026-07-28 refactor (#4875)server-filesystemReference implementation for the Filesystem MCP server - src/filesystem

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions