[BUG] remote-control: stale bridge-pointer re-adopts a deleted session → "registerWorker failed 404" on every launch

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?

Running claude remote-control (spawn mode: worktree) fails the same way on every launch.

On startup it reads a stale bridge-pointer.json and tries to reconnect the cloud session it references. The server replies 400 Session not found (the session was deleted days ago). Instead of dropping that pointer record, the client issues a second bridge/reconnect that re-adopts and re-queues the dead session. The poll loop immediately picks it up and calls CCR v2 registerWorker, which returns 404, printing a top-level [ERROR] registerWorker failed: Request failed with status code 404 to the user.

RC does recover (it stops the work item and stays connected, Capacity 0/32), but on shutdown it logs Skipping archive+deregister to allow resume, so the stale pointer is never cleaned up and the exact same 404 happens on the next launch, forever. There is no self-heal and no hint that deleting bridge-pointer.json fixes it.

Deleting ~/.claude/projects/<slug>/bridge-pointer.json manually resolves it — the next run mints a fresh environment and logs CCR v2: registered worker ... epoch=1 with no 404.

What Should Happen?

1. When bridge/reconnect returns 400 "Session not found", the client should treat that session as gone: drop it from bridge-pointer.json and do NOT issue a second bridge/reconnect that re-adopts and re-queues it.

1. A dead/adopted session that fails CCR v2 registerWorker with 404 should not be retried on every launch. After it fails, the stale bridge-pointer.json entry should be pruned automatically (self-heal), so the next claude remote-control starts clean instead of reproducing the identical 404 forever.

1. On shutdown, "Skipping archive+deregister to allow resume" should not preserve a pointer whose referenced session/environment the server has already rejected.

1. registerWorker failing with 404 for a session RC has already recovered from (stopped the work item, still connected, Capacity 0/32) should be a debug-level log line, not a top-level [ERROR] shown to the user. If it is surfaced, it should say how to recover (e.g. "run claude remote-control again" or point at bridge-pointer.json).

1. A git worktree under .claude/worktrees/bridge-cse_* that is locked by an owner PID which is no longer running should be reclaimed automatically by RC (unlock + remove + prune), not left for the user to clean up manually.

Net effect: claude remote-control should start successfully with a fresh environment when the previous one is no longer valid, with no manual deletion of bridge-pointer.json and no manual worktree cleanup.

Error Messages/Logs

[bridge:work] Acknowledging workId=cse_<WID>
  [bridge:api]  POST .../work/cse_<WID>/ack -> 200
  [bridge:session] CCR v2: registerWorker attempt 1 failed, retrying: Request failed with status code 404
  [ERROR] registerWorker failed: Request failed with status code 404
  [bridge:api]  POST .../work/cse_<WID>/stop -> 200
  [bridge:work] stopWork succeeded for workId=cse_<WID> on attempt 1/3
  [bridge:api]  GET .../work/poll -> 200 (no work, 1 consecutive empty polls)
  [bridge:shutdown] Skipping archive+deregister to allow resume (env env_<ENV>, spawnMode worktree)

  Secondary — stale worktree lock from the same incident:

$ git worktree list
  .../.claude/worktrees/bridge-cse_XXXX  <sha> [worktree-bridge-cse_XXXX]
    locked  claude agent bridge-cse_XXXX (pid 6247)      # pid 6247 not running

Steps to Reproduce

Preconditions

• Claude Code 2.1.267 (native), Linux, claude.ai OAuth (Pro).
• Remote Control spawn mode = worktree (default; also stored as

"remoteControlSpawnMode": "worktree" in ~/.claude.json).

• A directory that has been used with claude remote-control before, so

~/.claude/projects/<project-slug>/bridge-pointer.json exists and points at a
cloud session/environment that the server has since deleted or expired.
bridge-pointer.json looks like:
{"sessionId":"session_XXXX","environmentId":"env_XXXX","source":"standalone","pid":<n>,"procStart":"<n>"}

Natural repro (how I hit it)

1. Use claude remote-control in a repo over several days with spawn=worktree;

drive sessions from claude.ai/code and let them end / get cleaned server-side.

1. At some point a spawned bridge child session crashes at startup (0-byte

transcript) and leaves a locked git worktree under .claude/worktrees/bridge-cse_*.

1. Run claude remote-control again in that same directory.
2. Observe: it connects and creates an environment, but immediately prints

Error: CCR v2 worker registration failed for session cse_XXXX: Request failed
with status code 404.

1. Quit and re-run claude remote-control — the exact same 404 appears again.

It never clears on its own.

Deterministic repro

1. In a git repo, run claude remote-control once so bridge-pointer.json is

written for that directory. Note the sessionId/environmentId in it. Quit.

1. Wait until that cloud session no longer exists server-side (it was already

~5 days old in my case), OR delete/disconnect it from claude.ai/code so the
backend returns "Session not found" for it.

1. Run claude remote-control again in the same directory with

--verbose --debug-file /tmp/rc.log.

1. In /tmp/rc.log observe the loop:

• POST .../bridge/reconnect -> 400 "Session not found"
• a second POST .../bridge/reconnect -> 200, "Adopted session cse_XXXX re-queued"
• work/poll returns that dead session as queued work
• CCR v2 registerWorker -> 404 (retries once, fails)
• [ERROR] registerWorker failed: Request failed with status code 404
• on shutdown: "Skipping archive+deregister to allow resume"

1. Repeat step 3 any number of times: identical failure every launch.

Workaround that fixes it
rm ~/.claude/projects/<project-slug>/bridge-pointer.json
Then claude remote-control mints a fresh environment and logs
CCR v2: registered worker ... epoch=1 attempt=1 with no 404.

Secondary cleanup that was also needed
git worktree remove --force .claude/worktrees/bridge-cse_XXXX
git worktree prune
(the worktree stayed locked by a dead owner PID and was never reclaimed)

No project code is involved — any git repo reproduces it.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.267 (Claude Code)

Claude Code Version

2.1.267 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

When I enter claude rc:
<img width="1339" height="119" alt="Image" src="https://github.com/user-attachments/assets/09ceb9fe-d1cf-483a-8a38-c550a89c080c" />