[BUG] SSH binary deployment fails on Synology NAS — incompatible internal-sftp implementation

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's SSH session fails to deploy the remote binary to a Synology DSM NAS. SSH authentication and connection succeed, but binary upload via SFTP fails immediately with Failed to upload file: No such file.

The root cause is that Synology's bundled internal-sftp implementation (sftp-synolib) interprets the first component of an absolute path as a "share name" rather than a filesystem path, and rejects paths that don't begin with a recognized share. When Claude Desktop reads the user's home directory from the SSH session (which Synology reports as /var/services/homes/<user>) and uses that absolute path for SFTP upload, Synology's SFTP server rejects it with not found share [var].

There is currently no client-side workaround because the SSH connection dialog only exposes Name, Host, Port, and Identity File — no field to override the remote installation path. Server-side workarounds also fail or are unsafe (see "Steps to Reproduce" for details).

What Should Happen?

Claude Desktop should successfully deploy and run its remote binary on Synology NAS, OR provide a way for users to override the remote installation path so they can specify a SFTP-compatible location (e.g., /homes/<user>/.claude-ssh instead of /var/services/homes/<user>/.claude-ssh).

Suggested fix: Add a "Remote installation path" field to the SSH connection dialog. When provided, the binary deployment should target that path instead of the resolved $HOME.

Error Messages/Logs

Claude Desktop log (%APPDATA%\Claude\logs\ssh.log):
[info] [SSH2Connection] Connected to <user>@<masked-host>:<port>
[info] [BinaryDeployment] Remote: home=/var/services/homes/<user>, platform=linux, arch=amd64
[info] [BinaryDeployment] Deploying binary from C:\Users\<user>\AppData\Roaming\Claude\claude-ssh-remote\<hash>\claude-ssh-linux-amd64
[error] [RemoteServerController] Connection failed (XXXms, trigger: send_message): Failed to upload file: No such file
The local binary file exists and is intact (5,894,296 bytes, verified with Test-Path and Get-Item).
Synology server log (/var/log/messages), captured during failed attempts:
<host> internal-sftp[XXXX]: sftp-synolib.c:105 not found share [var]
This error fires once per retry. The string not found share [var] is emitted by Synology's proprietary sftp-synolib library when it receives a path beginning with /var/... and tries to interpret var as a Synology share name.
Synology SFTP architecture (root cause):
Synology DSM does not ship the standard OpenSSH sftp-server binary:
$ find / -name "sftp-server" 2>/dev/null
(no results)

$ sudo grep -i "subsystem" /etc/ssh/sshd_config
Subsystem sftp internal-sftp -f DAEMON -u 000
DSM uses a custom implementation that serves files relative to share-folder roots, not the actual filesystem layout. User homes are exposed as /var/services/homes/<user> over SSH (a symlink to /volume1/homes/<user>), but the SFTP layer only recognizes paths under share names like /homes/<user>.

Steps to Reproduce

1. Configure an SSH connection in Claude Desktop pointing to a Synology NAS user account (host, port, identity file)
2. Verify SSH login works — connection succeeds and the home directory is correctly detected as /var/services/homes/<user>
3. Send any message in the Code session
4. Observe: connection fails immediately with Failed to upload file: No such file in the UI; server log shows sftp-synolib.c:XXX not found share [var]

Things I tried that did not work:

• Reinstalling Claude Desktop (both Microsoft Store/MSIX and standalone .exe variants — same result on both)
• Cleaning the local binary cache and re-downloading the remote payload
• Setting Subsystem sftp /usr/libexec/sftp-server in sshd_config — fails because that binary doesn't exist on DSM
• Verifying SFTP service is enabled in DSM Control Panel
• Confirming user home service is enabled, permissions are correct, and the user can write to the target directory
• Switching between hostname, internal IP, and SSH config alias — same SFTP error in all cases

Workarounds that exist but are unsafe to apply:

• Installing OpenSSH sftp-server via Entware/opkg — risky because /opt is already used by Synology Container Manager (/opt/containerd), and DSM updates can wipe /opt
• Modifying /etc/passwd to change the user's home path — breaks other DSM services and is reverted on firmware updates
• Replacing Synology's sshd_config Subsystem line — DSM may regenerate it on package updates

Related Issues

SchoofsKelvin/vscode-sshfs#408 reports the same root cause (Synology internal-sftp incompatibility) for a different SFTP-using client, with identical diagnostics (find / -name sftp-server returns nothing; Subsystem sftp internal-sftp -f DAEMON -u 000). That issue remains unresolved on the client side.

Impact

Synology NAS is one of the most popular self-hosted server platforms used by developers as a remote dev target. Without a way to override the remote installation path, Claude Desktop's SSH mode is effectively unusable for this user segment.

I'm happy to test any patch or provide additional logs.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.112 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_