SSH/Remote-Tools connection to Synology NAS fails: "Failed to upload file: No such file"

Summary

When bootstrapping an SSH remote connection (Remote Tools / local code sessions over SSH) in Claude Desktop, the app mixes two incompatible path namespaces when the SSH server (here: Synology DSM) runs SFTP in its own sandbox, separate from the regular shell filesystem.

Observed behavior

1. Claude Desktop creates directories via SSH shell exec: mkdir -p <absolute path>/.claude/remote/run/<id> and .../srv/<hash> — this succeeds because the path is resolved through the normal SSH shell (e.g. /var/services/homes/<user>/.claude/... on Synology, derived from $HOME).
2. It then tries to upload the actual files into that same path via a separate SFTP session — and fails with "No such file", because that absolute path does not exist in the server's SFTP namespace.

Root cause

Synology's internal-sftp subsystem presents its own sandboxed filesystem tree (only the shared folders directly under "/", e.g. /home, /homes/<user>), independent of the regular shell filesystem. Even /etc, /var, and /volume1 are not visible over SFTP, even though they're fully accessible via a normal SSH shell session. Claude Desktop appears to determine the target path exclusively via the shell ($HOME) and reuses it unchanged for SFTP operations, without checking whether that path is actually reachable in the SFTP namespace.

Reproduction (verified via manual SSH/SFTP testing)

$ ssh <host> 'echo $HOME'
/var/services/homes/<user>

$ sftp <host>
sftp> ls /var
Can't ls: "/var" not found

sftp> ls /
# only shows share names (home, homes, docker, ...) — no /var, /etc, /volume1

Suggested fix

Determine the SFTP target path via the SFTP session itself (e.g. realpath("~") over the SFTP protocol) instead of reusing the $HOME path obtained from the SSH shell — or surface a clear error on path mismatch instead of a generic "No such file".

Environment

• Claude Desktop (macOS)
• Target: Synology DSM 7.3.2