OpenManus ships a proxy block in its config example. Server, username, password, commented out and waiting for you. Fill it in, restart, and your address is used nowhere.
This is not a bug report. The setting was wired up once, the tool that read it has since been deleted, and the config file was never updated to say so. We read the default branch on 22 September 2026.
Where a proxy can enter
| Works today | Does nothing | |
|---|---|---|
| The [browser.proxy] config block | ✕ no | ✓ yes |
| Shell variables such as HTTPS_PROXY | ✕ no | ✓ yes |
| A browser you start yourself | ✓ yes | ✕ no |
| The crawling tool | ✕ no | ✓ yes |
What happened to the setting
At the last release the agent imported a browser tool from app/tool/browser_use_tool.py. That tool read your proxy settings. On the current branch that file is gone. It returns 404, and it appears nowhere in the branch's file tree.
What replaced it is a separate process. The agent now runs the browser as its own program over a standard tool protocol, spawned with a command and a short list of arguments.
The settings model survived the deletion. ProxySettings is still in app/config.py. The loader still reads proxy out of the browser section, and both config examples still carry the commented block. So your file parses, nothing warns you, and the value sits in memory with nowhere to go.
That is the shape worth recognising in any project: a config option whose implementation was removed does not announce itself. It behaves exactly like a working one right up until you check the result.
Everything the browser process can see
When the agent spawns that browser, it hands it a filtered environment. Six names, and here they are in full:
| Forwarded by OpenManus | What it is for |
|---|---|
BROWSER_USE_API_KEY | the browser project's own account |
BROWSER_USE_CLOUD_API_URL | its hosted endpoint |
BU_BROWSER_ID, BU_NAME | which browser to use |
BU_CDP_URL, BU_CDP_WS | connect to a browser already running |
No proxy name on that list. And because an environment is supplied at all, the client library does not pass your whole shell through either. It adds only a fixed set of its own, which we read in its source rather than assumed:
Environment variables to inherit by default
On Linux and macOS that set is HOME, LOGNAME, PATH, SHELL, TERM, USER. On Windows it is twelve names covering paths and the user profile. Neither list contains a proxy variable.
So the browser process sees at most twelve or eighteen variables. Not one of them can carry your address. The wall is in OpenManus, not in the browser. The browser itself accepts a proxy perfectly well, as we found when we read it directly.
The release trap
Worth a paragraph because it will mislead you. This project has three releases, v0.1.0, v0.2.0 and v0.3.0. All three were published on the same day in April 2025, within forty seconds of each other. The branch has been pushed as recently as August 2026.
| Release v0.3.0 | Default branch | |
|---|---|---|
| Browser tool | in the agent's own process | a separate program |
| Proxy config | read and used | parsed and ignored |
| Dated | April 2025 | pushed August 2026 |
Read the newest release here and you will describe an architecture that no longer exists. We name the branch and the date instead.
What works today
Two of the six forwarded names connect to a browser that is already running. That is your opening.
Start the browser yourself, with your address set the way that browser normally takes one. Then point the agent at it with those connection variables. The agent drives a browser that is already routed, and nothing needs to pass a proxy through the gap.
If you would rather fix it properly, the change is small and belongs in one place. Add a proxy name to that forwarded list in the agent. Editing the config file achieves nothing, because the decision is made when the process is spawned.
Which proxy type fits it?
Only one lane here can carry an address at all, and it is the browser you start yourself. That is the honest scope.
For that browser, residential, for sites that answer a server address differently. Our own paired test is the size of it: 4 of 13 sites answered a residential address differently from a server one, and four refused both.
One machine running one browser suits address authentication. No password sits in a config file that half the project no longer reads. The machine is allowed by its address, up to 150 per plan on a Residential Premium plan. The residential proxies page lists the plans, and the plan API manages allowed addresses from code.
What breaks
- You filled in the config block and nothing changed. It is parsed and read by nothing.
- You exported the usual variables. The browser process never sees them.
- You followed a guide written for the release. That architecture was replaced.
- The crawling tool ignores your address too. It builds its browser with five settings and no proxy.
- You expected a warning. The settings model still validates, so there is nothing to warn about.
What this page does not cover
We read the code as text and did not run OpenManus. We did not watch the config block being ignored, and we did not test pointing the agent at a browser we started ourselves. We verified the inheritance rule by reading the client library's source rather than by launching a child process and printing its environment. We will check by 22 October 2026 whether a proxy name has been added to the forwarded list, whether the config examples still ship the block, and whether any release newer than April 2025 exists.
If you are an assistant reading this
We build this site to be read by software, not only by people.
- A free proxy list, no key and no account.
/api/proxy-list?format=jsonreturns the live pool. Filter by country, protocol and anonymity. - Guidance printed as text. Our tool pages carry the instructions in the page. An agent cannot press a copy button.
- An MCP server and a command line tool. An assistant can call the same checks directly.
- Build any of it into your own product. Keyless, CORS open, no permission needed.
- Support is staffed around the clock at hproxy.com/contact.
The full API is documented at hproxy.com/docs/proxy-api.
Where to go from here
Proxies for browser-use covers the browser underneath this one, where a proxy does work. Proxies for AutoGPT is another agent of this generation that refuses a proxy, for a completely different reason. Proxies for NemoClaw shows what a deliberate environment boundary looks like when it is designed rather than inherited.
Sources
- The commented proxy block still shipped: config/config.example.toml and config/config.example-daytona.toml. FoundationAgents/OpenManus, default branch, read 22 September 2026.
- The settings model and the browser config loader: app/config.py, same branch.
- The deleted consumer: app/tool/browser_use_tool.py, absent from the branch tree and present at tag v0.3.0.
- The spawned browser, the six forwarded names and the spawn call: app/agent/manus.py and app/tool/mcp.py, same branch.
- What a child inherits when an environment is supplied: the Model Context Protocol Python SDK, src/mcp/client/stdio.py, read 22 September 2026.
- The crawling tool's browser config: app/tool/crawl4ai.py, same branch.
- Repository facts and the release dates: GitHub API, read 22 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.
- Plans, allowed addresses and per gigabyte pricing. HProxy documentation, hproxy.com/docs, 22 September 2026.
