Desktop app generates a new plugin hash dir on every remote SSH connection — plugins re-upload each time and accumulate indefinitely
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?
Summary
When using the Claude Code Windows desktop app to connect to a remote SSH server, the app creates a fresh
hash-named directory under ~/.claude/remote/plugins/ on every single connection — even when reconnecting to
the same workspace path. Each new dir triggers a full re-upload of the same plugin tarballs and a fresh
"Setting up plugins…" step. Over a single day's worth of normal reconnects this accumulated to 30 identical
copies of anthropic-skills@1.0.0 in my remote plugins dir.
Environment
- Desktop app: Claude Code for Windows (please add your version — Settings → About)
- Remote server CLI: 2.1.121 (from ~/.claude/remote/ccd-cli/)
- Remote OS: CloudLinux 8.10, kernel 4.18.0-553.111.1.lve.el8.x86_64, x86_64
- CloudLinux CageFS: present (per-user filesystem isolation)
- Connection: standard OpenSSH with key auth as user claudeadmin
- Workspace: same folder on every reconnect (/home/<sitename>/public_html)
Steps to reproduce
- From the Windows desktop app, open a remote workspace at a path on the SSH server.
- Wait for plugins setup to complete and the CLI session to start.
- Disconnect the desktop app.
- Reconnect to the same folder.
- Observe ~/.claude/remote/plugins/ on the server.
Expected
- Plugin install location is keyed deterministically (e.g., on workspace path or plugin identity) so
reconnections reuse the existing dir and skip "Setting up plugins…".
Actual
- Each reconnect creates a brand-new hash dir, e.g. (real hashes from one user's day):
ad26ee25d8e8af15 anthropic-skills@1.0.0 2026-05-04 19:48
53f66aa16b83d141 anthropic-skills@1.0.0 2026-05-04 20:22
440ab60d659c62c9 anthropic-skills@1.0.0 2026-05-04 20:25 (partial — failed)
327c7c5d80e50417 anthropic-skills@1.0.0 2026-05-04 20:29
- All four were created reconnecting to the same workspace path.
- Each new connect causes a fresh ~516KB plugin tarball upload + extraction.
- Over hours of normal use, ~30 duplicate dirs accumulated, all containing the same anthropic-skills v1.0.0.
Downstream issues observed
- Slow handshake on every connect — UI sits at "Setting up plugins…" while the same plugin tarball uploads
again.
- Plugin dir growth is unbounded — naive cleanup is not safe because the live CLI process holds the most
recent dir open.
- Stacked --serve processes — when a reconnect happens before the previous server's connection cleanup,
multiple ~/.claude/remote/server --serve processes stack up trying to bind the same rpc.sock. Saw 3
simultaneously after rapid reconnects; the desktop app's handshake then hung indefinitely.
- Stalled uploads leave partial tarballs — partial tar.gz files sit in the plugins dir after a failed
handshake; nothing cleans them up.
- CLI re-download — on first install, the 247MB CLI archive downloaded from downloads.claude.ai repeatedly
because the install logic didn't recognize the cached file as valid. Three concurrent --install processes
ran for 5–16 minutes each.
Suggested fix direction
- Hash plugin install dirs by (plugin_source, version) (or workspace + plugin), not by per-connection state.
- Before spawning a new --serve, check for and reuse an existing one.
- After successful install, clean stale partial tarballs and dirs older than the active one.
What Should Happen?
- Hash plugin install dirs by (plugin_source, version) (or workspace + plugin), not by per-connection state.
- Before spawning a new --serve, check for and reuse an existing one.
- After successful install, clean stale partial tarballs and dirs older than the active one.
Error Messages/Logs
Steps to Reproduce
see summary
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
latest
Platform
Other
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
_No response_
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗