Remote Control: CCR v2 worker registration fails with 404 when re-launching a previously-registered environment

Status Open
Reported on v2.1.228
Maintainer reply None cached
Activity 2 comments · opened Aug 12, 2026

Summary

claude remote-control fails to register its CCR v2 worker (Error: CCR v2 worker registration failed for session cse_XXXXXXXX: Request failed with status code 404) when re-launching on an environment that was already registered before (the same env_... ID is reused server-side for a given account+directory+machine combination). A brand-new environment (never launched before under that account) registers cleanly every time.

The bridge still reports Connected, so the failure is easy to miss, but the practical impact is that cross-machine session discovery via /list-agents (ListAgents) never shows sessions from an affected environment — even with Remote Control simultaneously connected on multiple machines under the same account.

Environment

  • Claude Code CLI: 2.1.228 (confirmed up to date via claude update on every machine involved)
  • Single Claude Max subscription, same org (orgId) on all machines
  • Machines: macOS (MacBook Pro), macOS (Mac Mini), Synology DSM (NAS, accessed via SSH)
  • claude auth status confirms loggedIn: true, same org, on every machine

Steps to reproduce

  1. claude remote-control --name "X" in a directory that has never been used for Remote Control before → registers cleanly, no error.
  2. Stop the process (Ctrl+C, close the terminal, or disconnect the SSH session it was running in).
  3. claude remote-control --name "X" again in the same directory → fails on startup with:

``
Error: CCR v2 worker registration failed for session cse_XXXXXXXX: Request failed with status code 404
`
The bridge still shows
Connected, but the environment never becomes discoverable from another machine's /list-agents`.

Evidence (same account, same day, 3 independent machines)

| Machine | Directory | Environment ID | Registration | CCR v2 error |
|---|---|---|---|---|
| MacBook Pro | ~/Desktop | env_0174inQqWGZ7Q2K6hqQemsah | 1st launch ever | No |
| MacBook Pro | ~/Desktop (same env, relaunched) | env_0174inQqWGZ7Q2K6hqQemsah | Relaunch | Yes |
| Mac Mini | ~/DS-Builder | env_01GfsCL3uhDdu2VJ2CnGkHGY | Relaunch (×2, different times) | Yes (both times) |
| Mac Mini | ~/test-rc (freshly created dir) | new env | 1st launch ever | No |
| NAS (Synology DSM) | ~ | env_017LMwYYknmnm6JB1Qi82cNs | 1st launch ever | No |

Every first-time registration of a new environment succeeded; every relaunch of a previously-registered environment failed with the same 404, across two different physical Macs.

What we ruled out

  • CLI version: all three machines were already on the latest version (claude update reported up to date).
  • Auth/account/subscription: identical orgId, loggedIn: true, Claude Max on all three machines.
  • Local install corruption: on the Mac Mini specifically, registering a brand-new environment (~/test-rc) worked perfectly right after the existing environment (~/DS-Builder) had just failed in the same install — ruling out a broken local install as the cause.

This points to a server-side issue with re-registering (resuming) a CCR v2 worker for a previously-created environment, rather than a client-side or account-level problem.

View original on GitHub ↗

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