--remote-control silently ignored when startup eligibility check runs before profile data is available — never re-evaluated after profile fetch

Environment

Claude Code 2.1.207, Linux (Debian 13), claude.ai Max subscription (oauth login)

Summary

Remote Control eligibility is evaluated exactly once, ~10ms into startup, against local cached state only (oauthAccount in .claude.json). If that block is missing or stale at that instant, the CLI prints to stderr:

Unable to determine your organization for Remote Control eligibility. Run `claude auth login` to refresh your account information.
--rc flag ignored.

…and never re-checks — even though the CLI's own async profile fetch delivers fresh org data seconds later in the same process. The interactive TUI immediately paints over the stderr warning, so to the user the session simply never appears in claude.ai/code with no visible explanation. Running /rc inside the same session succeeds (that path refreshes the profile live), confirming the account is fully eligible.

Repro

# A config dir identical to a working one, minus the cached account block:
cp -a ~/.claude /tmp/rc-repro
jq 'del(.oauthAccount)' ~/.claude.json > /tmp/rc-repro/.claude.json
CLAUDE_CONFIG_DIR=/tmp/rc-repro claude --rc      # → "--rc flag ignored" (stderr, hidden by TUI)
# /rc inside the session works fine

Timing evidence (--debug-file)

The warning is emitted synchronously between showSetupScreens() completing and LSP manager init — before Starting background startup prefetches — i.e. before any network I/O could populate the missing data:

[DEBUG] [STARTUP] showSetupScreens() completed in 5ms
[WARN] [stderr] Unable to determine your organization for Remote Control eligibility. ...
--rc flag ignored.
[DEBUG] [LSP MANAGER] initializeLspServerManager() called

On a machine where the check passes, the very next lines are [remote-bridge] Created session cse_… — so the gate is purely the local cache read.

Second trigger: stale profile schema

The same silent failure occurs when oauthAccount is present but was written by an older CLI version — e.g. a cached block still carrying the since-removed organizationRole/workspaceRole fields fails the check until something refreshes it. So any user with an old or restored .claude.json can hit this on every launch.

Expected

Either of:

1. Re-evaluate Remote Control eligibility when the startup profile fetch completes, and engage the requested --remote-control then (best), or
2. Block the eligibility check on the profile fetch when local data is missing/stale, or at minimum
3. Surface the failure in the TUI rather than only on painted-over stderr.

/rc already proves the late-refresh path works; startup just never takes it.