You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the Gemini engine under network isolation (network: defaults), every run logs 60–72 CONNECT localhost:8080 → 403 TCP_DENIED entries in its firewall report. The agent's MCP client repeatedly tries to reach the in-container MCP gateway at localhost:8080through the squid egress proxy, which denies it (deny-default). MCP eventually connects via the awmg-mcpg topology hostname and runs succeed, so this is harmless startup-retry noise — but it's noisy, alarming ("MCP issues detected. Run /mcp list for status." prints on every run), and wastes ~50s of retries.
The compiler sets MCP_GATEWAY_HOST_DOMAIN="localhost", so the Gemini CLI's MCP client is pointed at http://localhost:8080/mcp/<server>.
The AWF agent entrypoint sets HTTP_PROXY/HTTPS_PROXY=http://<squid>:3128 but no NO_PROXY.
The Gemini CLI honors HTTP_PROXY but ignores NO_PROXY, so it tunnels localhost:8080 through squid via CONNECT.
The squid ACL allowlists real egress domains (and the awmg-mcpg topology peer) but has no dstdomain localhost — loopback is only represented as dst 127.0.0.1 / broken .127.0.0.1/.::1dstdomain entries. So CONNECT localhost:8080 matches no allow rule → deny-default.
Allowlisting loopback via the local network ecosystem — the firewall emits dstdomain .127.0.0.1 / .::1 (broken leading-dot IP rules) and never dstdomain localhost, so CONNECT localhost:8080 is still denied.
NO_PROXY=localhost,127.0.0.1,::1 at the workflow level (forwarded via awf --env-all) — the Gemini CLI ignores NO_PROXY, so it still proxies loopback.
Suggested fixes (upstream)
Address the MCP gateway by the allowlisted topology hostname (awmg-mcpg:8080) instead of localhost:8080 for the Gemini engine — the auto-allow-topology-hostnames ACL (firewall [plan] Upgrade lipgloss to stable v1.1.0 release #6473) already permits it; or
Set NO_PROXY/no_proxy=localhost,127.0.0.1,::1 in the agent container entrypoint so loopback bypasses squid regardless of engine; or
Emit a real dstdomain localhost allow rule (not .127.0.0.1/.::1) when loopback is allowlisted.
Summary
With the Gemini engine under network isolation (
network: defaults), every run logs 60–72CONNECT localhost:8080 → 403 TCP_DENIEDentries in its firewall report. The agent's MCP client repeatedly tries to reach the in-container MCP gateway atlocalhost:8080through the squid egress proxy, which denies it (deny-default). MCP eventually connects via theawmg-mcpgtopology hostname and runs succeed, so this is harmless startup-retry noise — but it's noisy, alarming ("MCP issues detected. Run /mcp list for status."prints on every run), and wastes ~50s of retries.Environment
v0.83.4, AWF firewallv0.27.42, MCP gatewayv0.4.6gemini(gemini --yolo --skip-trust --output-format stream-json)network: defaults(squid egress isolation,isolation:true,topologyAttach:["awmg-mcpg"])Root cause
MCP_GATEWAY_HOST_DOMAIN="localhost", so the Gemini CLI's MCP client is pointed athttp://localhost:8080/mcp/<server>.HTTP_PROXY/HTTPS_PROXY=http://<squid>:3128but noNO_PROXY.HTTP_PROXYbut ignoresNO_PROXY, so it tunnelslocalhost:8080through squid viaCONNECT.awmg-mcpgtopology peer) but has nodstdomain localhost— loopback is only represented asdst 127.0.0.1/ broken.127.0.0.1/.::1dstdomainentries. SoCONNECT localhost:8080matches no allow rule →deny-default.Audit sample (
agent/sandbox/firewall/logs/audit.jsonl):{"event":"http_access","client":"172.30.0.20","host":"localhost:8080","method":"CONNECT","status":403,"decision":"TCP_DENIED","url":"localhost:8080"}Firewall report:
What does NOT fix it (tested on live runs)
localnetwork ecosystem — the firewall emitsdstdomain .127.0.0.1/.::1(broken leading-dot IP rules) and neverdstdomain localhost, soCONNECT localhost:8080is still denied.NO_PROXY=localhost,127.0.0.1,::1at the workflow level (forwarded viaawf --env-all) — the Gemini CLI ignoresNO_PROXY, so it still proxies loopback.Suggested fixes (upstream)
awmg-mcpg:8080) instead oflocalhost:8080for the Gemini engine — the auto-allow-topology-hostnames ACL (firewall [plan] Upgrade lipgloss to stable v1.1.0 release #6473) already permits it; orNO_PROXY/no_proxy=localhost,127.0.0.1,::1in the agent container entrypoint so loopback bypasses squid regardless of engine; ordstdomain localhostallow rule (not.127.0.0.1/.::1) when loopback is allowlisted.Happy to test a fix. Thanks!