mirror of
https://github.com/deepseek-ai/deepseek-harness.git
synced 2026-09-07 04:10:42 +00:00
Yichen Jiang
6de470e61b
Review found `127.0.0.2` routed through the proxy. The bypass list carries four literal loopback entries because that is all a consumer reading an environment can match, and `proxyForUrl` matched only those — leaving the rest of `127.0.0.0/8`, `0.0.0.0`, and the IPv4-mapped spellings routed through a proxy that could then reach them. Loopback is now recognised structurally, which a list entry cannot express; the published entries stay for the environment readers. The same review case exposed a wider one. `web_fetch` skips its address checks on a proxied hop, because the proxy resolves the origin — but a literal needs no resolution, so the skip bought nothing and let a proxy on this machine reach every private range those checks refuse, `169.254.169.254` included. A literal the checks would refuse now takes the validated path, where the existing refusal already covers it. Tests that proved a tunnelled hop used a loopback origin, which no policy can route through a proxy any more. They name a host only the proxy can answer for instead — closer to what a proxied request actually looks like. The user guide promised the proxy carried every outbound request including telemetry. It carries neither on an older Node, nor anything a model-authored script sends, so the promise is narrowed and the exceptions listed. A password in a proxy URL reaching every tool DSH runs is documented there too: it is how the variable already behaves, and worth knowing before putting one in.
