PicoClaw is a small agent written in Go that runs on modest hardware. It has a proxy setting, which puts it ahead of most of this series. It has two, in fact, and the one you find first is the one you probably do not want. We read release v0.3.1 on 20 September 2026, and checked the default branch too.
Two fields
| Field | What it routes | In the documentation |
|---|---|---|
| the web tools proxy | web searches and page fetches | no |
registries.github.proxy | installing skills from GitHub | yes |
Search the tools reference for the word proxy and you find the second one, described as an HTTP proxy for GitHub API requests. It is real and it works, and it covers skill installs only.
The field that matters is the web tools one. The agent passes it to the page fetch tool at startup, every search integration hands it to the shared client, and the web interface exposes it as an editable setting. It is simply not in the reference tables, which list the fetch size limit, the output format, the native search preference and the private host whitelist, and stop there.
So if you concluded this project can only proxy skill downloads, that is the documentation talking, not the code.
What the helper accepts
Every proxied client in the project comes from one small function, and it is strict in a good way:
An unsupported scheme does not fall back to a direct connection. It returns an error that names the four it accepts. A URL without a host is refused the same way. That is the behaviour we want from a proxy setting, because the alternative is traffic leaving from an address you did not choose.
The login goes inside the URL here. This runtime passes a userinfo part as a proxy authorization header, so http://user:pass@host:8080 is the right shape. Readers of our browser pages will notice that is the exact opposite of Chrome, which ignores a login written that way.
The h that does nothing
Plenty of good advice says the h in socks5h decides who resolves the hostname, and that leaving it off leaks your DNS. That is true of curl. It is not true here.
Go's own documentation for the HTTP client says it plainly: the supported schemes are http, https, socks5 and socks5h, and socks5 is treated the same as socks5h. Both spellings send the hostname to the proxy. PicoClaw accepts both, which is sensible, because people type the one their proxy vendor's documentation shows them.
Two ways in
The empty value in that chart is not an error and not a proxy. It means the process proxy settings are used instead.
That is a deliberate line of code, not a default. In this language a hand built HTTP transport has no proxy at all unless something sets one, and this helper sets it in both branches: your address when the field is filled, the environment when it is not.
So you can configure the field, or export the usual variables and leave the field empty. Both work, and they cover the same three places: searches, page fetches, skill installs.
The exception for your own proxy
Here is the part we want to praise, because the previous page in this series shows the alternative.
The page fetch tool uses a guarded client. It refuses to connect to private or local addresses, checks again on every redirect, and stops after ten of them. That protects an agent from being talked into fetching something on your own network.
A proxy is usually on a private address. A blanket refusal would therefore block the connection to your own proxy, so they wrote one narrow exception: the first hop to the configured proxy is allowed, and nothing else.
| Target | Allowed |
|---|---|
| a public address | yes |
| a private or local address | no |
| a redirect to a private address | no |
| the first hop to your configured proxy | yes |
Our nanobot page covers the same hazard solved the other way, by dropping the protective transport when a proxy is configured. Both are defensible. This one keeps more.
If you genuinely need an internal host, there is a documented whitelist for that rather than a flag that turns the whole guard off.
Which proxy type fits it?
Residential, for the sources 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 this fetch sends.
The traffic is small. A page fetch stops at ten megabytes by default and search results are text, so a per gigabyte line goes a long way on this tool. Two notes. This agent is built to run on small hardware, and an allowed address means no login sits in a configuration file on a device that might be imaged or shared: on a Residential Premium plan your machine's address can be allowed, up to 150 per plan. And because the guard already permits the first hop, a local forwarder in front of your line works without any extra configuration. The residential proxies page lists the plans, and the plan API manages allowed addresses from code.
What breaks
- Skills install through the proxy and searches do not. You set the documented field. The web tools have their own.
- The agent refuses to start a request. Check the scheme. Only four are accepted, and the error names them.
- Your login is ignored. Put it in the URL rather than in a separate setting.
- You added the h and nothing changed. Correct. In this runtime the two SOCKS spellings are the same.
- An internal host will not load. That is the guard. Use the whitelist rather than removing it.
What this page does not cover
We read the release as text and did not run the agent, so we did not watch a fetch use an address, did not exercise the guard and did not measure a run's traffic. We read the client helper, the guarded client, the skills installer, the search integration's call sites and the tools reference closely, and used a code search rather than reading the whole repository. We did not establish whether model provider calls go through any proxy, only the web tools and the skill installs. The release we read is from 3 July 2026 while the branch was pushed to on 17 September 2026, so a reader on the nightly build may see more. We will read it again by 20 October 2026.
Where to go from here
Proxies for nanobot covers the same private address problem solved the other way round. Proxies for OpenClaw covers a larger agent with more network paths and a harder configuration. Proxies for the Google Maps scraper covers another Go project, where a local forwarder is started for you and refuses to run without a login.
Sources
- The shared client helper with its four schemes, its errors and its environment fallback (pkg/utils/http_client.go). The guarded client, the private target dialer, the redirect check and the exception for the configured proxy (pkg/utils/http_guard.go). The call sites in the search integration and the skills installer, and the agent wiring the fetch tool with the web proxy (pkg/tools/integration/web.go, pkg/skills/installer.go, pkg/agent/agent_init.go). sipeed/picoclaw, release v0.3.1 of 3 July 2026, read 20 September 2026.
- The documented skills registry proxy, the web fetcher settings and the private host whitelist. PicoClaw tools configuration reference, docs/reference/tools_configuration.md, same release.
- The supported proxy schemes, the equivalence of socks5 and socks5h, and the userinfo handling. Go standard library, src/net/http/transport.go, 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.
