For anyone at Anthropic triaging this: below is the confirmed root cause and exact workaround on a fresh VPS.

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When connecting Claude Desktop (macOS) to a remote VPS via SSH for the first time, the Code tab appears to connect successfully (the bottom status bar shows the correct host and project path), but every message sent produces zero output. No error message, no warning, no dialog — complete silence.

This is caused by ccd-cli (the remote Claude Code CLI binary that the desktop bootstraps on the VPS) presenting an interactive first-run setup wizard (theme picker + Anthropic account login) when it has never been run before. The desktop spawns ccd-cli non-interactively via a JSON stdin pipe and immediately sends an initialize payload — but ccd-cli is not ready to accept JSON yet; it is waiting for the user to interact with the wizard. It receives non-TTY input it cannot handle, exits with code 1, and the desktop receives that silent failure with no UI feedback whatsoever.

This will affect every user who sets up a fresh VPS as a Claude Code Desktop SSH remote and connects via the desktop app as their first interaction with that machine. The desktop gives no indication that a manual setup step is required first.

What Should Happen?

When a user connects Claude Desktop to a fresh VPS via SSH for the first time, the desktop should detect that ccd-cli has not completed its first-run setup and either:

1. Automatically handle the first-run flow in-app (guided setup wizard inside Claude Desktop), OR
2. Display a clear, actionable error message such as: "Remote setup required. SSH into your server and run: ~/.claude/remote/ccd-cli/[version] — then return here and try again."

At minimum, the app must never silently fail. An exit code 1 from ccd-cli should surface a human-readable error in the UI, not invisible silence.

Error Messages/Logs

# From ~/.claude/remote/remote-server.log on the VPS:
[Server] New connection from: @
[Server] RPC request: method=server.ping, id=1
[Server] RPC response sent: id=1, hasError=false
[Server] RPC request: method=process.spawn, id=3
[shellenv] Extracted shell PATH (98 chars)
[process.Manager] Process 6ca20afc started, PID=170777, command=/root/.claude/remote/ccd-cli/2.1.92
[process.Manager] WriteStdin: wrote 429 bytes (initialize JSON payload)
[process.Manager] Read 93 bytes from stderr  <-- ccd-cli first-run wizard output
[process.Manager] stderr EOF
[process.Manager] Process 6ca20afc exited with code 1  <-- crash
[process.Manager] stdout EOF
[process.Manager] writeFrame: exit

# No error or warning of any kind is shown in the Claude Desktop UI.
# Running ccd-cli manually in a terminal on the VPS shows the first-run theme picker wizard,
# confirming the binary is trying to run an interactive TUI that cannot work over a non-TTY stdin pipe.

Steps to Reproduce

Prerequisites: A fresh Linux VPS (Ubuntu/Debian) where Claude Code's ccd-cli has never been run. SSH key auth works from your Mac terminal.

1. Open Claude Desktop on macOS → click the Code tab.
2. Click the + or SSH connection button to add a remote.
3. Enter your VPS details: Host your-vps-ip, Port 22, User root (or any user), key ~/.ssh/id_ed25519.
4. Select a project folder on the VPS (e.g. /root/myproject).
5. Confirm the status bar at the bottom of the Code tab now shows root@your-vps-ip · /root/myproject — it looks connected.
6. Type any message, for example: "Run pwd and ls and show me the output." and press Enter.
7. Observe: Claude accepts the message. Nothing ever appears. No output, no error, no spinner, no dialog. The UI is completely frozen/silent on that request.
8. Restart the app, try a new session — same result every time.

Why it happens (confirmed via server logs): The desktop successfully bootstraps the remote server binary. However, when it spawns ccd-cli to handle your request, ccd-cli immediately shows an interactive first-run wizard (theme selector + Anthropic account login). Since the desktop is communicating with it via a non-interactive JSON pipe (not a real terminal), ccd-cli crashes with exit code 1. The desktop receives this failure with no UI feedback.

The fix (workaround until Anthropic patches this): You must run ccd-cli manually once on the VPS to complete its first-run setup, BEFORE using it from Claude Desktop.

Steps:

# SSH into your VPS from your Mac terminal first:
ssh -i ~/.ssh/id_ed25519 root@your-vps-ip

# Find the ccd-cli binary (the version number may differ):
ls ~/.claude/remote/ccd-cli/

# Run it interactively:
~/.claude/remote/ccd-cli/2.1.92

You will see a setup wizard. Complete it:

• Press 1 then Enter to choose Dark mode (or whichever theme you prefer)
• Choose login via Claude.ai / Anthropic Console
• A browser will open on your Mac to platform.claude.com — log in
• Paste the authentication code back into the terminal when prompted
• Wait for "Ready" confirmation
• Press Ctrl+C to exit

Now return to Claude Desktop, open a new Code session for the same SSH remote, and send a message. It will work.

Related issues: #43852, #43252, #26562

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.92 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Plan: Max App type: Claude Desktop (unified Chat/Cowork/Code build, NOT the standalone Claude Code CLI) Remote VPS: Linux (Debian/Ubuntu), fresh setup, running as root SSH key: Ed25519, no passphrase, key-based auth confirmed working in Terminal

This issue is specifically with the desktop app's SSH remote feature, not the CLI. The desktop bootstraps the remote server binary automatically, which worked correctly. The failure only occurs at the ccd-cli spawn step due to first-run interactive state.

The workaround described in Steps to Reproduce is confirmed working and immediately resolves the issue. This report is filed so others do not spend hours debugging what appears to be a connection problem but is actually a one-time first-run setup requirement that the desktop app never communicates.