[BUG] Long-lived CLAUDE_CODE_OAUTH_TOKEN (setup-token) and Remote Control are mutually exclusive with no documented workaround

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?

claude setup-token generates a long-lived OAuth token (valid ~1 year) intended for headless/CI use. Setting it globally via env.CLAUDE_CODE_OAUTH_TOKEN in settings.json` is the documented way to avoid the normal ~28-day refresh-token expiry for a long-running interactive session.

However, claude doctor reports that Remote Control requires a full-scope login token, and that a setup-token-issued token is missing the user:profile scope:

Remote Control requires a full-scope login token...
Sign-in is missing the user:profile scope

This makes long-lived tokens and Remote Control mutually exclusive: as soon as CLAUDE_CODE_OAUTH_TOKEN is set (globally or per-session), Remote Control stops working, regardless of how recently a full interactive /login was performed — the env token always wins over the session's own credentials.
For a long-running headless/server session (e.g. Claude Code running inside a Docker container as part of a home-automation setup, no interactive access to re-run /login every few weeks), the realistic choices are:

1. Use a long-lived token → lose Remote Control entirely.
2. Use the normal interactive OAuth login → refresh token expires after inactivity or after ~28 days, and without a background daemon to proactively refresh it (no longer present in recent CLI versions — no daemon process, no daemon.log), the session silently falls back to being logged out and needs a manual /login.

There's no supported way to get both: an unattended long-running session that never asks for a fresh login, and the ability to reach it via Remote Control from claude.ai or the mobile app.

What Should Happen?

Either:

• A way for a setup-token-issued token to also carry user:profile scope (even if that requires an explicit claude setup-token --with-remote-control opt-in), or
• A background refresh mechanism for the normal interactive login's refresh token that keeps it alive indefinitely for long-running unattended sessions (so Remote Control keeps working without ever needing a manual re-login), or
• At minimum, clear documentation of this trade-off in claude setup-token --help / the Remote Control docs, since right now it's only discoverable via a claude doctor error message after the fact.

Error Messages/Logs

- Claude Code CLI version: 2.1.207 (also checked: this limitation was still present as of the current CHANGELOG.md head, 2.1.278 — searched for "user:profile", "setup-token", "long-lived" + "Remote Control" across all intervening release notes, found nothing indicating this was addressed)
- Running inside a Docker-based Home Assistant add-on (headless, no persistent background daemon)

Steps to Reproduce

Claude Code CLI version: 2.1.207 (also checked: this limitation was still present as of the current CHANGELOG.md head, 2.1.278 — searched for "user:profile", "setup-token", "long-lived" + "Remote Control" across all intervening release notes, found nothing indicating this was addressed)

• Running inside a Docker-based Home Assistant add-on (headless, no persistent background daemon)

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.207

Claude Code Version

2.1.207

Platform

Anthropic API

Operating System

Other

Terminal/Shell

Other

Additional Information

_No response_