Remote Control: unarchived bridge session never reconnects (stuck "Connecting", host never spawns a worker)

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?

After I archive a session hosted by a Remote Control bridge (claude remote-control --name <n> --spawn=same-dir) and then unarchive it, the session never reconnects. The host never logs a spawn attempt and no worker process starts, even after 90+ seconds. The app shows "Connecting…" indefinitely.

After unarchive, the server-side record shows session_status: SESSION_STATUS_PENDING and connection_status: disconnected. unarchived_cpa_epoch goes up by one on each unarchive attempt. A message sent to the session is stored with unread: true and never processed.

Everything else on the bridge keeps working. A new session in the same environment gets a worker within about 5 s, and restarting the bridge reclaims the environment and respawns its held session with --resume=<session-url>. The bridge was not restarted between archive and unarchive in any of my tests.

It does not depend on the terminal wrapper. I get the same result from a bridge under systemd + tmux and from one under a bare pty with no tmux anywhere in the chain.

What Should Happen?

When a session is unarchived, the host should spawn a worker for it (resume), the same way it does for a new session or after a bridge restart.

Error Messages/Logs

# host log at archive time (worker exits, capacity drops e.g. 2/32 -> 1/32)
[20:29:27] Session failed: Process exited with error cse_011YSNsPxRW1QGdyrRdLahrj

# server record after archive
session_status: SESSION_STATUS_ARCHIVED
connection_status: connected

# server record after unarchive (unchanged after 90+ s)
session_status: SESSION_STATUS_PENDING
connection_status: disconnected
unarchived_cpa_epoch: <increments per attempt>

Nothing is logged on the host after unarchive.

Steps to Reproduce

1. On a Linux host, run claude remote-control --name test --spawn=same-dir and leave it running.
2. Create a session in that bridge's environment. I used the claude-code-remote MCP create_session (Haiku 4.5, prompt "reply ok"); the Claude app works too. A worker starts within about 5 s.
3. Archive the session (archive_session, or archive it from the app). The host logs Session failed: Process exited with error <id> and the worker exits.
4. Unarchive it (unarchive_session, or unarchive it from the app).
5. Wait 90 s. No spawn is logged, no worker appears, and the session stays PENDING / disconnected.
6. Optional: run send_message to the session. The message stays unread: true.
7. Optional: repeat steps 1–5 with the bridge started under a bare pty, e.g. script -qfc 'claude remote-control --name bare-test --spawn=same-dir' from a transient systemd unit. The result is the same.

Claude Model

Not model-specific. I hit it with Opus 5.5 (real session) and Haiku 4.5 (repro).

Is this a regression?

I don't know

Last Working Version

Unknown

Claude Code Version

2.1.289 (also seen on 2.1.280)

Platform

Anthropic API (claude.ai login, Max plan)

Operating System

Ubuntu 24.04 (headless server)

Terminal/Shell

Other: headless bridge under systemd + tmux, and separately under a bare pty via script. Clients were the Android app, claude.ai, and the claude-code-remote MCP.

Additional Information

• I first hit this with a real session created from the Android app on 2.1.280. I archived it, then unarchived it twice from the app (unarchived_cpa_epoch: 2), and it stayed stuck.
• Permission mode: auto.
• This may be related to the 2.1.288 fix for "Remote Control cleanup archiving a session that is still connected or was just re-attached by another Claude Code process". The record after archive still shows connection_status: connected.