Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Browser navigation is blocked when HTTP_PROXY / HTTPS_PROXY are set [2 pull requests, 3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#71358•Fetched 2026-04-26 05:13:32
View on GitHub
Comments
3
Participants
3
Timeline
8
Reactions
0
Author
zdg1110zdg1110
Participants
Sanjays2402Sanjays2402steipetesteipetezdg1110zdg1110
Timeline (top)
commented ×3cross-referenced ×2closed ×1labeled ×1

Browser navigation fails with "Navigation blocked: strict browser SSRF policy cannot be enforced while env proxy variables are set" when HTTP_PROXY / HTTPS_PROXY are present in the gateway environment.

Error Message

Error message:

Root Cause

Severity:

  • Medium, because browser navigation is blocked in this setup.

Fix Action

Fixed

PR fix notes

PR #71361: fix: respect NO_PROXY in browser navigation SSRF guard

Description (problem / solution / changelog)

Summary

Browser navigation is blocked with "strict browser SSRF policy cannot be enforced while env proxy variables are set" when HTTP_PROXY/HTTPS_PROXY are configured in the gateway environment — even for normal public URLs that don't go through the proxy.

Root Cause

The navigation guard in assertBrowserNavigationAllowed() checks hasProxyEnvConfigured() as a blanket block. When proxy env vars exist and dangerouslyAllowPrivateNetwork isn't enabled, all browser navigation is rejected. The guard doesn't consider NO_PROXY, which tells the network stack to bypass the proxy for matching URLs.

Fix

  1. Export matchesNoProxy from plugin-sdk/browser-security-runtime (already implemented in src/infra/net/proxy-env.ts)
  2. Re-export it in the browser extension's proxy-env.ts
  3. In the navigation guard, add a !matchesNoProxy(url) check: if the target URL matches NO_PROXY, the proxy won't route that traffic, so SSRF IP-based checks remain enforceable

Workaround for users

Users can now add browser targets to NO_PROXY:

export NO_PROXY="localhost,127.0.0.1,docs.openclaw.ai"

Or use * to bypass proxy for all browser traffic while keeping it for provider requests (which use their own fetch path).

Error message improvement

Updated the error message to suggest NO_PROXY as a fix:

Navigation blocked: strict browser SSRF policy cannot be enforced while env proxy variables are set. Set NO_PROXY to bypass the proxy for browser targets, or set browser.ssrfPolicy.dangerouslyAllowPrivateNetwork to true.

Fixes #71358

Changed files

  • extensions/browser/src/browser/navigation-guard.ts (modified, +28/-8)
  • extensions/browser/src/infra/net/proxy-env.ts (modified, +1/-1)
  • src/plugin-sdk/browser-security-runtime.ts (modified, +1/-1)

PR #71401: fix(browser): allow public-URL navigation when env proxy is set

Description (problem / solution / changelog)

Summary

  • Remove blanket block that prevented all browser navigation when HTTP_PROXY/HTTPS_PROXY env vars were set
  • Defer to per-hostname DNS resolution check: public URLs resolving to public IPs are allowed, private/internal destinations remain blocked
  • Fixes #71358

Fix Details

Previously, when HTTP_PROXY or HTTPS_PROXY env vars were set, assertBrowserNavigationAllowed would throw InvalidBrowserNavigationUrlError for all navigation, including legitimate public-internet browsing. This was overly broad.

The fix removes the blanket proxy-env block and relies on the existing resolvePinnedHostnameWithPolicy DNS resolution check downstream, which correctly:

  • Allows hostnames resolving to public IPs (e.g., 93.184.216.34)
  • Blocks hostnames resolving to private IPs (e.g., 127.0.0.1)

Before/After

ScenarioBeforeAfter
HTTP_PROXY set + public URLBlockedAllowed
HTTP_PROXY set + private URLBlockedBlocked
No proxy + public URLAllowedAllowed (no change)
No proxy + private URLBlockedBlocked (no change)

Test plan

  • Updated existing test: "allows navigation to public IPs when env proxy is configured"
  • New test: "blocks navigation to private IPs when env proxy is configured"
  • All 23 navigation-guard unit tests pass
  • TypeScript compilation passes (tsc --noEmit)

🤖 Generated with Claude Code

Closes #71358

Changed files

  • extensions/browser/src/browser/navigation-guard.test.ts (modified, +13/-2)
  • extensions/browser/src/browser/navigation-guard.ts (modified, +5/-7)

Code Example

Error message:
Navigation blocked: strict browser SSRF policy cannot be enforced while env proxy variables are set

Diagnostics bundle:
openclaw-diagnostics-2026-04-25T01-44-44-684Z-15811.zip
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Browser navigation fails with "Navigation blocked: strict browser SSRF policy cannot be enforced while env proxy variables are set" when HTTP_PROXY / HTTPS_PROXY are present in the gateway environment.

Steps to reproduce

  1. Start OpenClaw with HTTP_PROXY / HTTPS_PROXY set in the gateway environment.
  2. Use the browser tool to open a normal public page such as https://docs.openclaw.ai/faq.
  3. Observe navigation failure with: "Navigation blocked: strict browser SSRF policy cannot be enforced while env proxy variables are set".

Expected behavior

Browser navigation should either work for normal public pages in this setup, or OpenClaw should document the officially supported way to separate browser traffic from provider traffic that requires proxy.

Actual behavior

Browser navigation fails with: "Navigation blocked: strict browser SSRF policy cannot be enforced while env proxy variables are set".

Observed behavior in my environment:

  • With HTTP_PROXY / HTTPS_PROXY set: browser navigation fails, but OpenAI Codex / GPT-5.4 works.
  • Without HTTP_PROXY / HTTPS_PROXY: browser navigation works again, but OpenAI Codex / GPT-5.4 stops working.

OpenClaw version

2026.4.23 (a979721)

Operating system

macOS

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

openai-codex -> chatgpt.com/backend-api

Additional provider/model setup details

Gateway is started via LaunchAgent. Proxy is configured through environment variables in LaunchAgent. OpenAI Codex / GPT-5.4 requires proxy in this environment.

I also tested provider-level explicit proxy for openai-codex, but removing gateway env proxy still caused the Codex path to fail in my setup.

Local code match: /opt/homebrew/lib/node_modules/openclaw/dist/chrome-CEcd-itj.js

Matched logic: if (hasProxyEnvConfigured() && !isPrivateNetworkAllowedByPolicy(opts.ssrfPolicy)) throw new InvalidBrowserNavigationUrlError("Navigation blocked: strict browser SSRF policy cannot be enforced while env proxy variables are set");

Logs, screenshots, and evidence

Error message:
Navigation blocked: strict browser SSRF policy cannot be enforced while env proxy variables are set

Diagnostics bundle:
openclaw-diagnostics-2026-04-25T01-44-44-684Z-15811.zip

Impact and severity

Affected users/systems:

  • Users who need both browser navigation and provider traffic that requires proxy in the same gateway environment.

Severity:

  • Medium, because browser navigation is blocked in this setup.

Frequency:

  • 100% reproducible in my environment.

Consequence:

  • Browser tool navigation cannot be used while HTTP_PROXY / HTTPS_PROXY are set.

Additional information

This report is about browser navigation, not Telegram replies.

The diagnostics bundle attached for this report is: openclaw-diagnostics-2026-04-25T01-44-44-684Z-15811.zip

extent analysis

TL;DR

The issue can be resolved by separating browser traffic from provider traffic that requires a proxy, potentially by configuring provider-level explicit proxy settings.

Guidance

  • Review the OpenClaw documentation for officially supported methods to separate browser traffic from provider traffic that requires a proxy.
  • Consider configuring provider-level explicit proxy settings for OpenAI Codex / GPT-5.4, as testing this approach showed promise.
  • Investigate the isPrivateNetworkAllowedByPolicy function in the chrome-CEcd-itj.js file to understand the conditions under which the strict browser SSRF policy can be enforced.
  • Verify that removing the gateway environment proxy variables allows browser navigation to work, while also ensuring OpenAI Codex / GPT-5.4 functionality is maintained through alternative proxy configurations.

Example

No code snippet is provided, as the issue is more related to configuration and setup rather than a specific code fix.

Notes

The solution may depend on the specific requirements of the OpenAI Codex / GPT-5.4 model and the gateway environment. Further testing and configuration may be necessary to find a working solution.

Recommendation

Apply a workaround by configuring provider-level explicit proxy settings, as this approach has shown potential in resolving the issue without requiring a version upgrade.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Browser navigation should either work for normal public pages in this setup, or OpenClaw should document the officially supported way to separate browser traffic from provider traffic that requires proxy.

#api#ssr#indexing error#inference speed#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Browser navigation is blocked when HTTP_PROXY / HTTPS_PROXY are set [2 pull requests, 3 comments, 3 participants]