[BUG] SSH remote silently drops all prompts — strace confirms no data on stdin (fd 0)

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?

When using the Claude Code Desktop app on Windows with an SSH remote connection to WSL2 (NAT networking, non-root user), prompts submit without error but no response is ever returned. The UI remains interactive — you can keep typing and submitting prompts indefinitely — but nothing happens. No error, no loading indicator, no timeout. The prompt appears to be accepted but silently goes nowhere.

This is not the same as #27325 or #29761 where the submit button is greyed out / disabled. In this case the UI appears fully functional but the backend communication is broken.

Root Cause (traced via strace)

The Desktop app's SSH tunnel is not piping stdin to the remote ccd-cli process. The remote binary launches correctly, authenticates with the API, and establishes connections — but never receives any prompt data on stdin.

Finding 1: Remote binary spawns and runs correctly

The Desktop app successfully deploys and launches the remote binary:

$ ps aux | grep -i ccd
user  1868  0.5  0.8 74494288 281604 ?  Sl  21:06  0:07 /home/user/.claude/remote/ccd-cli/2.1.87 --output-format stream-json ...

Full command line:

/home/user/.claude/remote/ccd-cli/2.1.87 --output-format stream-json --verbose --input-format stream-json --effort medium --model claude-opus-4-6 --permission-prompt-tool stdio --setting-sources user,project,local --permission-mode acceptEdits --allow-dangerously-skip-permissions --include-partial-messages

Finding 2: API connections are established successfully

The remote process opens multiple TCP connections to Anthropic's API:

$ ss -tnp | grep 3876
ESTAB 0  0  172.23.x.x:57582 160.79.104.10:443  users:(("2.1.87",pid=3876,fd=20))
ESTAB 0  0  172.23.x.x:57566 160.79.104.10:443  users:(("2.1.87",pid=3876,fd=19))
ESTAB 0  0  172.23.x.x:57556 160.79.104.10:443  users:(("2.1.87",pid=3876,fd=17))
ESTAB 0  0  172.23.x.x:57542 160.79.104.10:443  users:(("2.1.87",pid=3876,fd=16))

Finding 3: stdin (fd 0) receives no data — prompts never arrive

When tracing writes while submitting a prompt from the Desktop app, the process only writes to internal file descriptors (fd 6), never stdout (fd 1):

$ strace -p 3876 -f -e trace=write 2>&1
[pid  3914] write(6, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  3891] write(6, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  3888] write(6, "\1\0\0\0\0\0\0\0", 8) = 8
(repeating — only internal event loop heartbeats)

When tracing reads while submitting a prompt, only internal fd 14 shows activity — fd 0 (stdin) is completely silent:

$ strace -p 3876 -f -e trace=read 2>&1
[pid  3890] read(14, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  3890] read(14, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  3890] read(14, "\1\0\0\0\0\0\0\0", 8) = 8
(repeating — no reads on fd 0, prompt never arrives)

This confirms the Desktop app is not piping prompt data through the SSH tunnel to the remote process's stdin.

Finding 4: Desktop app spawns orphaned duplicate processes

Each time a prompt is submitted or a reconnection occurs, the Desktop app spawns a new ccd-cli process without killing the previous one:

$ ps aux | grep -i ccd
user  1868  0.5  0.8 74494288 281604 ?  Sl  21:06  0:07 /home/user/.claude/remote/ccd-cli/2.1.87 --output-...
user  3876  4.4  0.8 74494232 281560 ?  Sl  21:29  0:00 /home/user/.claude/remote/ccd-cli/2.1.87 --output-...

Both processes have identical command lines. PID 1868 has zero network connections — fully orphaned. PID 3876 has the active API connections but still receives nothing on stdin.

What Should Happen?

When a prompt is submitted in the Desktop app, the prompt data should be piped through the SSH tunnel to the remote ccd-cli process's stdin as stream-json. The process should receive it, send it to the API, and stream the response back via stdout to the Desktop app.

Additionally, the Desktop app should not spawn duplicate remote processes without terminating the previous one.

Error Messages/Logs

No error messages are shown in the Desktop app UI. The UI remains fully interactive with no indication of failure.

Steps to Reproduce

1. Open Claude Code Desktop app on Windows
2. Create an SSH remote connection to a WSL2 instance (NAT networking)
3. Connect and select a working folder (this succeeds)
4. Type any prompt and submit
5. Observe: prompt appears to submit, no response ever arrives, UI remains interactive
6. Submit additional prompts — same behavior, additional orphaned ccd-cli processes accumulate on the remote

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

N/A — SSH remote to WSL2 is only something i am trying out now

Claude Code Version

Desktop app: latest Windows version Remote ccd-cli: 2.1.87

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

• WSL2 is using default NAT networking (not mirrored)
• SSH connection is to localhost (WSL2)
• Non-root user
• Claude Code CLI is not installed on the WSL2 side — the Desktop app deploys its own binary to ~/.claude/remote/ccd-cli/
• Related issues: #27165, #27325, #29761 — similar symptoms but different root causes. Those issues report a disabled/greyed-out submit button. This issue has a fully functional UI where the stdin pipe over SSH is silently broken.