[Bug]: Fetch tool ignores HTTP_PROXY/HTTPS_PROXY — uses bare reqwest::Client bypassing proxy configuration

[sleicht]

Description

The ForgeFetch tool (crates/forge_services/src/tool_services/fetch.rs) creates its own bare reqwest::Client via Client::new(), completely bypassing the proxy-aware, properly configured HTTP client used by the rest of the application (ForgeHttpInfra in crates/forge_infra/src/http.rs).

Since the workspace enables the hickory-dns Cargo feature for reqwest, the bare client attempts direct DNS resolution, which fails in corporate proxy environments even when HTTP_PROXY/HTTPS_PROXY environment variables are correctly set.

The main ForgeHttpInfra client already handles this correctly by calling .hickory_dns(false) on the builder — the fetch tool just needs the same treatment.

Steps to Reproduce

1. Set HTTP_PROXY and HTTPS_PROXY to a corporate proxy (e.g. http://proxy.corp:8080)
2. Use the fetch tool to load any URL (e.g. https://example.com)
3. Observe: Failed to fetch URL https://example.com/: error sending request for url
4. Meanwhile, curl https://example.com works fine (respects proxy env vars)

Root Cause

In crates/forge_services/src/tool_services/fetch.rs:

impl ForgeFetch {
    pub fn new() -> Self {
        Self { client: Client::new() }  // bare client, no proxy/hickory config
    }
}

vs. the properly configured client in crates/forge_infra/src/http.rs:

let mut client = reqwest::Client::builder()
    // ... timeouts, TLS, etc.
    .hickory_dns(http.hickory)  // defaults to false — proxy-safe
    // ...

Suggested Fix

Either:

1. (Preferred) Have ForgeFetch accept and use the shared ForgeHttpInfra client instead of constructing its own
2. (Minimal) Disable hickory-dns on the fetch client:

pub fn new() -> Self {
    Self {
        client: Client::builder()
            .hickory_dns(false)
            .build()
            .unwrap()
    }
}

Related

• PR fix: disable hickory-dns in auth HTTP client #2828 — fixes the same hickory-dns issue for the auth HTTP client, but not for fetch
• PR fix(auth): route HTTPS traffic through HTTP_PROXY when no HTTPS proxy is set #2744 (closed) — proxy routing fix for auth

Environment

• Forge Code version: 2.1.140
• OS: macOS (ARM64)
• Corporate proxy via HTTP_PROXY/HTTPS_PROXY env vars
• curl works correctly through the proxy

[sleicht]

Update: Root Cause is Two-Fold

After investigation and testing, hickory_dns(false) alone is not sufficient. There are two issues:

1. Hickory-DNS bypasses proxy DNS resolution

Client::new() inherits the workspace-wide hickory-dns cargo feature, causing direct DNS lookups that bypass HTTP_PROXY/HTTPS_PROXY.

Fix: Call .hickory_dns(false) on the client builder.

2. TLS interception — corporate proxy CA not trusted

Many corporate proxies perform SSL/TLS interception (MITM), re-signing every HTTPS certificate with a corporate CA. Since reqwest is built with rustls-tls (using webpki-roots), it only trusts the standard Mozilla CA bundle and rejects the proxy's re-signed certificates.

For example, in our environment the proxy re-signs with:

issuer: CN=Swisscom Proxy Sub CA for Sanitas Grundversicherungen AG

curl works because it uses the system certificate store (/opt/homebrew/etc/openssl@3/cert.pem), which includes the corporate CA. The ForgeHttpInfra main client works because LLM API endpoints (e.g. googleapis.com) are in NO_PROXY and bypass the proxy entirely.

Fix: Load additional root CA certificates from well-known environment variables:

1. FORGE_ROOT_CERT_PATHS — comma-separated list of PEM/DER paths (Forge-specific)
2. SSL_CERT_FILE — single PEM bundle (common convention)
3. NODE_EXTRA_CA_CERTS — single PEM file (Node.js convention)
4. REQUESTS_CA_BUNDLE — single PEM bundle (Python convention)

Verified Working

Both fixes together resolve the issue. PR incoming.