Bug type

Behaviour bug (incorrect output/state without crash)

Summary

web_search and web_fetch still fail in TRUSTED_ENV_PROXY mode on v2026.3.31 when local DNS is unavailable and all outbound traffic must go through a trusted HTTP CONNECT proxy.

This is distinct from the strict-mode proxy fix merged in #50650. In both main and v2026.3.31, fetchWithSsrFGuard() still calls resolvePinnedHostnameWithPolicy() before branching to the trusted env-proxy path, so the request fails on local DNS before EnvHttpProxyAgent is ever created.

Steps to reproduce

1. Run OpenClaw in a sandboxed environment where HTTP_PROXY / HTTPS_PROXY are configured and local DNS is intentionally unavailable.
2. Trigger web_search or web_fetch through the trusted web-tool path.
3. Observe getaddrinfo EAI_AGAIN ... before the request reaches the proxy dispatcher.

Expected behaviour

When trusted env-proxy mode is selected, OpenClaw should skip local DNS pinning and let the trusted proxy resolve DNS.

Actual behaviour

OpenClaw still performs local DNS resolution first and fails with EAI_AGAIN, so web tools are unusable in proxy-only sandboxes.

OpenClaw version

2026.3.31

Operating system

Linux sandbox / proxy-only network namespace

Additional details

Current source in both main and v2026.3.31 still has this ordering:

assertExplicitProxySupportsPinnedDns(...);
const pinned = await resolvePinnedHostnameWithPolicy(...);
const canUseTrustedEnvProxy =
  mode === GUARDED_FETCH_MODE.TRUSTED_ENV_PROXY && hasProxyEnvConfigured();
if (canUseTrustedEnvProxy) {
  dispatcher = new EnvHttpProxyAgent();
}

That means trusted env-proxy mode never gets a chance to run if DNS is blocked locally.

Related context

• #46306 was closed as fixed by #50650, but that fix addressed the strict-mode env-proxy path rather than the trusted env-proxy ordering bug.
• #58034 appears to address the correct branch ordering, but this is still reproducible on v2026.3.31 and current main as shipped today.