NO_PROXY missing Docker service hostname 'api-proxy' — Node.js undici routes internal traffic through Squid

[lpcox]

Problem

When the api-proxy sidecar is enabled, AWF adds the api-proxy IP (172.30.0.30) to NO_PROXY but not the Docker service hostname api-proxy. Node.js undici (used by Pi provider and other Node-based runtimes) performs string-based hostname matching against NO_PROXY entries — it does not resolve the hostname to an IP before checking.

As a result, fetches to http://api-proxy:10000/reflect are tunneled through Squid via CONNECT api-proxy:10000, which Squid rejects (403 or DNS failure) because api-proxy isn't in the domain allowlist and isn't a real external hostname.

Evidence

From the UNDICI debug trace in gh-aw#35381:

[gh-aw/pi-provider] awf-reflect: fetching http://api-proxy:10000/reflect
UNDICI 177: connecting to api-proxy:10000:10000 using http:undefined
UNDICI 177: connecting to 172.30.0.10:3128:3128 using http:undefined
UNDICI 177: connected to 172.30.0.10:3128:3128 using http:h1
UNDICI 177: sending request to CONNECT http://172.30.0.10:3128api-proxy:10000/

curl to the same URL succeeds because it resolves the hostname first and matches the IP against NO_PROXY.

Root Cause

In src/services/agent-environment/proxy-environment.ts:

// Line 25 — only adds the IP, not the hostname
environment.NO_PROXY += `,${networkConfig.proxyIp}`;

Proposed Fix

Add api-proxy (the Docker Compose service name) alongside the IP:

environment.NO_PROXY += `,${networkConfig.proxyIp},api-proxy`;

This ensures both IP-matching clients (curl) and hostname-matching clients (Node.js undici) bypass the proxy for internal api-proxy traffic.

Related

• gh-aw PR with workaround and diagnostics: Harden Pi smoke reflect fetch with startup retries, proxy bypass, diagnostics, and Node debug logging gh-aw#35381
• Affects: Pi provider, and any Node.js runtime that fetches internal api-proxy endpoints by hostname