Local MCP server allowed directories get overwritten by Claude Code working directory

Resolved 💬 3 comments Opened Apr 5, 2026 by formnutrition Closed Apr 8, 2026

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?

Bug: Local MCP server allowed directories get overwritten by Claude Code working directory

Environment:

  • macOS, Claude Desktop + Claude Code + Cowork
  • MCP server: @modelcontextprotocol/server-filesystem

Setup:
I have a local filesystem MCP server called "obsidian" configured in Claude Desktop pointing at my Obsidian vault:

"obsidian": {
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-filesystem@latest",
    "/Users/me/Library/Mobile Documents/iCloud~md~obsidian/Documents/damo"
  ]
}

This works correctly after a fresh restart of Claude Desktop — the server reports the vault as the allowed directory.

The bug:
When I open Claude Code in a different project directory (e.g. /Users/me/Projects/chords), the Obsidian MCP server in Claude Desktop gets its allowed directories silently overwritten to the Claude Code working directory. After that, any Desktop chat or Cowork scheduled task that tries to use the Obsidian server fails with:

{"content":"Allowed directories:\n/Users/me/Projects/chords"}

The Desktop UI still shows the correct vault path in the server config, and the server shows as "running" — but the actual process is scoped to the wrong directory.

Attempted fix:
I also registered the same server in Claude Code at user scope:

claude mcp add obsidian -s user -- npx -y @modelcontextprotocol/server-filesystem@latest "/path/to/vault"

This helped briefly, but the problem recurs when Claude Code opens a new project directory. The server's allowed directories get overwritten again.

Impact:
This makes Cowork scheduled tasks that depend on local MCP servers unreliable. Every time Claude Code is used in a different project, Cowork's local MCP connections break until Desktop is manually restarted.

Expected behaviour:
Claude Desktop's local MCP servers should maintain their configured allowed directories regardless of what Claude Code is doing. The two apps should not share or overwrite each other's MCP server process scope.

Repro steps:

  1. Configure a local filesystem MCP server in Claude Desktop pointing at directory A
  2. Restart Desktop, confirm the server reports directory A as allowed
  3. Open Claude Code in directory B
  4. Go back to Desktop and check the server's allowed directories — it now reports directory B instead of A

What Should Happen?

Each Claude surface (Desktop, Code, Cowork) should maintain its own independent MCP server process, or at minimum respect the allowed directories defined in its own config file. Opening Claude Code in /Projects/foo should have no effect on a filesystem MCP server that Claude Desktop launched with /path/to/obsidian/vault as its allowed directory. The two should be fully isolated.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

Add a local filesystem MCP server to Claude Desktop's config (claude_desktop_config.json) with a specific allowed directory, e.g. an Obsidian vault
Restart Claude Desktop and confirm the server is running with the correct allowed directory
Open Claude Code in a different project directory (e.g. ~/Projects/some-project)
Go back to Claude Desktop or trigger a Cowork scheduled task that uses the filesystem MCP server
The server now reports ~/Projects/some-project as its allowed directory instead of the configured vault path
Any read/write to the original allowed directory fails with "Access denied - path outside allowed directories"

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.569.0 (49894a) 2026-04-02T20:01:42.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗