Best possible solution:

Finish maintainer review on this draft and, if the security boundary is accepted, land this narrower host-scoped policy as the superseding fix for #76530 and #76549.

Do we have a high-confidence way to reproduce the issue?

Yes, source inspection gives a high-confidence reproduction path: make provider or trusted web endpoint DNS resolve to 198.18.0.0/15 or fc00::/7 on current main and the guarded fetch path blocks it because those policy flags are absent. I did not run a live fake-IP proxy repro in this read-only review.

Is this the best way to solve the issue?

Yes, the proposed direction appears narrower than the related broad allow-host proposals because it uses target hostname allowlisting plus specific fake-IP range flags instead of general private-network bypass. Final merge should wait for the draft/protected review and completed validation.

What I checked:

• Current web-search policy gap: On current main, trusted web tools pass an empty SSRF policy and self-hosted web tools only opt into the RFC 2544 IPv4 fake-IP range, leaving IPv6 ULA fake-IP DNS answers blocked. (src/agents/tools/web-guarded-fetch.ts:10, 03e35b1d8392)
• Current model-provider policy gap: On current main, model provider transport forwards only allowPrivateNetwork; it does not set the RFC 2544 or IPv6 ULA fake-IP policy flags for provider hosts. (src/agents/provider-transport-fetch.ts:296, 03e35b1d8392)
• SSRF range behavior: The SSRF implementation blocks special-use DNS answers unless the corresponding policy flag is set, including RFC 2544 and IPv6 ULA handling. (src/infra/net/ssrf.ts:139, 03e35b1d8392)
• PR diff approach: The PR introduces a helper that combines allowRfc2544BenchmarkRange, allowIpv6UniqueLocalRange, and hostnameAllowlist, then applies it only when the request host matches the configured provider host or trusted web endpoint host. (src/infra/net/ssrf.ts:99, 63b72d9cfac9)
• Related PR context: The PR explicitly builds on fix(web-tools): exempt fake-IP DNS ranges from trusted/self-hosted SSRF policy #76530 and fix(provider-transport): pass baseUrl hostname to SSRF guard so fake-IP proxies don't block model API calls #76549, which documented fake-IP failures for web-search providers and model-provider HTTP; this PR narrows those proposals to host-scoped fake-IP allowances. (63b72d9cfac9)
• PR state: GitHub currently reports the PR as open, draft, labeled maintainer, and not mergeable, so cleanup automation should not close or route it to repair. (63b72d9cfac9)

Likely related people:

• steipete: Current checkout blame for the SSRF policy, fetch guard, provider transport, and web guarded-fetch paths points to Peter Steinberger's commit, and this PR also comes from the same maintainer handle. (role: recent maintainer and current-main code owner for this surface; confidence: medium; commits: ab0f8a79ca24; files: src/infra/net/ssrf.ts, src/infra/net/fetch-guard.ts, src/agents/provider-transport-fetch.ts)
• zqchris: The PR body credits fix(web-tools): exempt fake-IP DNS ranges from trusted/self-hosted SSRF policy #76530 and fix(provider-transport): pass baseUrl hostname to SSRF guard so fake-IP proxies don't block model API calls #76549 for the web-search and provider-transport fake-IP repros that this PR consolidates into a narrower host-scoped approach. (role: related reproducer and source-proposal contributor; confidence: medium; commits: 15a5aae6815d, 4fa5b6af2ca9; files: src/agents/tools/web-guarded-fetch.ts, src/agents/provider-transport-fetch.ts)

Remaining risk / open question:

• The cited Testbox pnpm check:changed run was still in progress at review time, so completed broad validation remains pending.
• This changes SSRF policy semantics around fake-IP DNS ranges, so the protected maintainer review should explicitly confirm the host-scoped allowance is the intended security boundary.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 03e35b1d8392.