[BUG] Desktop SSH remote BinaryDeployment deploys linux-x64-musl to a glibc WSL2 host; fails "not runnable" / statx: symbol not found

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?

Connecting the Claude Desktop Code tab over SSH to a local WSL2 Ubuntu 22.04 (glibc) host fails to install the remote CLI. BinaryDeployment selects the linux-x64-musl variant for a glibc system. The deployed binary cannot run, the runnable-check fails, ~/.claude/remote/ccd-cli/<version>/ is left empty, and the connection aborts with: Failed to install Claude CLI: installed cli at /home/<user>/.claude/remote/ccd-cli/2.1.181 is not runnable.Root cause matches #14537: the host has Ubuntu's musl package installed (providing /lib/libc.musl-x86_64.so.1 for cross-compilation), which appears to trip libc detection into choosing musl, even though the system is glibc.Environment:

Claude Desktop: 1.14271.0 (c8f4d8), 2026-06-18
Client OS: Windows 11
Remote: WSL2, Ubuntu 22.04, glibc 2.35 (ldd (Ubuntu GLIBC 2.35-0ubuntu3.13) 2.35)
file /bin/ls → interpreter /lib64/ld-linux-x86-64.so.2 (glibc)
System has musl 1.2.2 installed (from 2021), so /lib/libc.musl-x86_64.so.1 is present
SSH: alex@127.0.0.1:22, key auth; ssh "echo OK" and ssh "claude --version" (→ 2.1.183) both succeed manually
Native claude 2.1.183 installed and working in WSL

What Should Happen?

BinaryDeployment should deploy the linux-x64 (glibc) variant on a glibc host. Detection should not rely on the mere presence of /lib/libc.musl-x86_64.so.1 (installed by Ubuntu's musl cross-compilation package). As suggested in #14537 and SDK issue #296: detect the actual libc (interpreter of /bin/ls, or ldd /bin/ls), or spawn-probe each variant and accept the first that runs.

Error Messages/Logs

Relevant log (ssh.log):
[BinaryDeployment] Remote CLI fetch failed, falling back to SFTP: installed cli at .../ccd-cli/2.1.181 is not runnable
[BinaryDeployment] SFTP upload progress: claude.zst (linux-x64-musl) ... 53115330/53115330B
[RemoteServerController] Connection failed: Failed to install Claude CLI: ... ccd-cli/2.1.181 is not runnable
Note the (linux-x64-musl) variant tag.
Proof the deployed binary is musl and unrunnable on this glibc host:

Captured the binary mid-deploy and tested offline:
$ file ccd-test
ELF 64-bit LSB executable, x86-64, interpreter /lib/ld-musl-x86_64.so.1, ...
$ ldd ccd-test
libc.musl-x86_64.so.1 => not found        # before workaround
$ ldd ccd-test                             # after symlinking system musl libc
libc.musl-x86_64.so.1 => /lib/libc.musl-x86_64.so.1
$ ./ccd-test --version
Error relocating ccd-test: statx: symbol not found
Even with the musl libc resolvable, the binary requires statx, absent from musl 1.2.2 — so the musl variant is unrunnable here regardless.

Steps to Reproduce

1. On a Windows host with WSL2 running Ubuntu 22.04 (glibc), install the

musl package inside the distro: sudo apt install musl
(this is the key precondition — it creates /lib/libc.musl-x86_64.so.1)

1. Confirm the system is glibc, not musl:

• ldd --version → glibc 2.35
• file /bin/ls → interpreter /lib64/ld-linux-x86-64.so.2

1. Ensure sshd is running in the distro and key auth works from Windows:

ssh alex@127.0.0.1 "echo OK" → prints OK

1. In Claude Desktop → Code tab, add an SSH connection to the WSL host

(Host: alex@127.0.0.1, Port: 22, key: ~/.ssh/id_ed25519) and select a
project folder.

1. Open a session / send any prompt to trigger remote CLI deployment.
2. Observe the connection fail with: "Failed to install Claude CLI:

installed cli at ~/.claude/remote/ccd-cli/<version> is not runnable"

1. Confirm the wrong variant was chosen — in ssh.log:

"[BinaryDeployment] ... claude.zst (linux-x64-musl) ..."
and ~/.claude/remote/ccd-cli/<version>/ is left empty.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.14271.0 (c8f4d8) 2026-06-18T05:47:57.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Workarounds / confirmation that musl presence is the trigger:

None on the remote side make the musl variant run (would require musl ≥ ~1.2.5 for statx). The system's musl is what triggers misdetection, so the test is to remove it:
bash# 1. Remove the cross-compilation musl package that provides the false-positive marker
sudo apt remove musl

(also remove any manual symlinks if present)

sudo rm -f /lib/libc.musl-x86_64.so.1 /lib/x86_64-linux-musl/libc.musl-x86_64.so.1

2. Confirm the marker file is gone

ls -la /lib/libc.musl-x86_64.so.1 # should be: No such file or directory

3. Reconnect from Claude Desktop

With the /lib/libc.musl-x86_64.so.1 marker absent, detection should fall through to linux-x64 (glibc), which runs natively on this host. If reconnecting after removal deploys the glibc variant and succeeds, that confirms the marker-file presence is the trigger — matching the install.sh logic identified in #14537. (Caveat: only remove musl if nothing else on the system depends on it for cross-compilation.) I'll update this issue with the post-removal result.
Scope of fix: Please confirm whether the fix should cover both the standalone installer (#14537) and this Desktop remote BinaryDeployment path — they appear to share the detection flaw but are separate code paths, so fixing one may not fix the other.