[BUG] Remote SSH session crashes immediately with exit code 1 on Max/OAuth accounts (ccd-cli 2.1.128)

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 I try to start a Claude Code session on a remote host via the SSH connection feature in Claude Desktop, the session crashes immediately with the generic error:

"Claude Code crashed. Try sending your message again. If it keeps happening, share feedback so we can investigate. Claude Code process exited with code 1"

The same setup works perfectly when I select "Local". It only fails when targeting any of my SSH connections.

The remote-server log shows the RPC handshake completes successfully (capabilities, ping, file reads, tar extractions all OK), the ccd-cli binary is spawned, the initialize control_request is written to its stdin (1608 bytes), and then the process exits with code 1 within ~1 second. No stderr is surfaced anywhere in the UI.

Critically: the same ccd-cli binary on the same remote host runs perfectly when I invoke it manually over plain SSH. It launches the full TUI, OAuth login works, sessions persist, and even piping the same initialize JSON payload to its stdin manually works (exit 0, sensible response on stdout, empty stderr). The crash only happens when Claude Desktop spawns it remotely.

I'm on a Claude Max plan and authenticated via OAuth (no API key configured). I suspect this may be related to how credentials are propagated to the remote process — looking at --help, there's a --bare mode that explicitly states "OAuth and keychain are never read" and requires ANTHROPIC_API_KEY. If Claude Desktop invokes the remote binary in a mode that bypasses OAuth, that would explain why Max/OAuth users hit this. This is just a hypothesis though — I could not capture the exact argv because the process dies too fast to inspect via /proc.

The UX is also rough: the error message gives no actionable info, no link to logs, no hint that ~/.claude/remote/remote-server.log even exists. It took manual debugging (running the binary standalone, piping JSON to stdin, reading flag docs) to narrow this down. Surfacing the child process's stderr to the desktop UI would help a lot.

What Should Happen?

Selecting an SSH connection in Claude Desktop should start a Claude Code session on the remote host with the same authentication context as the local session. The OAuth credentials from my Claude Desktop login should propagate to the remote ccd-cli process so that Max/Pro/Team users without an ANTHROPIC_API_KEY can use the remote SSH feature out of the box, with no manual onboarding required on the remote.

If the remote process fails for any reason, its stderr should be surfaced to the user in the desktop UI (or at minimum, a clear pointer to the log file location), instead of the generic "exited with code 1" message.

Error Messages/Logs

Desktop UI error:
  Claude Code crashed
  Try sending your message again. If it keeps happening, share feedback so we can investigate.
  Claude Code process exited with code 1

Relevant excerpt from ~/.claude/remote/remote-server.log:

2026/05/06 18:19:38 [Server] RPC request: method=process.spawn, id=33
2026/05/06 18:19:38 [shellenv] Extracted shell PATH (98 chars)
2026/05/06 18:19:38 [process.Manager] Process cbba0814-17b2-4b8c-ab14-f06ad4344aa4 started, PID=1424749, command=/home/<user>/.claude/remote/ccd-cli/2.1.128
2026/05/06 18:19:38 [Server] RPC response sent: id=33, hasError=false
2026/05/06 18:19:38 [process.Manager] Starting stdout streaming for process cbba0814-...
2026/05/06 18:19:38 [process.Manager] Starting stderr streaming for process cbba0814-...
2026/05/06 18:19:38 [Server] RPC request: method=process.stdin, id=37
2026/05/06 18:19:38 [process.Manager] WriteStdin called for process cbba0814-... with 1608 bytes
2026/05/06 18:19:38 [Server] RPC response sent: id=37, hasError=false
2026/05/06 18:19:38 [process.Manager] drainStdin cbba0814-...: 1608 bytes, preview "{\"request_id\":\"x6oyid3ifcc\",\"type\":\"control_request\",\"request\":{\"subtype\":\"initialize\",\"hooks\":{\"Pre..."
2026/05/06 18:19:39 [process.Manager] Process cbba0814-... exited with code 1

The exit happens roughly 1 second after stdin is written. No stderr lines from the ccd-cli child appear in the log despite "Starting stderr streaming" being logged. This is consistent across multiple reproductions (process IDs cbba0814-... and ddf26d67-... both exit with code 1 the same way).

Sanity checks I ran on the remote (all pass):
- file ccd-cli/2.1.128       → ELF 64-bit LSB, x86-64, dynamically linked, for GNU/Linux 3.2.0
- ldd ccd-cli/2.1.128         → all libraries resolve, no "not found"
- ldd --version               → glibc 2.39 (Ubuntu 24.04)
- uname -m                    → x86_64
- ccd-cli/2.1.128 --version   → 2.1.128 (Claude Code)
- ccd-cli/2.1.128 (run manually)  → full TUI loads, OAuth works, "Welcome back <name>!", Opus 4.7, Claude Max
- echo '{"request_id":"test","type":"control_request","request":{"subtype":"initialize","hooks":{}}}' | ccd-cli/2.1.128
                              → exit 0, sensible response, empty stderr

So the binary is healthy. The failure is environmental — something about how Claude Desktop spawns it.

Steps to Reproduce

1. Sign into Claude Desktop with a Claude Max account (OAuth login, no ANTHROPIC_API_KEY set).
2. Add an SSH connection to a Linux remote (Ubuntu 24.04 x86_64 in my case, glibc 2.39).
3. From the Claude Code panel in Claude Desktop, select that SSH connection instead of "Local".
4. Send any message, or just open the session.

Expected: Session starts on the remote, same as Local.
Actual: "Claude Code crashed ... process exited with code 1" appears immediately. The remote-server.log shows the ccd-cli child process exiting with code 1 right after receiving the initialize control_request on stdin.

100% reproducible. Selecting Local works fine in the same Claude Desktop session.

Workaround: SSH to the remote manually and run ~/.claude/remote/ccd-cli/<version> directly in a terminal. Full Claude Code experience works that way, but loses the desktop integration.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

latest claude desktop as of may 6 2026

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

• Claude Desktop: <PUT YOUR OS HERE — macOS / Windows / Linux, plus app version if you can find it in About>
• ccd-cli version: 2.1.128 (auto-deployed by Claude Desktop)
• Account: Claude Max, OAuth (no API key)
• Remote OS: Ubuntu 24.04
• Remote arch: x86_64
• Remote glibc: 2.39
• Remote Node: not relevant (ccd-cli is a self-contained binary, not Node)
• Onboarding state on remote: completed manually, ~/.claude/.credentials.json exists with valid OAuth token, ~/.claude/settings.json present