[BUG] Skills in ~/.claude/skills/ not discovered by Desktop Remote (SSH) sessions, even after full restart + new session

Status Open
Reported on v2.1.258
Maintainer reply None cached
Activity 2 comments · opened Sep 3, 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?

Custom skills placed in ~/.claude/skills/<name>/SKILL.md on a remote Linux host are not discovered/registered as slash commands when connecting via Claude Desktop's Remote (SSH) feature. This happens even after fully killing all running ccd-cli processes on the host, restarting Claude Desktop entirely, and starting a genuinely new chat/session (not resume/continue).

What Should Happen?

Personal skills in ~/.claude/skills/ on the remote host should be discovered the same way they are in a plain terminal SSH session, regardless of whether the connection goes through Desktop's Remote (SSH) bridge. A fresh session should pick up any skill present on disk at session start.

Error Messages/Logs

None shown in the UI. No errors observed on the host side either — the skills simply don't appear when asking "what slash commands are available?" by typing "/" and expecting a list of available personal skills.

Steps to Reproduce

  1. On the remote Linux host, confirm skills exist at ~/.claude/skills/<name>/SKILL.md (folder-per-skill structure, correct lowercase naming — confirmed via ls -la ~/.claude/skills, e.g. folders bitbucket-file-content, code-review, commit, handoff, etc.)
  2. In Claude Desktop (on a separate Windows machine), connect via Remote (SSH) to the Linux host.
  3. Start a brand-new chat/session (not resume/continue).
  4. Type "/".
  5. Observe: the skills present in ~/.claude/skills/ do not appear.
  6. As a troubleshooting step, kill all existing ccd-cli processes on the host (ps aux | grep claude), fully restart Claude Desktop, and repeat steps 3–5 — issue persists.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.258 (also observed on 2.1.246, 2.1.247, 2.1.255 across multiple sessions on the same host)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Platform - other: Claude Desktop app connecting via Remote (SSH) to a self-managed Linux host (not API/Bedrock/Vertex directly)

  • ps aux on the host shows Desktop spawning ccd-cli processes with --plugin-dir /home/<user>/.claude/remote/plugins/<hash> flags per session, plus a persistent bridge process: server --bridge --socket .../rpc.sock. This suggests Desktop's remote session setup may sync/scope certain assets differently than a plain terminal SSH session, and ~/.claude/skills/ may not be included in whatever gets passed through that bridge path.
  • Launch flags for these processes include --setting-sources=user,project,local, so user scope is present, ruling out a scope-flag issue.
  • Already ruled out: folder casing (lowercase skills, confirmed), folder structure (each skill has its own subfolder + SKILL.md, not a bare .md file), and stale process reuse (fresh session after full restart still fails).

View original on GitHub ↗

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