OpenClaw merged PR #98951, "fix: strict guarded fetch fails before managed proxy DNS" on July 2nd, tightening a security-sensitive network path for proxy-only deployments.
The issue affected users running OpenClaw in managed proxy-only sandboxes. Strict or default guarded fetch calls could fail locally before reaching the managed proxy when local DNS could not resolve, disagreed with, or rejected a hostname.
That undermined the deployment model for environments where the proxy is supposed to own resolution and enforcement. The PR names channel and provider preflight, plugin HTTP paths, Google Chat, Mattermost, media, and web-tool paths as affected surfaces.
What Changed
When OPENCLAW_PROXY_ACTIVE=1 and the HTTP(S) environment proxy applies to the target URL, strict guarded fetch now keeps its pre-DNS hostname and IP-literal SSRF checks, then dispatches through the managed environment proxy without resolving the target locally.
Direct strict mode still uses DNS pinning. NO_PROXY targets still use DNS pinning. Exact configured local-origin bypass candidates still resolve and pin DNS so loopback bypass policy remains enforced.
In other words, this is not a broad "trust whatever proxy env vars say" change. The proxy-aware path is limited to the OpenClaw managed proxy lifecycle.
Why It Matters
Guarded fetch is a boundary feature. It exists so plugin, channel, provider, and tool paths can fetch remote resources without accidentally reaching private networks or metadata services.
In a managed proxy-only sandbox, though, local DNS may intentionally be incomplete or unavailable. The proxy is the component that sees the target hostname, resolves it, applies operator policy, and decides whether a tunnel should exist.
Before this PR, strict guarded fetch could still call the local resolver inside that managed-proxy branch. That meant a valid proxy-owned request could fail before the proxy had a chance to enforce policy.
Security Contract
The PR body is careful about the boundary: private IP literals and blocked hostnames are still rejected before fetch, redirects are still revalidated, and ordinary strict mode does not become proxy-aware just because proxy variables exist.
The deployment contract is that the managed proxy owns target DNS and blocks unsafe resolved addresses before opening a tunnel. The proof attached to the PR demonstrates this with public, loopback, RFC1918 private, and link-local target mappings.
That distinction matters. OpenClaw is not weakening guarded fetch checks; it is moving target DNS ownership to the managed proxy only when the managed proxy mode is active and applicable.
Evidence
The PR includes focused test coverage for SSRF and proxy environment behavior, plus lint, formatting, and git diff --check validation.
The behavioral proof used a local CONNECT proxy with OPENCLAW_PROXY_ACTIVE=1, proxy environment variables, an unresolvable hostname, and a lookup function that throws if local target DNS is attempted. The managed fetch returned a successful 200 response with zero local lookup calls.
Additional proof showed the proxy allowing a public destination while denying loopback, private, and link-local targets after proxy-side DNS resolution.
Bottom Line
PR #98951 fixes a real operational mismatch between strict guarded fetch and managed proxy-only networking.
For operators using OpenClaw behind a managed proxy, fetches can now reach the enforcement boundary that is supposed to make the decision, without falling over on local DNS first.