What Problem This Solves

Fixes an issue where users with HTTP_PROXY / HTTPS_PROXY (or their lowercase variants) set in the Gateway process environment see web_fetch silently use direct connections instead of routing through the configured proxy. On networks that block direct egress (corporate firewalls, regional proxies), this causes confusing web_fetch timeouts with no operator feedback about the missing tools.web.fetch.useTrustedEnvProxy opt-in.

The tools.web.fetch.useTrustedEnvProxy option has existed since the original landing for this surface, but there is no in-product surface that tells operators it exists or that their proxy env vars are being ignored. Users discover the option via changelogs, GitHub issues, or community channels.

Closes #95560.

Why This Change Was Made

Adds a diagnostic warning that fires in three existing surfaces — openclaw doctor, openclaw status, and openclaw security audit --deep — when any of HTTP_PROXY, HTTPS_PROXY, http_proxy, or https_proxy is present in the Gateway process environment but tools.web.fetch.useTrustedEnvProxy is not enabled. The change is diagnostic-only:

• web_fetch routing is unchanged
• The SSRF DNS-pinning boundary in src/infra/net/fetch-guard.ts is unchanged
• No default config value changes
• No auto-flip of the opt-in (a hard-flip would interact poorly with the open NO_PROXY work in web_fetch useTrustedEnvProxy ignores NO_PROXY env variable #93807 and was explicitly declined by the reporter)

Detection delegates to the existing per-protocol predicate hasEnvHttpProxyConfigured("http", env) || hasEnvHttpProxyConfigured("https", env) from src/infra/net/proxy-env.ts. The web_fetch runtime resolves tools.web.fetch.useTrustedEnvProxy in src/agents/tools/web-fetch.ts and passes that value into the guarded fetch env-proxy dispatch path in src/infra/net/fetch-guard.ts, which calls shouldUseEnvHttpProxyForUrl() before constructing the proxy dispatcher. The warning gate therefore stays tied to the HTTP(S) env vars that the web_fetch dispatcher considers:

• lowercase HTTP/HTTPS env vars take precedence over uppercase,
• an empty lowercase value intentionally shadows the uppercase value,
• ALL_PROXY / all_proxy alone do not fire — the per-protocol helper only reads HTTP_PROXY / HTTPS_PROXY / http_proxy / https_proxy, and the web_fetch dispatcher (built with no explicit options at fetch-guard.ts:528) does not honor ALL_PROXY for HTTP/HTTPS even when useTrustedEnvProxy is on,
• a bare NO_PROXY=* / no_proxy=* value suppresses the warning — matchesNoProxy() treats that exact value as bypass-everything, so enabling the opt-in could not route any web_fetch request through the proxy and the recommendation would be misleading. * entries inside comma/whitespace-separated lists are skipped per-entry by that matcher (only the bare value is all-bypass), so partial NO_PROXY lists still warn.

Prior art in this repo: this PR mirrors the shape of #74271 (PR #74433, fix(doctor): warn when OPENCLAW_GATEWAY_TOKEN env overrides gateway.auth.token config) — pure resolver in src/gateway/ + integration into the same three doctor / status / security-audit surfaces + per-surface unit tests + severity: "warn". The remediation text follows the canonical SSRF framing already used by the docs/tools/web-fetch.md trusted-env-proxy guidance.

Scope boundaries (deliberate)

• The resolver lives at src/gateway/web-fetch-proxy-source-conflict.ts to mirror the [Feature]: doctor/status should warn when OPENCLAW_GATEWAY_TOKEN in ~/.openclaw/.env overrides gateway.auth.token #74271 precedent path (src/gateway/auth-token-source-conflict.ts). The subject is a tools.web.fetch.* concern, so src/agents/tools/ would also be a defensible location; the precedent path is kept for minimum-diff review against the precedent.
• Explicit tools.web.fetch.useTrustedEnvProxy: false also produces the warning. The runtime gate at web-fetch.ts is === true, so undefined and explicit false route web_fetch direct identically; treating them the same in the diagnostic is consistent with runtime behavior. Operators who explicitly opted out for SSRF safety see one informational line per doctor run rather than a silent miss; this matches the precedent's "no per-finding suppression" stance.
• Explicit tools.web.fetch.enabled: false suppresses the warning. When the tool is disabled, web_fetch cannot make direct requests, so the proxy opt-in diagnostic would be misleading.
• Bare NO_PROXY=* suppresses the warning (see gate description above): with every target bypassed, the remediation could never change routing. Per-target NO_PROXY routing behavior after opt-in remains out of scope — sibling issue web_fetch useTrustedEnvProxy ignores NO_PROXY env variable #93807 owns that surface (fix(web-fetch): respect NO_PROXY when useTrustedEnvProxy is enabled #94541, #93807: fix: respect NO_PROXY in web_fetch useTrustedEnvProxy mode #93840, fix(web-fetch): respect NO_PROXY env var when useTrustedEnvProxy is enabled #93860).

User Impact

Operators with HTTP_PROXY / HTTPS_PROXY set who run openclaw doctor, openclaw status, or openclaw security audit --deep see a Security-section warning that names the env var, points at tools.web.fetch.useTrustedEnvProxy, and explains the SSRF / DNS-pinning trade-off of enabling it. Operators without proxy env vars, with the opt-in already enabled, with web_fetch explicitly disabled, or with NO_PROXY=* bypassing every target see no warning. There is no behavior change for web_fetch itself.

Evidence

Fresh-base merge update

Merged openclaw/openclaw@76a236da5fa into the PR branch with a signed merge commit (6dafc2c64aa), then added the NO_PROXY=* gate as signed commit 0287d4a4233 (current head).

$ git diff --name-status upstream/main...HEAD
M	src/commands/doctor-security.test.ts
M	src/commands/doctor-security.ts
M	src/commands/status.scan.config-shared.test.ts
M	src/commands/status.scan.config-shared.ts
A	src/gateway/web-fetch-proxy-source-conflict.ts
M	src/security/audit-gateway-config.ts
M	src/security/audit-gateway.test.ts

$ git diff --check upstream/main...HEAD
# clean

main kept advancing during proof (f180638e878 at push time); 0 commits in 76a236da..f180638e touch the 7 PR files or the dependency surface (proxy-env.ts, web-fetch.ts), and git merge-tree --write-tree upstream/main HEAD is conflict-free, so the branch was intentionally not re-merged again.

Focused regression on the three changed surfaces

$ node scripts/run-vitest.mjs src/security/audit-gateway.test.ts
Tests  17 passed (17)
$ node scripts/run-vitest.mjs src/commands/doctor-security.test.ts src/commands/status.scan.config-shared.test.ts
Tests  64 passed (64)

Red-first: the four new suppression tests (NO_PROXY=* on doctor/status/audit plus lowercase no_proxy=* on doctor) were added before the resolver change and fail against the previous head — the warning is still emitted — then pass with the gate. Coverage now includes:

• positive uppercase HTTP_PROXY / HTTPS_PROXY, positive lowercase http_proxy / https_proxy, mixed case
• empty-lowercase-shadows-uppercase, matching undici precedence
• ALL_PROXY / all_proxy only stays negative (dispatcher does not honor those here)
• tools.web.fetch.useTrustedEnvProxy: true stays negative
• tools.web.fetch.enabled: false stays negative across doctor, status, and security audit
• new: NO_PROXY=* and lowercase no_proxy=* suppress across doctor, status, and security audit
• new: NO_PROXY="*,localhost" (a * entry inside a list) still warns, matching matchesNoProxy() per-entry skip
• new: partial NO_PROXY=internal.example.com still warns
• new: blank lowercase no_proxy= shadowing NO_PROXY=* still warns, matching undici precedence
• doctor test env isolation now saves/clears/restores NO_PROXY / no_proxy, so a machine-level NO_PROXY cannot flip the suite

Full built CLI proof

Built and exercised head 0287d4a4233 in a fresh isolated clone with Node v24.15.0:

$ corepack pnpm install --frozen-lockfile   # exit 0
$ corepack pnpm build                       # exit 0, total 2m 34.1s

The built output contains the new gate:

$ grep -o 'if ((params.env.no_proxy ?? params.env.NO_PROXY) === "*") return null;' dist/web-fetch-proxy-source-conflict-DO90MGiu.js
if ((params.env.no_proxy ?? params.env.NO_PROXY) === "*") return null;

Then ran the built CLI (node dist/entry.js) with isolated OPENCLAW_HOME / OPENCLAW_STATE_DIR / OPENCLAW_CONFIG_PATH and HTTP_PROXY=http://127.0.0.1:7897, across four env/config sets, three surfaces each (doctor --non-interactive, status --json --timeout 1000, security audit --deep --json; all runs exit 0):

1. Positive control (no NO_PROXY, default config): all three surfaces report the diagnostic.

[Security]
- WARNING: HTTP_PROXY set without tools.web.fetch.useTrustedEnvProxy.
  Detected HTTP_PROXY in the process environment, but
  tools.web.fetch.useTrustedEnvProxy is not enabled, so web_fetch will
  use direct connections and ignore the configured proxy. ...

status: secretDiagnostics contains the opt-in diagnostic; audit: findings include tools.web.fetch.env_proxy_without_use_trusted_env_proxy (warn).

2. NO_PROXY=* (all-bypass): the diagnostic is gone from all three surfaces.

• doctor stdout/stderr: "useTrustedEnvProxy is not enabled" absent, "web_fetch will use direct connections" absent
• status: "secretDiagnostics": []
• audit: matching findings for tools.web.fetch.env_proxy_without_use_trusted_env_proxy: []

3. NO_PROXY=internal.example.com (partial): the diagnostic is present on all three surfaces — partial bypass lists do not suppress.

4. tools.web.fetch.enabled: false (no NO_PROXY): the diagnostic stays absent on all three surfaces, re-proven at this head.

Assertion sweep over the captured outputs: 10/10 target-string checks passed (3 positive-control present, 4 all-bypass absent, 3 partial present).

Local gates

• corepack pnpm install --frozen-lockfile / corepack pnpm build: exit 0 with Node v24.15.0
• node scripts/run-oxlint.mjs on the 4 touched files: 0 warnings, 0 errors
• oxfmt --check on the 4 touched files: clean
• pnpm tsgo:core and pnpm tsgo:core:test: exit 0
• git diff --check upstream/main...HEAD: clean

What was not tested

• A packaged npm/tarball install path. The proof above builds this PR head from source and runs the built dist/entry.js CLI.
• Per-target NO_PROXY routing behavior after the opt-in is enabled (sibling web_fetch useTrustedEnvProxy ignores NO_PROXY env variable #93807 owns that surface). This PR only recognizes the bare NO_PROXY=* all-bypass value in the diagnostic gate.

Risks / Mitigations

• Risk: Diagnostic noise for operators who explicitly set useTrustedEnvProxy: false. Mitigation: Matches runtime semantics (=== true gate); message is informational and points at the trade-off.
• Risk: The resolver lives under src/gateway/ but its subject is tools.web.fetch.*. Mitigation: Mirrors the [Feature]: doctor/status should warn when OPENCLAW_GATEWAY_TOKEN in ~/.openclaw/.env overrides gateway.auth.token #74271 precedent path for ease of review. Easy to move in a follow-up if the maintainer prefers a different placement.
• Risk: Accidentally suppressing the diagnostic for normal proxy-env users. Mitigation: Suppression happens only for tools.web.fetch.enabled: false or the exact bare NO_PROXY=* / no_proxy=* value that matchesNoProxy() treats as bypass-everything. Positive control and partial-NO_PROXY built-CLI runs plus the per-surface positive tests prove normal proxy users still see the warning.