[BUG] Remote Control bridge registration sent as plaintext HTTP through proxy instead of CONNECT-tunneling

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Remote Control fails to register whenever an HTTP proxy is configured via HTTPS_PROXY / HTTP_PROXY. claude remote-control (and --remote-control, and remoteControlAtStartup: true) aborts at registration with an HTTP 400.

The Remote Control bridge client does not CONNECT-tunnel HTTPS through the proxy. It sends the registration request to the proxy in forward-proxy absolute-form over a cleartext connection, so the upstream receives plaintext and rejects it. The normal Anthropic API client works fine over the same proxy (it CONNECT-tunnels correctly), so only the Remote Control bridge path is broken.

Side effect: the Authorization: Bearer token is transmitted in cleartext to the proxy and onward (the error message itself warns about this). With remoteControlAtStartup: true, this fires on every session start.

What Should Happen?

The bridge client should honor HTTPS_PROXY by issuing CONNECT api.anthropic.com:443 and then performing TLS to the origin, exactly as the main Anthropic API client already does. Registration should succeed through an HTTP proxy, and the bearer token should never be sent in cleartext.

Error Messages/Logs

Error: Registration: Failed with status 400: This request was sent over HTTP. Only HTTPS is supported for API use. Consider revoking your API key, as it was sent in plaintext over the internet with this request.

# What the bridge client actually sends to the proxy, captured by pointing
# HTTPS_PROXY at a local logging listener:
POST https://api.anthropic.com/v1/environments/bridge HTTP/1.1
Authorization: Bearer sk-ant-oat01-<REDACTED>
anthropic-version: 2023-06-01
anthropic-beta: environments-2025-11-01
x-environment-runner-version: 2.1.193
User-Agent: claude

# Expected instead: a CONNECT tunnel ->  CONNECT api.anthropic.com:443  (then TLS to origin)

Steps to Reproduce

1. Start any HTTP forward proxy locally, e.g. tinyproxy / squid / mitmproxy on 127.0.0.1:8888 (or a tiny TCP listener that logs the first bytes, to inspect what the client emits).
2. Launch Remote Control through it:

``
HTTPS_PROXY=http://127.0.0.1:8888 HTTP_PROXY=http://127.0.0.1:8888 \
claude remote-control --spawn=same-dir
``

1. Registration fails immediately with the HTTP 400 shown above.
2. To confirm the cause: point HTTPS_PROXY at a listener that logs the first request bytes. The client sends POST https://api.anthropic.com/v1/environments/bridge HTTP/1.1 (absolute-form, cleartext) instead of CONNECT api.anthropic.com:443.

Notes:

• The normal API path over the same proxy works (it CONNECT-tunnels), so this is specific to the bridge client.
• Tried and did not help: NODE_USE_ENV_PROXY=1; HTTPS_PROXY only (with HTTP_PROXY unset); ALL_PROXY. All reproduce the identical error.

Claude Model

Not sure / Multiple models (not model-related; this is a networking/registration bug).

Is this a regression?

No, this never worked.

Claude Code Version

2.1.193 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other (terminal-independent; reproduces in a non-interactive invocation too).

Additional Information

• Root cause is in the bridge client's proxy handling, not the proxy itself: a forward HTTP proxy correctly CONNECT-tunnels the main client's HTTPS to api.anthropic.com; only the /v1/environments/bridge registration is emitted in absolute-form cleartext.
• Security impact worth prioritizing: the OAuth bearer token (sk-ant-oat01-...) is sent in cleartext, and remoteControlAtStartup: true triggers this on every session start.
• Searched existing issues before filing. Closest are #65801 (distinct: bridge is reachable, token rejected upstream) and #1382 (old main-client corporate-proxy 400, since fixed). This report is specifically the Remote Control bridge client not CONNECT-tunneling through an HTTP proxy.