[BUG] claude desktop bridge bug report

Status Open
Maintainer reply None cached
Activity 2 comments · opened Jul 21, 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?

Claude Desktop 1.24012.1 (macOS): local MCP tools/call dropped — multiple surfaces race one device bridge; unfixed by 1.24012.0 → .1

Preflight

  • [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 (1.24012.1)

Environment

  • App: Claude for Mac (Claude Desktop) 1.24012.1 (0adcae)
  • Regression window: worked on 1.22209.3; broke on 1.24012.0 (44be96) after auto-update; still broken on 1.24012.1 (0adcae), the immediate hotfix
  • OS / arch / Node: appVersion: '1.24012.1',

isPackaged: true,
platform: 'darwin',
arch: 'arm64',
nodeVersion: '24.18.0'

  • Account / window / device: single account, single window, single device registration
  • Extension: Filesystem v2026.7.10 (bundles @modelcontextprotocol/server-filesystem v2026.7.4), enabled, allowed-directories configured and confirmed persisted
  • Other connectors on the same bridge: Word, PowerPoint, PDF Tools, Control Chrome

Symptom

Every live Filesystem tool call (e.g. list_allowed_directories) returns a generic Tool execution failed. The request never reaches the MCP server: around the failure timestamp, mcp.log and mcp-server-Filesystem.log record only initialize, notifications/initialized, and tools/listnever a tools/call. The failure is invisible in the local MCP logs, indicating the request is dropped above the local MCP host.

Root cause (from main.log)

On each launch, more than one bridge-owning surface starts — the chat renderer plus background Cowork and Claude-Code-Desktop (CCD) renderers. Each opens a [remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/<device>/…/bridge to the same device ID, and each emits [localMcpBridge] announcing Filesystem: 14 tool(s). These appear in identical-timestamp pairs.

Because the device bridge endpoint holds one connection per device, the surfaces evict each other, producing repeated [remote-tools-device] close → reconnect / rotation churn. A tools/call that arrives while a surface is mid-re-announce or just-evicted has no live Filesystem host to route to, so it errors upstream without ever reaching the server.

This is consistent with the surface counts observed via ps immediately after a clean launch: two renderers (one carrying cowork, one ccd in its args) and three MCP Node hosts (node.mojom.NodeService), with a single restored window.

Reproduction

  1. Fully quit and verify zero residual processes:

osascript -e 'tell application "Claude" to quit'pkill -f "/Applications/Claude.app" → confirm ps aux | grep -i "[C]laude.app" prints nothing.

  1. Relaunch. main.log logs a single Starting app { appVersion: '1.24012.1' }.
  2. Within ~4 s, the bridge comes up doubled — paired announcing Filesystem + paired connecting wss://…/bridge at an identical timestamp (see excerpt).
  3. Invoke any Filesystem tool → Tool execution failed.
  4. mcp.log / mcp-server-Filesystem.log show only initialize / tools/list; no tools/call.

Observed additionally: right after launch there is a brief (~2 min) single-surface window before the second surface joins and the announce doubles — so a call fired immediately after a restart may occasionally succeed before failing thereafter.

Log excerpt (device ID + hostname redacted)

2026-07-22 07:06:55 [info] Starting app { appVersion: '1.24012.1', isPackaged: true, platform: 'darwin', ... }
2026-07-22 07:06:59 [info] [localMcpBridge] announcing Filesystem: 14 tool(s)
2026-07-22 07:06:59 [info] [remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/<REDACTED>/<HOST>/bridge
2026-07-22 07:06:59 [info] [localMcpBridge] announcing Filesystem: 14 tool(s)
2026-07-22 07:06:59 [info] [remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/<REDACTED>/<HOST>/bridge

Both announcing Filesystem and connecting wss lines are duplicated at the same second — the signature of two surfaces registering under one device ID.

Ruled out (none resolve the issue)

  • Full uninstall + fresh reinstall of the app
  • Force-quit to zero processes + clean relaunch (repeated; doubled announce recurs every time)
  • Forward update 1.24012.0 → 1.24012.1, then a verified-zero restart on .1
  • macOS permissions reset (tccutil reset All com.anthropic.claudefordesktop) + re-grant of Full Disk Access and Files & Folders
  • Filesystem allowed-directories reconfigured and confirmed persisted; single extension install
  • Filesystem tool permission set to "Always allow"
  • Device registry (ant-device-registry.json) confirmed clean and single
  • Disabling coworkScheduledTasksEnabled / ccdScheduledTasksEnabled in claude_desktop_config.json — the app re-syncs both back to true on launch; doubled announce persists regardless

Scope

Only local-MCP extensions are affected. Control Chrome is unaffected (it runs a separate connection, immune to the remote-tools-device churn). Word / PowerPoint / PDF share the local-MCP path and are intermittently affected by the same race.

Request

  1. A build that coordinates surface/bridge registration so only one connection per device announces local-MCP servers, or
  2. A supported way to pin 1.22209.3 (the last known-good build) — note there is no user-facing auto-update toggle on Desktop, so a manual downgrade re-updates itself without one.

Possibly related

#76054 — "[BUG] Desktop Bridge Failure" (post-update bridge-attach failure; Windows / Cowork-session-specific, so possibly the same root cause, not identical).

---

Attaching your log

Redact the device + account UUIDs and hostname before posting publicly:

sed -E 's#devices/[a-f0-9-]+_[a-f0-9-]+/[^/]+/bridge#devices/<REDACTED>/<HOST>/bridge#g' \
  ~/Library/Logs/Claude/main.log > ~/Downloads/claude-main-redacted.log

Attach claude-main-redacted.log (a trimmed excerpt around one launch showing the paired lines is sufficient). File at: https://github.com/anthropics/claude-code/issues → New issue → Bug report. Suggested labels: area:desktop, platform:macos, has repro.

What Should Happen?

claude-main-redacted.log

Error Messages/Logs

Steps to Reproduce

  1. Fully quit and verify zero residual processes:

osascript -e 'tell application "Claude" to quit'pkill -f "/Applications/Claude.app" → confirm ps aux | grep -i "[C]laude.app" prints nothing.

  1. Relaunch. main.log logs a single Starting app { appVersion: '1.24012.1' }.
  2. Within ~4 s, the bridge comes up doubled — paired announcing Filesystem + paired connecting wss://…/bridge at an identical timestamp (see excerpt).
  3. Invoke any Filesystem tool → Tool execution failed.
  4. mcp.log / mcp-server-Filesystem.log show only initialize / tools/list; no tools/call.

Observed additionally: right after launch there is a brief (~2 min) single-surface window before the second surface joins and the announce doubles — so a call fired immediately after a restart may occasionally succeed before failing thereafter.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.22209.3

Claude Code Version

Claude 1.24012.1 (0adcae) 2026-07-21T20:59:53.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

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