Remote Control (Windows Desktop → Linux VPS): ccd-cli upload fails with fork/exec ENOENT because Windows binary is sent to Linux server

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?

Environment

• Claude Code Desktop version: 2.1.116 (Windows)
• Remote server OS: Debian 13 (trixie), x86-64 Linux
• Connection type: Remote Control via SSH

What happened

When using Claude Code Desktop on Windows to connect to a Linux VPS via Remote Control, the connection repeatedly fails with:

Failed to spawn Claude Code process: fork/exec /home/melih/.claude/remote/ccd-cli/2.1.101: no such file or directory

This failure persists for 1–2 minutes on every reconnect after idle, making the feature effectively unusable.

Root cause (reverse engineered)

Through strace, inotifywait, /proc inspection, and server log analysis, we identified the exact failure sequence:

1. Desktop SSHes to VPS and uploads remote/server (the 5.9MB Go relay binary — correct, this is the Linux binary)
2. remote/server starts and checks ~/.claude/remote/ccd-cli/ for the expected ccd-cli version
3. The version doesn't match → server marks the binary as "being updated" internally
4. Desktop tries to upload a replacement ccd-cli binary from its local machine (Windows) — this is a Windows PE binary, not a Linux ELF
5. During the upload (or even just the attempt), the server's internal state marks 2.1.101 as unavailable
6. Every process.spawn RPC call during this window returns fork/exec ... no such file or directory
7. After ~2 minutes, the upload times out / is abandoned
8. Server falls back to whatever exists in ccd-cli/ and spawning works again
9. On next reconnect after idle, cycle repeats

Key evidence:

• inotifywait watching the ccd-cli directory shows zero file events during failure window — the file is not actually deleted
• SSH exec of the same binary from the same user succeeds during the failure window
• The ENOENT comes from the server binary's internal state, not from the actual filesystem
• The uploaded binary (when it completes) is a Windows PE file and cannot run on Linux

The fix needed

The Windows installer should ship claude-ssh-linux-amd64 (the Linux ccd-cli binary) alongside the Windows binary, and upload that to Linux VPS targets instead of the local Windows binary. This was previously requested in #26536 (closed as Not Planned).

Alternatively, the remote/server binary should detect the target OS and pull the appropriate binary from npm (@anthropic-ai/claude-code) which is already installed on the VPS, rather than uploading from the client.

Workaround

Manually copy the Linux binary from the npm package already installed on the VPS:

cp /usr/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe ~/.claude/remote/ccd-cli/2.1.116
cd ~/.claude/remote/ccd-cli && ln -sf 2.1.116 2.1.101

This must be re-applied after every Desktop auto-update that changes the expected version.

Expected behavior

Remote Control should work from Windows to Linux without manual binary management. The server should use the Linux binary already present on the VPS.

Additional context

• The claude.exe binary in @anthropic-ai/claude-code/bin/ on Linux is actually a Linux ELF binary (the .exe extension is misleading) — it works perfectly as ccd-cli once placed in the right location
• The remote/server relay binary IS correctly uploaded as a Linux binary — only the ccd-cli upload is broken
• Related: #26536 (claude-ssh-linux-amd64 missing from Windows installer, closed Not Planned)

What Should Happen?

aDesktop Remote Control should work reliably on Windows → Linux VPS setups. Either: (a) the Windows Desktop installer should include the Linux ELF ccd-cli binary to upload to remote Linux servers, or (b) the server should detect the OS mismatch and skip the upload when the existing binary is already the correct architecture. Connection should succeed immediately without a 1-2 minute ENOENT failure window.

Error Messages/Logs

Failed to spawn Claude Code process: fork/exec /home/melih/.claude/remote/ccd-cli/2.1.101: no such file or directory

Steps to Reproduce

a1. Install Claude Code Desktop on Windows

1. Set up a Linux VPS (Debian/Ubuntu) with Claude Code installed via npm
2. 3. Configure Desktop to connect to the VPS via Remote Control
3. 4. Open any project in Desktop using Remote Control to the Linux VPS
4. 5. Send a message — observe "Failed to spawn Claude Code process: fork/exec ... no such file or directory"
5. 6. Wait ~2 minutes and try again — it works briefly, then fails again on next reconnect after idle

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.116 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_