[FEATURE] Remote Control: allow localhost proxies (loopback exception or opt-in for ANTHROPIC_BASE_URL=http://127.0.0.1:*)

Status Closed — duplicate

Reported on v2.1.196

Maintainer reply None cached

Activity 4 comments · opened Jul 11, 2026 · closed Aug 20, 2026

Summary

Since v2.1.196, Remote Control is disabled whenever ANTHROPIC_BASE_URL points at any host other than api.anthropic.com (changelog: "Remote Control is now disabled when ANTHROPIC_BASE_URL points at a non-Anthropic host"). This also gates loopback proxies (http://127.0.0.1:*), which breaks a legitimate and growing workflow: running Claude Code through a local optimization/audit proxy (context compression, prompt-cache handling, local savings metering) while still being able to hand a session off to claude.ai/code or the mobile app.

Please consider a loopback exception — or an explicit opt-in — so local proxies and Remote Control can coexist.

Reproduction

Claude Code ≥ v2.1.196, logged in via a Pro/Max subscription (/login).
export ANTHROPIC_BASE_URL=http://127.0.0.1:8787 (any local reverse proxy that forwards to api.anthropic.com, passing the OAuth Authorization header through untouched).
Start claude → /remote-control is missing from the command menu; the session never appears on claude.ai/code.
unset ANTHROPIC_BASE_URL → works again. Last version where the combination worked: v2.1.138.

Why a loopback exception is reasonable

A 127.0.0.1/localhost base URL is the user's own machine — the same trust domain as the CLI process itself, not a remote MITM. The proxy never sees anything the local Claude Code process doesn't already see.
Auth is untouched: these proxies pass the Authorization/x-api-key headers through verbatim; Anthropic's backend still authenticates the same subscription.
The current behavior is a silent capability loss: the command simply disappears, and users debug their proxy for hours before finding the version gate.

Proposed options (any would help, in order of preference)

Loopback exception: allow Remote Control when the ANTHROPIC_BASE_URL host is 127.0.0.1/localhost/::1.
Explicit opt-in: e.g. CLAUDE_CODE_REMOTE_CONTROL_WITH_PROXY=1 or a settings.json key, keeping the safe default.
At minimum, a visible notice when the gate disables Remote Control ("disabled because ANTHROPIC_BASE_URL is set"), instead of the command silently vanishing.

Who this affects

Users of local LLM proxies/gateways in front of Claude Code — e.g. the open-source Headroom proxy community hit this too: https://github.com/headroomlabs-ai/headroom/issues/1779. Related (auth-token variant of the same gate): #59062; broader session-handoff ask: #71731.

Environment: Claude Code ≥ 2.1.196, macOS 14, subscription login.

View original on GitHub ↗

3 Comments

turing · 1 month ago

This would be a fantastic addition for those of us using the rtk + headroom setup.

kwu18-png · 1 month ago

We've been encountering this same limitation in production with TeamoRouter (an AI API gateway), and wanted to share our perspective as a proxy operator serving developers who rely on ANTHROPIC_BASE_URL.

The real-world impact is significant for two user groups:

Developers in regions with unreliable direct API access: Many of our users are in China and Southeast Asia, where direct connections to api.anthropic.com can be unstable. They use ANTHROPIC_BASE_URL to route through a local proxy/gateway for stable connectivity. Losing Remote Control means losing the ability to share interactive Claude Code sessions with teammates — a key collaboration feature.

Enterprise users with compliance requirements: Some organizations require all API traffic to pass through an internal gateway for auditing, rate limiting, and cost tracking. These are legitimate enterprise security requirements, not attempts to circumvent licensing.

Technical observation: The loopback exception (127.0.0.1 / localhost) would cover the API gateway use case — most proxy setups use localhost or a local network address. A more general approach would be an allowlist (environment variable or config) letting users explicitly opt-in trusted proxy endpoints.

From the gateway operator side, we'd also be happy to implement any validation or attestation mechanism Anthropic would find acceptable — e.g., signing requests, registering proxy endpoints, or providing transparency about model routing.

Appreciate the team looking into this — Remote Control is genuinely valuable for collaborative Claude Code workflows.

Farhan27sadik · 29 days ago

Confirming on Windows 11 — this issue is labeled platform:macos, but the gate is platform-independent.

Claude Code 2.1.220, Windows 11 Pro (26200), Claude Max subscription (OAuth login)
Local proxy: Headroom 0.33.0 on http://127.0.0.1:8787, ANTHROPIC_BASE_URL set via ~/.claude/settings.json
Same outcome as the macOS report: the v2.1.196+ eligibility check applies and /remote-control is not available.

Everything else through the loopback proxy works normally — 131 API requests, 0 failures, both claude-opus-5 and claude-sonnet-5 routing fine — so this is purely the base-URL eligibility check, not a connectivity or auth problem. The proxy passes the OAuth Authorization header through untouched, exactly as the original report describes.

Worth flagging for prioritization: Windows users currently have no workaround.

The transparent-proxy proof of concept in the linked Headroom thread (headroomlabs-ai/headroom#1779) depends on iptables DNAT, so it is Linux-only. The other approach under discussion there — leaving ANTHROPIC_BASE_URL unset and routing via HTTPS_PROXY + NODE_EXTRA_CA_CERTS — requires the proxy to implement a CONNECT/TLS-MITM transport that does not exist yet. So on Windows the only option today is running Claude Code without the proxy for any session that needs Remote Control, which means giving up context optimization entirely for that session.

Option 1 (loopback exception) would resolve this cleanly. Failing that, option 3 (a visible notice) would at least stop people from debugging their proxy setup for hours — the command currently just disappears from the menu with no explanation of why.

Showing cached comments. Read the full discussion on GitHub ↗