[BUG] Claude Desktop app - Filesystem connector not available in Cowork sessions

[osdtinubu]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

The Filesystem connector is installed and configured in the Claude desktop app. It works correctly in the standard Claude desktop app chat, but its cannot be loaded in Cowork sessions.
Claude cannot load the connector in Cowork; the connector appears enabled in the UI but is not surfaced in Cowork sessions

Environment: macOS 26.4.1 (25E253), Claude desktop app (Cowork mode) 1.2773.0 (884b37)

What Should Happen?

Claude can load the connector in Cowork, as it already does in the standard desktop chat

Error Messages/Logs

The Filesystem connector tools (list_directory, move_file, etc.) are still not available — same result as before. The bug is confirmed and reproducible: even with the skill loaded and the connector attached via the "+" button, the Filesystem tools simply don't surface in Cowork sessions.
This is definitely something to include in your bug report.

One additional detail worth adding:
The connector also fails to load when triggered from within a skill that explicitly requires it (uses Filesystem:list_directory and Filesystem:move_file). The tools are absent whether the connector is pre-attached or attached mid-session.

Steps to Reproduce

Install the Filesystem connector via Customize → Connectors → "+" button Configure an allowed directory and click Save Start a new Cowork session The filesystem tools (read file, move file, etc.) are not available to Claude

Also tried: Starting a new cowork session. Restarting the Claude desktop application. Restarting the computer. Starting multiple fresh sessions

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude 1.2773.0 (884b37) 2026-04-15T14:32:09.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Desktop Extension MCP servers not passed to Cowork VM despite being enabled in session config #26259
2. [BUG] Google Drive connector shows connected but tools not exposed in Cowork #30457
3. [BUG] Claude cowork MCP Issue continues #27492

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[0xbrainkid]

Filesystem connector available in desktop chat but not in Cowork sessions — even when enabled in the UI and attached via the "+" button — is the same entrypoint-specific connector scope failure as #49010 (Slack-initiated sessions missing account-level MCP connectors).

The common root cause: Cowork sessions are initialized through a different code path than standard desktop chat sessions, and the connector resolution step that runs at session initialization is different (or absent) in the Cowork path.

From an agent capability and identity perspective, the Filesystem connector is part of the agent's declared tool set. If the UI shows it as enabled but the tools are not surfaced, the agent has a broken capability claim — it appears to have Filesystem access but cannot actually use it. This is the same pattern as the plugin MCP tools regression (#49019) where "Connected" status and actual tool availability diverge.

Diagnostic test: After attaching the Filesystem connector in Cowork, run list_directory /tmp directly as a message. If it fails with "tool not found" vs "permission denied", you can distinguish between registration failure and scope restriction.

The fix direction: Cowork session initialization needs to run the same connector registration step as standard chat sessions. If connectors are registered differently for Cowork (perhaps scoped to a different environment), the Filesystem connector needs to be included in whatever scope Cowork operates in.

Workaround: Try adding the Filesystem MCP server directly via .mcp.json in the project root ({"mcpServers": {"filesystem": {"command": "uvx", "args": ["mcp-server-filesystem", "/path/to/dir"]}}}). Project-level .mcp.json servers are less likely to have the Cowork scope limitation than account-level connectors.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[onesdayz]

Bug: Filesystem MCP connector permanently broken if first initialized inside a Project chat

Environment

• Claude Desktop app (macOS)
• Filesystem MCP connector (@modelcontextprotocol/server-filesystem)
• Connector shows as "Connected" / toggle ON in Connectors settings

Summary

The Filesystem MCP connector's tools are unavailable in a chat session if that session's first MCP handshake/initialization occurred while the chat was inside a Project. This appears to permanently break that specific chat session — moving the chat in or out of the Project afterward does not fix it. The bug is tied to the session's initial state, not its current state.

Reproduction steps (4 tested scenarios)

Scenario 1 — Works ✅

1. Start a new chat outside any Project
2. Ask Claude to use the filesystem tool (e.g., "list files in [folder]") — succeeds
3. Add this same chat to a Project
4. Ask again — still works correctly

Scenario 2 — Fails ❌

1. Start a new chat outside any Project
2. Do NOT use the filesystem tool yet
3. Add the chat to a Project
4. Now ask Claude to use the filesystem tool — fails (tools not available)

Scenario 3 — Fails ❌

1. Start a new chat directly inside a Project
2. Ask Claude to use the filesystem tool — fails (tools not available)

Scenario 4 — Fails ❌ (confirms permanence)

1. Start a new chat inside a Project (as in Scenario 3, tool call fails)
2. Remove this chat from the Project
3. Ask Claude to use the filesystem tool again in the same chat — still fails

Key finding

The deciding factor is whether the chat session was inside a Project at the moment of its first MCP tool initialization/handshake — not whether it is currently inside a Project.

• If first handshake happens outside a Project → tools keep working regardless of later Project membership changes.
• If first handshake happens inside a Project → tools never become available in that session, even after removing it from the Project.

This suggests the MCP tool registry/handshake is being scoped or cached incorrectly when a Project context is present at session creation, and this broken state is not re-evaluated when Project membership later changes.

Expected behavior

Filesystem MCP tools should be available consistently based on the connector's current enabled/connected state, regardless of:

• whether the chat is inside a Project
• when the chat was created relative to Project membership

Additional notes

• The connector consistently shows as "Connected"/enabled in the UI in all 4 scenarios — there is no visible error to the user explaining why tools aren't available in the broken sessions.
• This is consistent with previously reported issue [BUG] Claude Desktop app - Filesystem connector not available in Cowork sessions #49181 ("Filesystem connector not available in Cowork sessions"), but this report identifies a more specific root cause: it's not strictly "Project vs non-Project" at the current moment, but the Project state at first initialization that determines the session's permanent behavior.

Suggested fix direction

Re-evaluate / re-initialize MCP tool availability when:

1. A chat's Project membership changes, OR
2. At minimum, ensure first-handshake scoping doesn't permanently lock out tools that are otherwise connected and enabled.