[BUG] Remote Control initialization fails for every new session - registerWorker HTTP 401 (reconnects still work), since mid-May

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/67360
2. https://github.com/anthropics/claude-code/issues/61551
3. https://github.com/anthropics/claude-code/issues/57286

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate - please keep this open. Reviewed all three candidates:

• #67360 - different failure mode: an established bridge dies at JWT refresh and manually toggling Remote Control off/on recovers instantly. Here the enable/registration step itself is what always fails (registerWorker: HTTP 401); re-enabling never succeeds. Related area (auth), opposite recovery behavior.
• #61551 - closest in substance (registration-phase 401 on a valid Max login, Windows), but it was auto-closed as stale without resolution. This issue supersedes it with fresh evidence: existing-session reconnects still work while new registrations always 401, plus the desktop log signature and a 7-week timeline (first failure 2026-05-14, persistent since ~2026-06-22).
• #57286 - same user-visible symptom (only NEW sessions fail to initialize; old ones remain visible) but stale, already labelled duplicate, and has no log-level diagnosis pinning the failing call.

With one candidate being a different bug and the other two stale/closed unfixed, this is the only open, current, fully-diagnosed report of the create-new 401.

Still reproducing as of 2026-07-09 on Claude Code 2.1.197 (desktop-bundled; originally reported on 2.1.181) - same signature: Enabling remote control -> Remote Control initialization failed, registerWorker: HTTP 401. New worker registration has now failed continuously for ~8 weeks across at least 2.1.181->2.1.197, while existing-session reconnects keep working. Nine days since filing with no triage response - could a maintainer take a look? Happy to supply the full main.log or run any diagnostics.

Following up again — 11 days since this issue was filed and still no response from a maintainer. This is the only open, current, fully-diagnosed report of the registerWorker: HTTP 401 failure that blocks new Remote Control worker registration on the Windows desktop app (existing/persisted sessions still reconnect fine). Still reproducing as of today on 2.1.197. Remote Control is a paid Max feature and it has been unusable for me since 14 May. The two predecessor reports (#61551, #57286) were both closed stale without a fix — please don't let this one go the same way. Could someone from the team confirm this is on the radar and triage the area:auth root cause?

Corroborating on macOS - same symptom and error string here, in case a cross-platform datapoint helps triage.

• Claude Code 2.1.218, macOS (Darwin 25.5.0), VS Code extension panel (auto-enable via remoteControlAtStartup: true).
• Auth: claude.ai OAuth, max subscription, no ANTHROPIC_API_KEY. The Keychain OAuth token was refreshed the same day, so the access token is current and normal API use works fine.
• Every new panel session: toggleRemoteControl -> "Remote Control initialization failed", returned within ~20-45 ms. Identical result whether the enable is attempted 3s, 12s, or 32s after the session launches, so it is not a bridge-not-ready timing race.
• Only the Remote Control worker registration fails; everything else in the same session is unaffected.

So the "fails for every new session, while normal use / reconnects keep working" pattern reproduces on macOS + 2.1.218 too (this was reported Windows-first). Since the access token is confirmed fresh, this lines up with the server-side reading in #78309.

Happy to supply full CLI debug logs if a maintainer wants to pin the exact failing call. Thanks @NoelMul for the detailed registerWorker diagnosis - hopefully the added macOS signal helps get this in front of the auth team.

Confirming on macOS — and a concrete scope signal that explains the 401

Same symptom on macOS 15.5 (Darwin 25.5.0), Claude Desktop with bundled Claude Code 2.1.219: every new local session fails with Remote Control initialization failed, while a persisted session from a previous day reconnects fine in the same environment.

[sessions-bridge] Registering environment (reusing env_…)...
[sessions-bridge] Environment registered: env_…
[sessions-bridge] Reconnecting persisted session cse_…
[sessions-bridge] Session cse_… reconnected successfully
...
[info]  Enabling remote control for session local_…
[error] Failed to toggle remote control for local_…: Remote Control initialization failed

Reproduces 100% — 14 consecutive sessions over ~4.5 hours, [rcAutoEnable] verdict: enable=true source=explicit_pref each time.

Likely cause, matching #48378: the OAuth token Desktop injects into the spawned CLI process is inference-only. Inspecting the environment of the running CLI children (ps eww <pid>, 4 sessions checked):

CLAUDE_CODE_OAUTH_TOKEN=sk-ant-oat-…
CLAUDE_CODE_OAUTH_SCOPES=user:inference        ← only scope
CLAUDE_CODE_SUBSCRIPTION_TYPE=max
CLAUDE_CODE_SDK_HAS_HOST_AUTH_REFRESH=1

Meanwhile the Desktop main process fetches tokens for itself with the full set, logged right before it enables remote control:

[oauth-v2] lookup orgId=… scopes=user:inference user:file_upload user:profile user:sessions:claude_code

So the child that has to call registerWorker never receives user:sessions:claude_code, which lines up with the HTTP 401 in this issue. Reconnect keeps working because the persisted session's session_ingress_token is refreshed by the host (the sessions-bridge in the main process), not by the CLI child.

The generic toast comes from the CLI's fallback path — the bridge init returns null and the state change carries no detail, so the underlying 401 is never surfaced in the UI:

if (!bridge) fail(req, detailFromStateChange ?? "Remote Control initialization failed")

Surfacing the transport status code in that message would save a lot of guesswork.

Ruled out here: network (bridge.claudeusercontent.com reachable, [remote-tools-device] authenticated throughout), plan (Max), and local env conflicts (no CLAUDE_CODE_OAUTH_TOKEN/ANTHROPIC_AUTH_TOKEN in the user shell, ANTHROPIC_BASE_URL=https://api.anthropic.com).

Related: #48378 (closed as not planned, same root cause on Windows), #57286, #48238.

Thanks @jasonnickel and @DanielKa76 - cross-platform confirmation is very helpful. Adding a Windows datapoint that partly contradicts the inference-only-scope mechanism, in case it points at two variants.

On this machine (Windows 11 ARM64, Claude Desktop with bundled Claude Code 2.1.219, claude.ai Max OAuth), I inspected the environment from inside a spawned CLI child. The child receives the FULL scope string, not inference-only:

CLAUDE_CODE_OAUTH_SCOPES=user:inference user:file_upload user:profile user:sessions:claude_code
CLAUDE_CODE_SDK_HAS_HOST_AUTH_REFRESH=1
CLAUDE_CODE_SDK_HAS_OAUTH_REFRESH=1
CLAUDE_CODE_ENTRYPOINT=claude-desktop
CLAUDE_CODE_EXECPATH=...\\claude-code\\2.1.219\\claude.exe
(no CLAUDE_CODE_OAUTH_TOKEN present at all)

Two differences from the macOS reports: the sessions scope IS declared, and there is no token in the child at all - CLAUDE_CODE_SDK_HAS_HOST_AUTH_REFRESH=1, so the child defers to the host for auth rather than carrying sk-ant-oat-.... Yet registerWorker still returns 401 and every new session fails identically.

Also worth flagging so it isn't mistaken for the smoking gun: my main.log does contain scope: 'user:inference' lines, but they belong to a DIFFERENT OAuth client (clientId 89355bc3-..., redirect https://claude.ai/desktop/callback) used for browser preview - not the RC child spawn. Anyone grepping logs for this should check the clientId before attributing it.

So either there are two variants of the same failure, or the declared scope differs from the scope of the token actually minted/presented for registerWorker. If it is the latter, DanielKa76's conclusion still holds and the env var is simply not a reliable indicator of the effective grant - which would also explain why this is invisible to users.

Status ask. This issue is now 24 days old with three independent reporters across Windows and macOS, spanning at least 2.1.181 -> 2.1.219, 100% reproducible, with a concrete failing call identified - and it still has no assignee and no response from anyone at Anthropic. Two prior reports of the same failure (#48378, #61551) were auto-closed as stale/not-planned without a fix, so this has now gone unaddressed across three separate reports and roughly ten weeks. Could someone from the auth or desktop team please pick this up, or say what further diagnostics would help? Full main.log, CLI debug logs and process-environment dumps are available on request from all three of us.

Five months old, nine issues, 49 reporters, zero replies from Anthropic

I pulled these numbers from the GitHub API today (30 July). The nine issues tracking this same Remote Control registration failure:

| Issue | Opened | State | People |
|---|---|---|---|
| #28402 | 2026-02-25 | open | 18 |
| #30691 | 2026-03-04 | closed not_planned, LOCKED | 5 |
| #48238 | 2026-04-15 | closed not_planned | 4 |
| #48378 | 2026-04-15 | closed not_planned | 3 |
| #53920 | 2026-04-27 | closed not_planned, LOCKED | 1 |
| #57286 | 2026-05-08 | open | 11 |
| #61551 | 2026-05-22 | closed not_planned | 1 |
| #72968 | 2026-07-01 | open | 3 |
| #78309 | 2026-07-17 | open | 5 |

49 distinct people. Earliest report 25 February 2026. Comments from anyone with a MEMBER, OWNER or COLLABORATOR association across all nine issues: zero. Every comment on every one of these is from an external user or a bot.

Six of the nine were closed not_planned by the stale bot and two have since been auto-locked. None was closed because it was fixed, and none was read by a human before it was closed.

Two specifics worth a direct look:

1. #48378 identified the probable root cause on 15 April — "Claude Desktop injects inference-only CLAUDE_CODE_OAUTH_TOKEN" — the same mechanism @DanielKa76 independently arrived at here on 25 July. It was bot-closed on 5 June with no human comment. That diagnosis has sat in this tracker, unread, for three and a half months.
2. #53920 was auto-locked on 29 July with active_lock_reason: resolved. It was not resolved. It was stale-closed as not_planned and the bug still reproduces. Labelling unfixed reports "resolved" is how a five-month regression stays invisible.

What I am asking for

Assign an owner to this issue, or to #57286 as the largest, and say which is the canonical tracker so 49 people stop fragmenting across nine reports.

Correct the platform:windows label here — confirmed on macOS by @jasonnickel (2.1.218) and @DanielKa76 (2.1.219). That label may be filtering this out of triage.

Unlock #53920 and #30691, or reopen them against the canonical issue. Neither was fixed.

Exempt this cluster from the stale bot until it is actually resolved. Auto-closing unfixed reports six times has not made the bug go away, only harder to see.

For the record, I have also pursued this through paid support since 23 June across three conversations. On 27 July I was told the detail had been forwarded to the team and that no timeline would be provided. Posting here so the scale is at least on the public record.

Still reproducing tonight, 30 July, on 2.1.219.