[BUG] Desktop SSH remote: messages stuck at "Delivering to user@host…" and never reach ccd-cli stdin, while spawning new CLIs still works

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?

In a Desktop SSH remote session (Windows client → macOS host), user messages stopped reaching the remote ccd-cli process. The UI shows a pending indicator indefinitely (Korean locale: main@<host>에 전달하는 중…, roughly "Delivering to main@<host>…"). There is no error and no timeout.

This affects every session on that host, including brand-new sessions. However, the app can still ask the remote server to spawn new ccd-cli processes, and those spawns succeed. They just never receive any input.

Timeline (all times UTC+9, same Desktop app instance and same SSH connection throughout):

| Time | Event |
|---|---|
| 10-07 07:25 | Desktop app started; remote server --serve daemon + --bridge started 07:26 |
| 10-07 19:53, 20:40 | Two new sessions created; both worked normally (transcripts written until 20:51 / 20:52) |
| 10-08 00:58 | Last successful assistant response (session A) |
| 10-08 07:26 | Only other daemon log entry overnight: [hostclean] pass done in 39ms: nothing to do |
| 10-08 09:05:13 | Resumed session B: daemon log shows CLI spawned (Process … started, stdout/stderr streaming). Message never arrives; transcript unchanged |
| 10-08 09:07:03 | New session C: CLI spawned. Message never arrives; no transcript file is ever created |
| 10-08 09:07:46 | Message to session A, whose CLI has been alive since 10-07 08:08. Never arrives; no new transcript line |

Remote-side state while stuck (checked over a separate SSH login):

• The daemon and bridge processes are alive. The bridge's parent sshd session from 10-07 07:26 is still alive, so this is the original connection, not a reconnect.
• The target ccd-cli processes are alive, and their stdin/stdout/stderr are pipes to the daemon.
• sample <pid> shows the CLI main thread idle in kevent64. It is waiting for input, not busy or deadlocked.
• remote-server.log contains only process start/streaming/exit lines. There are no errors at the time of the stuck sends.

Client/network side:

• Host reachable (ping 3–7 ms on LAN), port 22 open.
• Windows System event log shows no sleep/resume events between 10-08 00:50 and the stuck sends.

So the spawn path (client → daemon) works, but the path that writes user messages to a CLI's stdin does not, for both existing and newly spawned processes.

What Should Happen?

Messages are delivered to the remote CLI. If they can't be, the UI should show an error or time out instead of staying "delivering" forever.

Error Messages/Logs

Remote daemon log excerpt:

2026/10/08 07:26:43 [hostclean] pass done in 39ms: nothing to do
2026/10/08 09:05:13 [process.Manager] Process 6c50c084-... started, PID=53065, command=/Users/<user>/.claude/remote/ccd-cli/2.1.289
2026/10/08 09:05:13 [process.Manager] Starting stderr streaming for process 6c50c084-...
2026/10/08 09:05:13 [process.Manager] Starting stdout streaming for process 6c50c084-...
2026/10/08 09:07:03 [process.Manager] Process a2fd298c-... started, PID=53430, command=/Users/<user>/.claude/remote/ccd-cli/2.1.289
2026/10/08 09:07:03 [process.Manager] Starting stderr streaming for process a2fd298c-...
2026/10/08 09:07:03 [process.Manager] Starting stdout streaming for process a2fd298c-...

(no further entries)

Steps to Reproduce

Not deterministic. Conditions when it happened:

1. Windows Desktop app connected to a macOS host via SSH remote; app and connection up for ~26 h.
2. Many sessions opened on that host over that period (28 ccd-cli processes alive under the daemon at the time, see "Additional Information").
3. Idle ~8 h overnight with no activity.
4. Send a message in any remote session, existing or new → stuck at "Delivering…".

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.26454.0 (Windows)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

• Not #54179: only one --serve daemon exists; no token churn.
• Not #52790: the spawn RPC is issued and the CLI starts.
• Possibly related: 28 idle ccd-cli processes (~8.4 GB RSS total) had accumulated under the daemon, including CLIs spawned for sessions that were only opened, not messaged. None were reaped, and hostclean reported "nothing to do". See #83359.
• Workaround result after fully quitting and relaunching the Desktop app: <resolved / not resolved>