[BUG] Desktop app (2.1.168) remote Linux session: bridge connects but no ccd-cli session is ever spawned — hangs on "Starting session…"
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?
Title: Desktop app (2.1.168) remote Linux session: bridge connects but
no ccd-cli session is ever spawned — hangs on "Starting session…"
Environment
- Desktop app: 2.1.168 (Mac/Windows)
- Remote host: Linux x86-64, RHEL 8 (kernel 4.18), OpenSSH
- Standalone CLI on remote: 2.1.168 (works fine)
- Remote stack the app provisions: claude-ssh server (built 2026-05-21)
- ccd-cli 2.1.165
What happens
"New session → on Linux server" hangs on "Starting session…" forever.
No error, no SSH password prompt.
Diagnosis from the remote host
- SSH is fine; a fresh
sshd@nottylogin is established by the app. - Disk/permissions fine; host reaches api.anthropic.com.
- ~/.claude/remote/srv/<hash>/server (claude-ssh) and
~/.claude/remote/ccd-cli/2.1.165 are both present.
- ccd-cli/2.1.165 runs correctly:
2.1.165 (Claude Code), exit 0. --serveand--bridgeprocesses start; the bridge connects to the
rpc socket, holds ~48s, then closes and retries indefinitely.
- remote-server.log loops:
New connection from: @
Connection closed: @ (every ~48s)
- No ccd-cli session process is ever spawned — the "start session"
step never launches the CLI.
Key point
- Updating the desktop app to 2.1.168 does NOT help: the app re-provisions
ccd-cli 2.1.165 every time, even after wiping
~/.claude/remote/{srv,ccd-cli,run}. The remote stack version is not
user-selectable from the Linux side.
- Looks like a protocol/version incompatibility between the 2.1.168
desktop app and the 2.1.165 remote stack it provisions.
Workaround that works
Cloud "remote control" sessions (claude --remote-control <name> running
on the host) attach fine from web AND desktop and edit code on the host.
Only the SSH "remote environment" path is broken.
What Should Happen?
the SSH "remote on Linux server" session should behave the same
as the cloud "remote control" session already does — a working Claude
session whose file/edit/bash operations land on the Linux host.
Error Messages/Logs
Steps to Reproduce
Steps to reproduce
Prerequisites:
- A Linux x86-64 host (RHEL 8 / kernel 4.18 in our case) reachable over SSH,
with key- or password-based SSH login working.
- Claude desktop app 2.1.168 (Mac or Windows), signed in.
- In the desktop app, click "New session".
- Choose the Linux server environment (the 💻 "remote on server" option,
NOT the ☁️ cloud option) and point it at the SSH host (user@host, port 22).
- Let the app connect — it SSHes in and provisions its remote stack under
~/.claude/remote/ (claude-ssh server binary + ccd-cli/2.1.165).
- Open the new session and send any message (e.g. "Hello").
Expected:
- A session starts on the Linux host; the prompt responds.
Actual:
- The session sits on "Starting session…" indefinitely. No error, no
password prompt, never responds.
To observe the failure on the host (SSH in via a normal terminal):
- Watch the processes:
pgrep -af 'remote/srv/.*/server'
→ --serve and --bridge processes are present.
pgrep -af 'ccd-cli/2.1.165'
→ empty — no session CLI is ever spawned.
- Tail the server log:
tail -f ~/.claude/remote/run/*/remote-server.log
→ loops every ~48s:
New connection from: @
Connection closed: @
- Confirm the remote CLI itself is fine (rules out a bad binary):
~/.claude/remote/ccd-cli/2.1.165 --version # prints "2.1.165 (Claude Code)"
Does NOT fix it:
- Update desktop app to 2.1.168, fully quit/relaunch, retry → same hang.
- Wipe the remote cache and retry:
pkill -f 'remote/srv/.*/server'
rm -rf ~/.claude/remote/{srv,ccd-cli,run}
→ app re-provisions ccd-cli 2.1.165 again (not 2.1.168) and hangs
identically.
- Kill the stale SSH master so the app opens a fresh login → SSH layer
reconnects cleanly, but the session still never spawns (same ~48s loop).
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.168
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Xterm
Additional Information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗