SSH remote passes local plugin paths and MCP configs to remote server, causing hang

Status Open

Reported on v2.1.42

Maintainer reply ✓ Yes — amorriscode

Activity 8 comments · opened Feb 14, 2026

💡 Likely answer: A maintainer (amorriscode, contributor) responded on this thread — see the highlighted reply below.

Bug Description

When connecting to a remote server via SSH, Claude Code passes local macOS plugin paths and MCP server configurations to the remote ccd-cli process. These paths don't exist on the remote machine, causing it to hang indefinitely until the client times out with "Failed to load session".

Root Cause

The remote ccd-cli process is invoked with local paths and configs:

--plugin-dir /Users/<user>/.claude/plugins/cache/claude-plugins-official/pyright-lsp/1.0.0
--plugin-dir /Users/<user>/.claude/plugins/cache/claude-hud/claude-hud/0.0.1
--plugin-dir /Users/<user>/.claude/plugins/cache/claude-plugins-official/ralph-wiggum/15b07b46dab3
--plugin-dir /Users/<user>/.claude/plugins/cache/claude-plugins-official/swift-lsp/1.0.0
--mcp-config {"mcpServers":{"Claude in Chrome":{"type":"sdk","name":"Claude in Chrome"},"mcp-registry":{"type":"sdk","name":"mcp-registry"}}}

These /Users/<user>/... paths don't exist on the remote Linux server, and the MCP servers (Claude in Chrome, mcp-registry) aren't available remotely.

The ccd-cli process consumes ~280MB RAM, opens a socket to the API, but hangs indefinitely — presumably failing to load the non-existent plugins. Eventually the client times out and shows "Failed to load session".

Steps to Reproduce

Install plugins and/or MCP servers locally (e.g., pyright-lsp, claude-hud, Claude in Chrome)
Set up an SSH connection to a remote Linux server
Connect via Claude Code SSH
Observe ccd-cli on the remote server being passed local plugin paths via --plugin-dir

Expected Behavior

The SSH remote session should either:

Not pass local plugin paths/MCP configs to the remote machine
Resolve/sync plugins to the remote before launching
Gracefully skip missing plugins instead of hanging

Environment

Local: macOS (Darwin 25.2.0), Claude Code 2.1.42
Remote: Ubuntu 18.04, x86_64

#25661 (SSH connection ignores Identity File setting)

View original on GitHub ↗

7 Comments

solomon23 · 6 months ago

Additionally, the error message shown to the user is just "Failed to load session" with no actionable information. There are no client-side logs indicating what went wrong, and the remote ccd-cli process produces no stderr output despite hanging/failing.

It took significant debugging (wrapping the binary, inspecting process args, reading remote server logs) to identify the root cause. A more descriptive error — or at minimum logging the ccd-cli command-line arguments and any plugin loading failures — would make this much easier to diagnose.

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

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

amorriscode contributor · 6 months ago

Should be fixed in the next release, sorry about that.

solomon23 · 6 months ago

<img width="395" height="234" alt="Image" src="https://github.com/user-attachments/assets/3e7bf58c-cc60-41e0-b77e-f1a06968623c" />
still seeing this with the update today

smabie · 4 months ago

Hi any updates on this? Still experiencing this issue for latest version (Claude 1.569.0 (49894a) 2026-04-02T20:01:42.000Z)

richindebitch · 4 months ago

Still reproducing as of April 23, 2026. Adding detailed logs that pinpoint the exact components involved — may help prioritize the fix.

Environment

Desktop: Claude for macOS (SSH binary version 9a871e263f5ad97516c97c8c8129f94990635ae7, built 2026-04-21)
Remote CCD CLI: ccd-cli/2.1.111
Client OS: macOS (Apple Silicon)
Remote OS: Ubuntu 24.04 LTS
SSH: ed25519 key-based auth, works instantly from terminal
Installed MCP extensions on Mac: Figma, Filesystem, Control your Mac (osascript)
Active connectors: GitHub (and previously Google Drive/Gmail/Calendar)

Root cause components

The culprits in Desktop's SSH bridge are two internal components visible in ~/Library/Logs/Claude/ssh.log:

SshMcpServerManager — tries to start local MCP servers on the remote
RemoteStdioTransport:<ExtensionName> — stdio bridge for each MCP

Both log errors on every single remote session start, whether the user invokes MCP tools or not. They are spawned eagerly.

Reproducible error signature

On every connection attempt, Desktop's log shows exactly these errors (captured from my live logs, multiple occurrences on 2026-04-22 and 2026-04-23):

[error] [RemoteProcess:<uuid>] Spawn failed: exec: "node": executable file not found in $PATH
[error] [RemoteStdioTransport:Figma] process error: exec: "node": executable file not found in $PATH
[error] [SshMcpServerManager] Failed to connect Figma: connect timeout; stderr:
[error] [RemoteStdioTransport:Control your Mac] process error: exec: "node": executable file not found in $PATH
[error] [SshMcpServerManager] Failed to connect Control your Mac: connect timeout; stderr:
[error] [RemoteProcess:<uuid>] Spawn failed: RPC call to process.spawn timed out

Even when node IS available on the remote (node v20.20.2 in PATH, verified), the transport still fails:

[warn] [RemoteStdioTransport:Figma] exited 1; stderr tail:
[error] [SshMcpServerManager] Failed to connect Figma: MCP error -32000: Connection closed

Note: stderr tail: is empty — node exits silently with code 1 because the JS file path being passed is a local Mac path that doesn't exist on the remote:

/Users/<macuser>/Library/Application Support/Claude/Claude Extensions/ant.dir.ant.figma.figma/server/index.js

I verified this by wrapping /usr/bin/node on the remote with a logging shim. The shim captured Desktop invoking node with /Users/... paths that obviously don't exist on a Linux server.

Contrast: plugins sync correctly

Interestingly, RemotePluginSync works fine — it copies 209+ files from Mac to remote before spawning ccd-cli, and passes --plugin-dir /home/claude/.claude/remote/plugins/<hash> (remote paths):

[info] [RemotePluginSync] Synced 209 file(s) from /Users/.../skills-plugin/... → /home/claude/.claude/remote/plugins/4d3224c6437bd19c
[info] [RemoteProcess] Spawning: /home/claude/.claude/remote/ccd-cli/2.1.111 ... --plugin-dir /home/claude/.claude/remote/plugins/4d3224c6437bd19c

So the sync-then-remap mechanism already exists for plugins. MCP extensions just aren't using it. They need the same treatment — either sync to remote and remap paths, or skip entirely for SSH sessions.

UX impact

Every session start triggers 15-second timeouts per MCP extension
Failures are silent in UI — user sees endless "Starting new session…"
Sometimes sessions succeed after timeouts; sometimes they never start
Non-obvious workaround (uninstall ALL MCP extensions AND connectors AND restart Desktop)
mcp-needs-auth-cache.json on the remote may also be involved — I found Google Drive/Gmail/Calendar listed there even though I never configured them on the remote user

Suggested fixes (in order of effort)

Quick: Add --disable-remote-mcp or skipLocalMcpInRemoteSessions toggle to settings
Better: Surface MCP spawn failures in UI instead of silently hanging
Proper: Extend RemotePluginSync mechanism to MCP extensions — sync the MCP server code to remote and remap paths before passing to ccd-cli

This bug has been open since February. Given the rising popularity of SSH-remote workflows (and how many users install Figma/Filesystem MCPs by default), a fix would help a lot of people.

Happy to provide more log excerpts or run further diagnostics if helpful.

bnguyen-lilly · 1 month ago

Hit a variant of this on an HPC cluster (SLURM/AWS ParallelCluster-style environment) behind a restrictive corporate egress proxy. In our case the remote path did get created (~/.claude/remote/plugins/<hash>/) and the plugin content was correctly copied over — but the SSH session hung indefinitely at "Setting up plugins..." because one plugin's install step (a Python-based plugin with a pyproject.toml) needed network access that the proxy silently drops rather than refuses. No timeout, no error, no indication of which plugin or host was blocking.
Workaround: removing all local plugin marketplaces (/plugin marketplace remove <name> for each) before connecting resolved it — confirms the hang comes from replicating the full local plugin/marketplace set to the remote with no opt-out.

Two separate gaps this suggests:
No timeout/error surfacing per-plugin during SSH session setup
Plugin/marketplace replication to SSH remotes has no independent opt-out from local config

Showing cached comments. Read the full discussion on GitHub ↗

SSH remote passes local plugin paths and MCP configs to remote server, causing hang

Bug Description

Root Cause

Steps to Reproduce

Expected Behavior

Environment

Related

7 Comments

Environment

Root cause components

Reproducible error signature

Contrast: plugins sync correctly

UX impact

Suggested fixes (in order of effort)

Related Claude Code issues

Browse by topic