[BUG] Desktop app (2.1.168) remote Linux session: bridge connects but no ccd-cli session is ever spawned — hangs on "Starting session…"

Resolved 💬 2 comments Opened Jun 8, 2026 by ntgr-yogeshjrk Closed Jun 12, 2026

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@notty login 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.
  • --serve and --bridge processes 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.
  1. In the desktop app, click "New session".
  2. 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).

  1. Let the app connect — it SSHes in and provisions its remote stack under

~/.claude/remote/ (claude-ssh server binary + ccd-cli/2.1.165).

  1. 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):

  1. 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.

  1. Tail the server log:

tail -f ~/.claude/remote/run/*/remote-server.log
→ loops every ~48s:
New connection from: @
Connection closed: @

  1. 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:

  1. Update desktop app to 2.1.168, fully quit/relaunch, retry → same hang.
  2. 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.

  1. 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_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗