HTTP proxy strips/modifies auth headers causing Claude Code Remote Control (CCR) bridge 401/403 failures

[ethiery]

Summary

Claude Code's Remote Control (/rc) feature fails inside sandboxes with repeated 401/403 errors. The initial session creation succeeds, but subsequent SSE streaming and worker registration calls are rejected, suggesting the sandbox HTTP proxy is interfering with authentication headers on these requests.

Reproduction steps

1. Start a Claude Code session inside a sandbox
2. Run a successful /login with the "Claude account with subscription" method
3. Run /debug to make Claude Code write debug logs to a file
4. Run /rc or /remote-control
5. Connection fails with "Remote Control failed · Transport closed (code 4091)" in the bottom right of the terminal and "worker_register_failed" in the debug log

Observed behavior

The CCR bridge session is created successfully, and bridge credentials are fetched. However, immediately after:

• The SSE event stream to api.anthropic.com/v1/code/sessions/{id}/worker/events/stream returns HTTP 403 (permanent)
• The worker registration PUT to api.anthropic.com/v1/code/sessions/{id}/worker returns HTTP 401
• GET polls to the same worker endpoint return 401 on every retry (up to 10 attempts), then exhausts retries

Relevant log entries:

[DEBUG] [remote-bridge] Created session cse_014jGpDmeKLwnuMcGT4UxWx3                                                                                                                                                                                                                                                                                                           
[DEBUG] [remote-bridge] Fetched bridge credentials (expires_in=14400s)                                                                                                                                                                                                                                                                                                         
[DEBUG] [remote-bridge] v2 session URL: https://api.anthropic.com/v1/code/sessions/cse_014jGpDmeKLwnuMcGT4UxWx3                                                                                                                                                                                                                                                                
[ERROR] SSETransport: HTTP 403 (permanent)                                                                                                                                                                                                                                                                                                                                     
[DEBUG] [remote-bridge] v2 transport closed (code=403)                                                                                                                                                                                                                                                                                                                         
[WARN]  CCRClient: GET .../worker returned 401 (attempt 1/10)                                                                                                                                                                                                                                                                                                                  
[WARN]  CCRClient: PUT worker (init) returned 401                                                                                                                                                                                                                                                                                                                              
[ERROR] [bridge:repl] CCR v2 initialize failed: CCRClient init failed: worker_register_failed                                                                                                                                                                                                                                                                                  
[WARN]  CCRClient: GET .../worker returned 401 (attempt 2/10)                                                                                                                                                                                                                                                                                                                  
...                                                                                                                                                                                                                                                                                                                                                                            
[ERROR] CCRClient: GET retries exhausted                        

Expected behavior

The remote control bridge should connect successfully after session creation and credential fetch both succeed.

Analysis

The session creation (POST .../sessions) and credential fetch work fine through the proxy, so basic API auth is passing through. However, the bridge endpoints (/worker/events/stream, /worker, /worker/events) fail with 401/403, which suggests the proxy may be:

1. Stripping or rewriting the Authorization header on SSE/streaming requests specifically
2. Not forwarding the bridge-specific bearer token (which differs from the main API OAuth token)
3. Treating long-lived SSE connections differently from standard request/response calls

The bridge credentials are fetched successfully (line: Fetched bridge credentials (expires_in=14400s)), so the token itself is valid — it's just not arriving at the upstream server intact.

Environment

• Claude Code version: 2.1.89
• sbx version: 0.23.0
• default balanced network policy (api.anthropic.com:443 allowed)

[nunziati]

Confirming this bug persists on sbx 0.27.0-69-g99d2a21e (4 releases after the OP's 0.23.0). Same Transport closed (code 4091) after worker_register_failed, on a different Linux distro than usually tested.

Environment

• OS: Pop!_OS 24.04 LTS (Ubuntu noble base), kernel 6.17.9
• sbx: 0.27.0-69-g99d2a21e
• Claude Code: 2.1.119
• Auth: OAuth via /login inside the sandbox (Claude subscription)
• Network policy: Balanced default, no custom rules

Same-host A/B with Docker Desktop

On the exact same machine, docker sandbox from Docker Desktop 4.71.0 (225177) works fine — RC connects and stays stable. This matches @xiaosongshu's observation in #12: the older path uses standard container networking without the GoProxy MITM, while sbx forces everything through gateway.docker.internal:3128.

So the bug reproduces across:

• sbx versions (0.23.0 → 0.27.0)
• Linux distros (Pop!_OS 24.04 here, presumably others in HTTP proxy strips/modifies auth headers causing Claude Code Remote Control (CCR) bridge 401/403 failures #8//remote-control with Claude Code #12)

…and is contradicted on the same host by the legacy Docker Desktop sandbox path.

Possibly useful detail from sbx policy log

SANDBOX          HOST                            PROXY            RULE             COUNT
claude-rc-test   api.anthropic.com:443           forward          domain-allowed   2
claude-rc-test   mcp-proxy.anthropic.com:443     forward-bypass   domain-allowed   3
claude-rc-test   downloads.claude.ai:443         forward-bypass   domain-allowed   5
claude-rc-test   platform.claude.com:443         forward          domain-allowed   1

Sibling Anthropic-controlled hosts already use forward-bypass (no MITM) — only api.anthropic.com is on forward, presumably because that's where credential injection is wired. If credential injection isn't actually needed when the user authenticates via OAuth /login inside the sandbox (the token lives inside the VM, the proxy doesn't need to inject anything), then api.anthropic.com could go through forward-bypass for that auth path and the streaming endpoints would just work — without changes to GoProxy's WebSocket/SSE handling.

Happy to test patches or nightly builds with verbose proxy logs if useful.

[nkugland]

Confirming on sbx v0.31.1, macOS Apple Silicon. Same Transport closed (code 4091) / worker_register_failed pattern.

Adding a second independent blocker not mentioned yet: remote-control.anthropic.com has no public DNS record (NXDOMAIN). The sbx VM's internal DNS resolver does not consult /etc/hosts, so adding a static hosts entry doesn't help. Even after running sbx policy allow network for the domain, the proxy logs show forward-bypass + because DNS resolution fails inside the VM.

Host CC works because it bypasses DNS entirely -- it connects directly to a hardcoded IP (160.79.104.10) without going through the proxy. That path isn't available inside the microVM.

Verified via sbx policy log:

• remote-control.anthropic.com:443 → forward-bypass → (DNS fails inside VM)
• 160.79.104.10:443 → forward-bypass → domain-allowed-ip (TCP + TLS + HTTP/2 all succeed)

The failure then continues as described above -- CC switches to hostname-based requests to api.anthropic.com for worker registration and hits the auth header stripping (401/403), retries exhaust, Transport closed.

An additional fix that may be needed: VM DNS resolver should honor /etc/hosts, or sbx should support static host-to-IP mappings for domains without public DNS records. Whether this is blocking independently of the auth header issue is unconfirmed.

Workaround: run Claude Code outside the sandbox for Remote Control sessions.

[phawrylak]

This bug makes Remote Control (/rc) unusable inside sandboxes, and that's exactly the feature needed to operate a Claude Code agent remotely while keeping it isolated. The only workaround - running the agent outside the sandbox - defeats the whole purpose of sbx, since you lose isolation precisely for the unattended/remote workflows where it matters most.

Could the team please consider raising the priority on this? It blocks remote operation of an isolated agent. Thanks in advance!

[phawrylak]

Following up - I got Claude Remote Control running fully inside an sbx sandbox (stable) with a small in-VM proxy shim. Sharing how it routes, since it pins down exactly which requests need an exception.

Root cause (confirming OP): on api.anthropic.com the forward proxy rewrites Authorization unconditionally. That's correct for inference and for the RC calls that use the main OAuth (session-create, credential-fetch) - which is why those pass. But RC's worker/work-lease/transcript planes authenticate with per-session scoped tokens, not the OAuth, so the rewrite clobbers them → worker 401 / SSE 403 / worker_register_failed.

How the shim works: a tiny mitmproxy addon in the VM, in front of the agent. It defaults everything to sbx's forward proxy (injection unchanged), and only forces a request direct (skipping injection) when both are true:

1. the path matches the scoped-token regex below, and
2. the outgoing Authorization/x-api-key does not contain sbx's proxy-managed sentinel (i.e. it's already a real scoped token, not the placeholder).

Direct egress still leaves the VM through sbx's transparent proxy, so network policy is still enforced - only credential injection is skipped.

Paths to except (all on api.anthropic.com) - single regex against the request path:

^/v1/(?:code/sessions/[^/]+/|environments/[^/]+/work/|sessions/[^/]+/events)

Suggested fix - two options for the team:

• Cleaner / future-proof: make injection conditional on the sentinel - only rewrite Authorization when the outgoing header still carries the proxy-managed placeholder; if a real bearer token is already present, pass it through. No path list to maintain.
• Surgical: add a forward-bypass exception on api.anthropic.com for exactly the regex above (don't bypass the whole host - create/register need injection).

For me the auth fix alone was enough - I didn't hit the remote-control.anthropic.com NXDOMAIN path @nkugland mentioned (RC rode api.anthropic.com/v1/code/sessions/... as in OP's logs), so that may be version-specific.

Happy to test a nightly with a fix candidate.

[jrhender]

I pushed my/Claude's implementation of @phawrylak's shim approach here: https://github.com/jrhender/sbx-claude-code-rc-shim , in cause that helpful for folks to use themselves.

[rltas]

While this works, and I use similar workarounds in other places like Chrome DevTools for example, I wish there was an official solution, especially now that we got MCP OAuth working inside the VM too.

It's 36°C here atm and it's really a burden that I have to get out of the pool just to check my agents' progress 😑

[lbureau-billettiqueservices]

Same problem here. It's very frustrating to not be able to combine the quality of life of remote control with the security of the sandbox. I hope a solution will be pushed soon.