Native updater ignores standard proxy environment variables

npx impeccable update fails on managed/corporate networks where direct access to GitHub is unavailable or DNS-filtered, even when standard proxy environment variables are configured and the proxy works correctly.

The native engine uses ureq, but its current build does not enable proxy support from the environment:

crates/context/Cargo.toml

ureq = { version = "2", default-features = false, features = ["tls", "json"] }

crates/skills/Cargo.toml has the same feature set.

The shared agent builder also only installs the custom TLS trust configuration:

crates/context/src/http.rs

pub fn agent_builder() -> ureq::AgentBuilder {
    ureq::AgentBuilder::new().tls_config(tls_config())
}

As a result, HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY do not affect native bundle or engine downloads.

Reproduction

On my machine:

HTTPS_PROXY=http://127.0.0.1:7892
HTTP_PROXY=http://127.0.0.1:7892
ALL_PROXY=socks5://127.0.0.1:7892

npx impeccable update --user

The local proxy is reachable and supports both HTTP CONNECT and SOCKS5.

For example, fetching the release signature explicitly through the HTTP proxy succeeds:

curl -fL -x http://127.0.0.1:7892 \
  https://github.com/pbakaus/impeccable/releases/download/skill-v4.3.1/universal.zip.sig.json

But npx impeccable update fails with:

Download failed: Could not verify skill bundle:
https://github.com/pbakaus/impeccable/releases/download/skill-v4.3.1/universal.zip.sig.json:
Connection Failed: Connect error: Connection refused (os error 111)

strace -f -e trace=connect shows the native process bypassing the configured proxy and connecting directly:

104.26.x.x:443   # impeccable.style — succeeds
127.0.0.1:443    # github.com — fails

The 127.0.0.1 address comes from the corporate DNS resolver:

github.com -> 127.0.0.1

This is intentional network filtering rather than a broken local proxy. Direct GitHub access is unavailable, while access through the configured HTTP proxy works.

The signed-bundle flow introduced for #479 makes this particularly visible because the redirect from impeccable.style is followed by a request for the GitHub-hosted .sig.json file.

Expected behavior

Native HTTP requests should honor the conventional proxy environment variables, so users behind corporate proxies, filtered DNS, VPNs, or similar network setups can use the updater without requiring a system-wide TUN.

Suggested fix

Enable ureq proxy support for the native downloader, for example:

ureq = {
    version = "2",
    default-features = false,
    features = ["tls", "json", "proxy-from-env", "socks-proxy"]
}

and, if desired, make the behavior explicit in the shared agent builder:

pub fn agent_builder() -> ureq::AgentBuilder {
    ureq::AgentBuilder::new()
        .tls_config(tls_config())
        .try_proxy_from_env(true)
}

socks-proxy matters when ALL_PROXY is configured with a socks5:// URL. In ureq 2.x the environment lookup checks ALL_PROXY before HTTPS_PROXY / HTTP_PROXY, so enabling only environment proxy discovery can otherwise select a SOCKS proxy that the build cannot use.

An alternative would be to document and support an Impeccable-specific proxy setting, but honoring the conventional environment variables would match tools such as curl, npm, and many other CLI clients.

Current workaround

Downloading the bundle through curl and then passing the local file to Impeccable works:

curl -fL -x http://127.0.0.1:7892 \
  -o /tmp/universal.zip \
  https://github.com/pbakaus/impeccable/releases/download/skill-v4.3.1/universal.zip

IMPECCABLE_BUNDLE_PATH=/tmp/universal.zip \
  npx impeccable update --user

A system-wide TUN also works because it intercepts the native TCP connection below the application layer, but requiring TUN for a CLI updater is considerably heavier than respecting the user's proxy configuration.

Reviewed at engine 0.1.5 / npm [email protected] (crates/ on main).

AI assistance disclosure: this issue was prepared with AI assistance under reporter direction.