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

Third machine reproducing the relaunch 404 (fourth in your combined dataset — your NAS row only shows a clean first launch), on a longer window, plus a local mechanism that may explain why re-launches fail while fresh directories register cleanly.

Setup: headless Ubuntu Server 26.04, claude remote-control under a systemd system unit, always on; native install, currently 2.1.234.

Matching your pattern: 26 consecutive service starts (Jul 31 – Aug 17, the most recent start) each log the CCR v2 worker-registration 404 exactly once, 6–12 seconds after start, always for the same session id. As in your report the bridge still connects afterwards, so it's easy to miss — and in daily use here, phone sessions on this machine have kept working regardless (my observation, not yours; I haven't tested your cross-machine /list-agents symptom).

**The dead id belongs to a session that ended cleanly.** With journalctl --all the id appears exactly once before the failures: Session completed (1m 41s) on Jul 29 — a short session, created within minutes of the environment id itself first appearing, that completed normally. No crash. That matches your stop conditions (Ctrl+C, closed terminal, dropped SSH) better than any crash story: a normally ended session left an id behind that re-registration has tripped over at every start since. (This also corrects the origin I gave in my Aug 11 comment on #77372, which blamed a kernel OOM of Aug 2 — with --all the series demonstrably starts Jul 31, and the journal shows the id completing healthily on Jul 29.)

Where the series starts is sharp, with one confound: on Jul 31, after a reboot and a ~6-minute credential-loss crash loop (11 starts, unrelated), a start at 08:54 on the then-installed CLI — a long-stale native install stuck on 2.1.197, auto-updates off — connected with no registration error. Minutes later that install was updated in place to 2.1.220 (a stray npm-global duplicate installed that morning as a repair attempt was removed at the same time) and the service restarted: the first start on 2.1.220 logged the first 404 six seconds in, and all 26 starts since (through 2.1.234, 6 reboots) repeat it. Caveat: successful registration is silent, so I can't tell whether 2.1.197 was re-registering successfully or simply didn't exercise this path.

(Measurement tip that cost me two weeks of miscounting: my unit's early logs stored raw ANSI codes, and those lines — including the first two 404s and the healthy Session completed — render as [blob data] in plain journalctl, invisible to grep. journalctl --all shows them.)

The mechanism datapoint. The CLI keeps a pointer file, ~/.claude/projects/<project>/bridge-pointer.json, which here still contains the dead session's id — with a session_ prefix where the error prints cse_ (same suffix; that prefix mismatch is why grepping for the printed id finds nothing, as tonydehnke found in #77372):

{
  "sessionId": "session_01Acwizs…",      ← error prints cse_01Acwizs…
  "environmentId": "env_01Gf2…",
  "source": "standalone",
  "pid": <pid of the currently running worker>
}

And it keeps being written back with the live worker's pid, so it never ages out. Three observations from the last two days:

• The restart of Aug 17 began at 23:07:12; the new worker was up at 23:07:13 and its pid was in the pointer at 23:07:15 — about two seconds into its life — with the same dead session id (mtime recorded live; since overwritten by the next rewrite).
• The registration that failed at 23:07:19 failed on exactly that id, four seconds after it was written back.
• Mid-run rewrites at 39 hours and again at 9 hours into a worker's life.

If the worker re-submits the persisted id on startup, your table follows directly: a fresh directory has no pointer → new session id → clean; a previously-registered one carries a session id the server no longer accepts → 404. That would make the server-side part simply "that session no longer exists", and the bug the client persisting and reusing a dead session id with nothing that lists it and nothing that can delete it (that side is tracked in #77372). Stated plainly: the re-submit step is inference from timing and the matching suffix, not a packet capture — your server-side reading could still be right, in which case the pointer is a symptom rather than the cause.

One footnote on "the same env_... ID is reused server-side": mostly true here too — the same env id has survived 38 service restarts and 7 reboots since Jul 29 — but my journal does show one changeover: a different id on Jul 28 that demonstrably survived the three reboots of an in-place OS upgrade that evening, and was replaced only at the next morning's boot. So the binding is sturdy but not immutable.

Happy to delete the pointer file and report whether the next start registers cleanly — haven't yet, since this worker is in production use.

as little it can be
I fought with rc remote-control --remote-control ... (@claude your doc is a mess) for almost 12 hours.
I was able to get ride of this Error: CCR v2
by turning off Auto-install IDE extension

remark I'm running claude code on Ubuntu 26.04LTS inside WSL2

Same error, different trigger and a client-side artifact that may be relevant.

Environment: macOS, claude rc (standalone Remote Control bridge), single repo directory.

Repro: claude rc, then end the process with a plain Ctrl+C (SIGINT) — the normal, everyday way to stop it, not a crash or force-kill. Next claude rc invocation — in any directory, not just the one that was interrupted — fails immediately with:

Error: CCR v2 worker registration failed for session cse_XXXXXXXXXXXXXXXXXXXXXXXX: Request failed with status code 404
Environment preserved. Restart `claude remote-control` to reconnect existing sessions.

Found the client-side state: each project directory keeps ~/.claude/projects/<project>/bridge-pointer.json, e.g.:

{"sessionId":"session_...","environmentId":"env_...","source":"standalone","pid":60757,"procStart":"..."}

If the process at that pid is no longer running — which is already true after an ordinary Ctrl+C, since the pointer is apparently never cleared on SIGINT — the next launch still tries to reconnect using it, the server 404s on the now-dead cse_... session, and registration fails.

Workaround: delete the stale bridge-pointer.json (verify pid is dead first) before relaunching. Confirmed this clears the error without needing a new environment.

This might be the same root cause as #90777 (activeSessionIds never written on ungraceful shutdown) — in both cases the client has no way to distinguish "worker died, pointer is stale" from "worker still owns this session," so it keeps re-presenting dead state to the server (or vice versa) and gets a 404. Might be worth having the client kill -0 the recorded pid before trusting a bridge pointer, and/or having the server accept re-registration for a cse_ id that's already gone instead of 404ing.