Remote Control init fails when ANTHROPIC_API_KEY is present in env, even though active auth is Max (/status shows Max)

Status Closed — not planned
Reported on v2.1.218
Maintainer reply None cached
Activity 1 comment · opened Jul 27, 2026 · closed Jul 27, 2026

Summary

Remote Control fails to initialize (VS Code extension: "Remote Control Initialization failed") when ANTHROPIC_API_KEY is present in the process environment — even when the session's active auth is a claude.ai Max subscription and /status reports Max. Removing the env var and restarting fixes it.

This is distinct from the existing "not yet enabled for your account" entitlement reports (#72683, #74762), where the key was already unset. Here the key is present but is not the active auth: /status shows Max, login always prompts for and selects the subscription billing method, and Console usage reflects no API billing.

Environment

  • Claude Code 2.1.218 (VS Code extension), macOS arm64 (Darwin 25.5.0)
  • Auth: claude.ai OAuth, Max subscription; /status = Max
  • ANTHROPIC_API_KEY exported from a shell profile (~/.secrets) and also propagated via launchctl setenv, so the GUI-launched VS Code session inherited it

Repro

  1. Log in with Max; confirm /status shows Auth = claude.ai / Max.
  2. Ensure ANTHROPIC_API_KEY is set in the environment the extension inherits (e.g. via launchctl setenv ANTHROPIC_API_KEY ..., or exported in a profile sourced before a GUI launch).
  3. Start Remote Control → "Remote Control Initialization failed".
  4. launchctl unsetenv ANTHROPIC_API_KEY, remove the export, fully restart VS Code, retry → Remote Control initializes.

Expected

Remote Control eligibility should key off the active auth source — which the client has already resolved to Max (it renders it in /status) — not the mere presence of ANTHROPIC_API_KEY in the environment.

Actual

Any environment containing ANTHROPIC_API_KEY is rejected, conflating "key present but unused" with "key is the active auth."

Hypothesis (not log-confirmed)

The presence check appears to run as a blunt pre-flight before auth resolution, so it can't distinguish "key present but unused" from "key is the active auth." The information to do it right exists by the time /status renders. I did not capture debug-log evidence; happy to gather --debug output if useful.

Related

  • #58127 (docs) notes API-key auth disables web-only Claude.ai features, but does not treat the env-presence-vs-active-auth gate as a defect.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗