Feature request: allow Remote Control when ANTHROPIC_BASE_URL is a transparent local proxy to api.anthropic.com
Title
Feature request: allow Remote Control when ANTHROPIC_BASE_URL is a transparent local proxy to api.anthropic.com
Body
Version: claude-code 2.1.197 (also observed on 2.1.195)
OS: Fedora Linux 43, kernel 7.0.8
Setup
I run Claude Code as a long-lived tmux-hosted session (a home-automation "assistant" project) that gets remotely restarted via a small internal API. For the daily-driver session I route traffic through a local, open-source token-compression reverse proxy (ANTHROPIC_BASE_URL=http://localhost:8787) that forwards every request unmodified to the real https://api.anthropic.com — it only compresses large tool-result payloads to reduce token usage, it does not change model routing, auth, or add any third-party backend.
Actual behavior
Running /remote-control <name> (or claude remote-control --name <name>) in a session where ANTHROPIC_BASE_URL is set to this proxy immediately fails:
Error: Remote Control is only available when using Claude via api.anthropic.com.
[debug] Remote Control auth state:
isBareMode=false
hasOAuthAccessToken=true
oauthScopes=user:file_upload,user:inference,user:mcp_servers,user:profile,user:sessions:claude_code
hasClaudeAIInferenceScope=true
isClaudeAISubscriber=true
hasProfileScope=true
oauthAccount.organizationUuid=set
ANTHROPIC_API_KEY=unset
ANTHROPIC_AUTH_TOKEN=unsetAuth/subscription state is otherwise completely valid (isClaudeAISubscriber=true, valid OAuth scopes) — the only difference from a normal session is ANTHROPIC_BASE_URL.
Expected behavior / request
Remote Control should work as long as the effective upstream is verifiably api.anthropic.com (e.g. resolved through a local reverse proxy that only forwards/compresses requests without changing destination, auth, or content), not just when ANTHROPIC_BASE_URL is literally unset/default.
Possible approaches:
- Allow Remote Control when
ANTHROPIC_BASE_URLis set but the proxy declares (e.g. via a response header, or a documented opt-in flag) that it forwards unmodified to the real API. - Or provide an explicit escape hatch (e.g.
CLAUDE_REMOTE_CONTROL_TRUST_PROXY=1) for advanced users who run their own local infra and understand the security tradeoff.
Why this matters
This blocks combining Claude Code's own official Remote Control feature with self-hosted token-compression tooling — currently the only workaround is to run the remote-controllable session with zero compression, which reintroduces the exact token-cost problem the proxy exists to solve.
Happy to provide more debug output or test a patch if useful.
5 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I'm having the same issue. What can we do about this? Is there a way to extend transparent proxies to support RC?
+1 this impacts my organization as well, and I want to add an enterprise data point since our setup differs a bit from the original report.
My organization requires all outbound AI traffic to route through a company-managed AI gateway (ANTHROPIC_BASE_URL points at our internal endpoint, which forwards to api.anthropic.com). This isn't optional on our side — it's a compliance/network requirement, not a personal optimization.
The key thing I want to flag: Remote Control was working fine for us through the gateway until a recent update. That suggests this gating was newly introduced or tightened, so for us it reads as a regression rather than a missing feature. Our auth/subscription state is all valid — the only thing tripping the check is that ANTHROPIC_BASE_URL isn't unset.
Both proposed approaches would unblock us:
Gating on "does traffic actually reach api.anthropic.com" rather than "is ANTHROPIC_BASE_URL literally unset" would cover both the transparent-proxy and enterprise-gateway cases. Happy to provide debug output or test a patch.
Adding a macOS + VS Code extension datapoint, because on this surface the gate is now completely silent about its cause - which makes the "at minimum, a visible notice" ask in #76653 (just closed into this issue) the practically urgent part.
Environment
anthropic.claude-code-2.1.236-darwin-arm64, macOS Darwin 27.0.0 (Apple Silicon)ANTHROPIC_API_KEY/ANTHROPIC_AUTH_TOKENunsetANTHROPIC_BASE_URL=http://127.0.0.1:18791- a loopback reverse proxy that forwards every request unmodified toapi.anthropic.comand passes theAuthorizationheader through verbatimWhat the extension surfaces
Not the CLI's explicit "Remote Control is only available when using Claude via api.anthropic.com" from the original report. The extension host log shows only this:
Same millisecond as the auth check, no cause named, and nothing bridge-related ever reaches the proxy - its access log across 55,372 requests contains only
/v1/messages,/v1/messages/count_tokensand/api/hello. The panel just shows a red "Remote Control error: Remote Control initialization failed" banner. There is no mention ofANTHROPIC_BASE_URLanywhere in the error, the banner, or the log.Why this got worse recently, not better
#62149 was fixed in 2.1.224, so the extension now honors
remoteControlAtStartupand fires auto-enable on every panel session launch. For anyone in this thread who also uses the VS Code extension, that means the base-URL gate is no longer a quiet missing menu item - it is a red error banner at the top of every new session, attributed to nothing.Cost of the missing diagnostic in my case: I went through the extension bundle, the native binary, and the launch path before finding bcherny's answer in #72382.
unset ANTHROPIC_BASE_URLfixes it instantly and Remote Control has worked perfectly since.So, ranked by what would have helped most:
127.0.0.1base URL is the same trust domain as the CLI process itself).If you are using a genuine proxy to send traffic on to anthropic then
export HTTPS_PROXY=...works and remote control is still enabled