NanoClaw runs its agents in containers. It gives them access to Gmail, GitHub, Stripe and the rest without ever handing them a credential, and it does that with a proxy. So in this project, unlike the fifty four before it, the variable you were about to use is already doing a job. We read release v2.3.0 on 20 September 2026.
The variable is taken
Inside the agent container, the proxy variable points at a local gateway. Their own skill file tells the agent why that works:
Standard HTTP clients (curl, fetch, requests, axios, Go net/http, git) all honor the
HTTPS_PROXYenvironment variable automatically. You do not need to set any auth headers.
The gateway is described as a transparent proxy that injects stored credentials into outbound calls. The agent calls the real API URL. The credentials are added at the proxy boundary.
| Where | What the proxy there is | Does your address belong there |
|---|---|---|
| inside the agent container | the credential gateway | no, overwriting it removes credential injection |
| the host environment | not forwarded into the agent at all | no, it has no effect |
| the gateway's own outbound calls | whatever you configure there | yes |
The second row is worth spelling out, because it is the next thing people try. From their security document: the agent container starts with only a timezone and provider declared variables. Host environment variables, including secrets, are never forwarded into it.
The locked down case
There is an optional mode that makes this even clearer, and it is off by default.
With egress lockdown on, agents sit on an internal Docker network with no route to the internet. The gateway container is attached to it and aliased, so the injected proxy URL resolves container to container. In their words: the gateway is the only reachable hop, and anything else has nowhere to go. The agent runs non root without network administration rights, so it cannot undo this.
Three switches control it, all read from the host service rather than the container. The lockdown flag, which defaults to off, the network name, and the gateway container name.
And it fails in the right direction. If lockdown is on and the network or gateway is missing, NanoClaw refuses to spawn the agent and says why. It never silently falls back to open egress.
Why they did not trust a variable
The sentence that opens that section is the best summary of this problem we have read anywhere:
The
HTTPS_PROXYenv var only redirects proxy-aware clients
The rest of their sentence says that a tool ignoring it, or a raw socket, could reach the internet directly and bypass credential injection, approvals and audit.
That is exactly right. A proxy variable is a routing convenience, not a control. They closed the gap at the network layer instead.
Where your address belongs
So if you want this agent's traffic to leave from a different address, put it where the gateway makes its outbound calls, or under that host.
That has two advantages beyond simply working. Credential injection stays intact, because you never touched the agent's variable. And it is one fixed machine rather than every container, which is the shape address authentication is built for. No password sits in any configuration, and the gateway host is allowed by its address.
We will not walk through configuring the gateway itself. It is a separate product whose code is not in this repository. What this page can tell you is which of the three obvious places is the right one.
Which proxy type fits it?
Residential, for the services that answer a hosting address differently. Our own paired test is the size of that effect: 4 of 13 sites answered a residential address differently from a server one, using plain requests of the kind these API calls are.
The traffic is small. This agent calls messaging and service APIs rather than loading pages, so a per gigabyte line goes a long way. On a Residential Premium plan your gateway host's address can be allowed, up to 150 per plan. That suits a design which goes to some trouble to keep credentials out of containers. The residential proxies page lists the plans, and the plan API manages allowed addresses from code.
What breaks
- Your credentials stopped being injected. You overwrote the proxy variable inside the agent.
- You exported a proxy on the host and nothing changed. Host variables are not forwarded into the container.
- A tool cannot reach the internet. With lockdown on, anything that ignores the proxy variable fails by design.
- The agent will not start at all. Lockdown is on and the network or the gateway is missing. That refusal is deliberate.
- You put a login in a URL. User information inside URLs is rejected in this project.
What this page does not cover
We read the release as text and did not run the agent, so we did not watch a request reach the gateway, did not enable lockdown and did not measure traffic. We read the gateway skill, the security document and the template rules closely. The gateway is a separate product whose code is not in this repository, so we describe its role from this project's documentation rather than its own. This project pushes daily and the release we read is four weeks old. Its changelog shows the credential path has already been replaced once. We will read it again by 20 October 2026.
Where to go from here
Proxies for OpenClaw covers the larger agent this one is an alternative to. Proxies for ZeroClaw covers an agent that lets you route per service. Proxies for PicoClaw covers one that makes an explicit exception so a guard does not block your own proxy.
Sources
- The gateway skill describing a transparent proxy that injects credentials and requiring the proxy variable (container/skills/onecli-gateway/SKILL.md). The egress lockdown section with its internal network, its only reachable hop, its fail fast behaviour, its three switches and its statement about what a proxy variable can redirect, plus the note that host variables are never forwarded (docs/SECURITY.md). The rejection of user information inside URLs (templates/README.md). nanocoai/nanoclaw, release v2.3.0 of 24 August 2026, read 20 September 2026.
- Our paired address test of 19 September 2026: 16 URLs, plain requests, two runs from our server and two through a residential line of our house plan. Raw output is kept in the research folder of our OpenClaw page.
- Plans, allowed addresses and per gigabyte pricing. HProxy documentation, hproxy.com/docs, 20 September 2026.
