[BUG] Remote Control registration: orphans on OAuth access-token rotation (~8h), dead session names never re-register, CLAUDE_CODE_OAUTH_TOKEN in env silently blocks registration

Summary

Three coupled Remote Control registration failures found over a 24h investigation on a headless always-on box. Together they make the desktop/mobile app channel unusable unattended: the app session dies roughly every 8 hours and no relaunch strategy short of a specific ritual brings it back.

1. Registration appears bound to the OAuth access token and orphans when the token rotates (~8h). A registered, actively-used session loses its app bridge at the next silent credential refresh, mid-turn, while the CLI process on the box stays healthy.
2. A session name whose registration died is burned. Relaunching under the same --name never re-registers, even with fully valid auth. Only a never-used name (plus condition 3 below) registers.
3. CLAUDE_CODE_OAUTH_TOKEN in the environment (inference-only claude setup-token) blocks remote-control registration entirely, even when a full-scope credentials.json is also present. Inference, plugins, and headless runs all work; only registration silently fails.

Environment

• Claude Code 2.1.212, WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2) on a Windows host, Pro plan
• Launch (via tmux + supervisor loop): claude --channels plugin:discord@... --remote-control --remote-control-session-name-prefix servus --name <unique-name> --model ... --effort high
• Clients: Claude desktop app (Windows) and phone app, same account

Evidence timeline (2026-07-16 .. 2026-07-17, times BST)

Finding 3 (token env blocks registration):

• 07-16 13:03: launch with CLAUDE_CODE_OAUTH_TOKEN set and credentials.json deliberately moved away: no session appears in the app (full app restart tried, stale-list quirk ruled out). Inference/Discord/CLI all fine. Registration-only failure.
• 07-16 23:31, 23:42: fresh unique names (servus-main-5-*, servus-main-6-*), valid credentials.json present AND token env present: not registered.
• 07-16 23:40: token env removed (unset in the auth hook, token file disabled). Next launch 07-17 00:39, servus-main-7, credentials-only: registers, user attaches and converses. Only variable changed vs. the 23:31/23:42 failures.

Finding 2 (burned names):

• 07-16 22:18 / 22:26 / 22:40: three same-name relaunches of the previously-registered servus-main after it orphaned. All fail to register, including one after a fresh interactive /login ("Login successful") and confirmed account-wide valid auth.
• 07-16 22:54: fresh never-used name servus-main-b registers (confound: a reboot happened in the same step, but the three no-reboot same-name failures above stand).
• 07-16 22:57: servus-main-b reused after its first holder died: does NOT re-register. Name reuse fails deterministically; we now increment a counter per launch.

Finding 1 (rotation orphaning), today:

• 07-17 00:39: servus-main-7 launches credentials-only, registers, user attaches from the desktop app and works with it.
• 07-17 07:00: credentials.json mtime updates (silent access-token refresh; interactive login was current).
• 07-17 ~09:30: app shows "Remote Control disconnected / The bridged Claude Code process stopped responding mid-turn. Check your terminal for errors (you may need to run /login)". The CLI process on the box: same PID since 00:39, ~9h uptime, RSS ~400MB, actively serving turns from the terminal. Nothing on the box died and /login is not actually needed.
• Same pattern observed 07-16 ~22:06: entity died coinciding exactly with an access-token refresh (credentials.json mtime 22:06), interactive login renewed 8h earlier that day.

Expected

• Registration survives silent access-token refresh (or re-registers transparently).
• Relaunching under a previously-used --name re-takes or replaces the dead entity instead of failing silently.
• Either CLAUDE_CODE_OAUTH_TOKEN presence does not affect registration when credentials.json has the needed scope, or the CLI warns that registration is disabled under token auth instead of failing silently.

Actual

App-visible session dies every ~8h on an unattended box; each recovery needs a fresh never-used session name; any leftover setup-token in env turns registration off with no diagnostic.

Impact

Headless/always-on use of Remote Control (the "attach to my home box from the phone" case) is effectively broken: the bridge cannot outlive one token cycle, and the error text blames the terminal/login, sending users down a wrong debugging path (we burned a full day on it).