[BUG] Remote Control: Projects threads on my computer fail with "CCR v2 worker registration failed ... 400"; self-started sessions on the same server register fine
Status Open
Reported on v2.1.292
Maintainer reply None cached
Activity 3 comments · opened Oct 8, 2026
What happens
Since about 2026-10-07 21:37 UTC, every claude.ai Project thread sent to run on my Mac fails to start ("Couldn't start"). The claude remote-control server log shows, for each attempt:Error: CCR v2 worker registration failed for session cse_...: Request failed with status code 400
Scope
- macOS,
claude remote-control --capacity 32 --permission-mode bypassPermissions --no-create-session-in-dir, several folders, each run as its own long-lived server. - It fails on every server, both those started in late September (older 2.1.2xx builds) and those started on 2026-10-08 on 2.1.292. Nothing changed on the machine at the time the failures began.
- "Require trusted devices" is off for my account.
Local vs Project thread
- A fresh
claude remote-controlin a scratch folder on the same machine and login, at 2026-10-08 01:25 UTC, created its own session. The work item was picked up and the debug log showedCCR v2: registered worker ... epoch=1 attempt=1, followed by a normal spawn. - Project-thread sessions dispatched from claude.ai to the same machine get the 400 on
/worker/registerevery time (latest at 01:20 UTC on 2026-10-08). - Signing in works, and folder approvals are current. Restarting a server did not help: one restarted on 2026-10-08 still fails.
Expected
Project threads start on the computer as they did before 2026-10-07 21:37 UTC.
Note
For status < 500 the response body only goes to the debug log, so the server log does not show the reason for the 400. Logging that body at error level would make this diagnosable.
3 Comments
Update: the same 400 hits Remote Control servers on 2.1.284 and 2.1.292 alike, and the registerWorker request (empty-body POST to /worker/register with the session ingress token) looks unchanged up to 2.1.293, so this appears to be a server-side change around 21:37 UTC on 7 Oct. On the older 2.1.284 server, "Always allow" for a folder also fails with "update Claude on your device", while "Allow once" still works.
Update: reproduced with a clean setup. A fresh
claude remote-controlserver on 2.1.293, started by hand in a new folder with an empty settings home (no settings.json, hooks, plugins, MCP servers or CLAUDE.md, and a minimal environment), registers its environment, and its own initial session registers its worker fine. Two Projects threads dispatched to it both failed with the same error: the work was acked (200), thenregisterWorker attempt 1 failed ... 400andregisterWorker failed: Request failed with status code 400, then stopWork. Even with --debug-file, the 400 response body is not logged. claude.ai showed "session could not become this thread's session". This account has many older Remote Control project threads still live, in case a per-account consent or session cap is involved.Correction to the timeline: the account-wide failures began at about 22:46 UTC on 7 Oct (23:46 BST). The 400 I quoted earlier at 22:37 BST was a separate one-off. Since 22:46 UTC, every project-dispatched session fails registerWorker with 400 in every folder, including a clean server with no settings, hooks or plugins (2.1.293). Self-created sessions still register.