[BUG] Desktop SSH remote: server binary upload fails with ENOENT after app update (srv/<hash>/ never created)

Environment

• Claude desktop app 2.37337.1, macOS 26.6
• Remote: Ubuntu 24.04.5 LTS, x86_64, Claude Code 2.1.282, plain OpenSSH via an ~/.ssh/config host alias (no chroot / virtual SFTP root)

What happens

After a desktop app update, connecting to the SSH remote fails with:

Couldn't upload to the remote (server binary): a required file or directory is missing [ENOENT]

It auto-retries 3 times, then gives up.

Cause

The app uploads the new server binary to ~/.claude/remote/srv/<hash>/server.<id>.part without first creating srv/<hash>/. The directory doesn't exist, so the SFTP upload fails. srv/ itself exists and is writable; it already holds folders for older server versions.

From ~/Library/Logs/Claude/ssh.log:

[BinaryDeployment] Deploying server binary linux-amd64 to ~/.claude/remote/srv/52d82f0a28317830ccacea80f6f4aac1d7563353 (remote=missing, local=52d82f0a…)
[BinaryDeployment] SFTP upload failed (~/.claude/remote/srv/52d82f0a…/server.2d4bc547.6c02906b.part): No such file
[RemoteServerController] Auto-reconnect exhausted after 3 attempt(s) (liveProcesses=0); emitting disconnect

Workaround

mkdir -m 700 ~/.claude/remote/srv/<hash> on the remote, then retry in the app.

Recurrence and related failures

Happened on 2026-10-12 (server c8e2f083…, on two different Macs) and again on 2026-10-14 (server 52d82f0a…), each time right after an app update. In the 2026-10-12 case, deployment then failed twice more once the directory existed:

1. NO_INSTALL_RESULT: the upload completed but was left as server.*.part and never renamed to server. Fixed by checking sha256 against the Mac's copy and renaming it by hand.
2. RPC transport closed during capability handshake (shown in the UI as "SSH handshake did not finish"): the daemon never started and run/<run>/rpc.sock was missing. Worked after starting srv/<hash>/server --serve --socket <abs>/run/<run>/rpc.sock --token-file <abs>/run/<run>/token.* by hand.

Possibly related, but with different causes: #78493 (Synology SFTP root), #77753 (WSL, root-owned binary).

Expected

The app creates srv/<hash>/ (like mkdir -p) before uploading, renames the .part file once it's verified, and starts the daemon.