Best possible solution:

Finish SSRF policy propagation through the image-generation contract, shared provider HTTP helper, and every image provider call path with focused regressions, then require redacted fake-IP runtime proof before merge.

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

Yes. Source inspection gives a high-confidence path: configure tools.web.fetch.ssrfPolicy.allowRfc2544BenchmarkRange, use a Google or MiniMax image provider behind fake-IP DNS, and the provider POST call still receives no RFC2544-capable policy on current main.

Is this the best way to solve the issue?

No. The direction is maintainable, but this PR must forward the new policy through all current image provider HTTP paths, not only OpenAI/OpenAI-compatible requests.

Full review comments:

• [P2] Forward the SSRF policy from every image provider — src/image-generation/types.ts:76
  This adds ssrfPolicy to the shared image-generation request, but the patch only consumes it in OpenAI/OpenAI-compatible paths. The linked bug names Google/MiniMax fake-IP provider calls, and current Google, MiniMax, OpenRouter, Vydra, and OpenAI Codex image provider POSTs still call the provider HTTP helpers without req.ssrfPolicy, so allowRfc2544BenchmarkRange remains ignored there after this patch.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.9

Security concerns:

• [medium] Complete SSRF policy propagation across image providers — src/image-generation/types.ts:76
  The patch introduces a full SSRF policy path for image-generation requests but forwards it only through part of the provider surface. Named provider paths still ignore the field, leaving security-sensitive policy behavior inconsistent and the fake-IP bug unresolved there.
  Confidence: 0.88

What I checked:

• PR diff adds a shared request policy field: The diff adds ssrfPolicy?: SsrFPolicy to ImageGenerationRequest and GenerateImageParams, so every provider implementation becomes responsible for consuming the new request field. (src/image-generation/types.ts:76, 15efb16757f7)
• Current main still lacks provider-policy plumbing: On current main, generateImage calls provider.generateImage without any SSRF policy, matching the source-level reproduction for the linked issue before this PR is applied. (src/image-generation/runtime.ts:104, 9859c23badd9)
• Tool policy currently reaches only reference media: image_generate resolves tools.web.fetch.ssrfPolicy and passes it to remote reference-image loading, but the current generateImage call at line 729 does not forward that policy to provider API calls. (src/agents/tools/image-generate-tool.ts:679, 9859c23badd9)
• Shared provider POST helper truncates policy today: resolveGuardedPostRequestOptions currently turns only allowPrivateNetwork into an SSRF policy, so allowRfc2544BenchmarkRange cannot reach provider POST helpers without the PR's helper change. (src/media-understanding/shared.ts:322, 9859c23badd9)
• Named image providers remain unwired by the PR: Google and MiniMax currently call postJsonRequest with allowPrivateNetwork and dispatcherPolicy only; the PR diff does not update those files, and OpenRouter/Vydra follow the same direct helper pattern. (extensions/google/image-generation-provider.ts:159, 9859c23badd9)
• Related issue review confirms the same gap: The linked issue review kept the bug open because current main forwards the policy to image reference media loads, but not to image-generation provider API calls, specifically calling out Google/MiniMax fake-IP behavior.

Likely related people:

• steipete: Recent blame and history put the central image-generation runtime, request types, and tool flow on Peter Steinberger's commits, including current lines involved in policy forwarding. (role: recent maintainer; confidence: high; commits: d479216d929f, 75d64cd4b8fb, 0bbb0eb73558; files: src/image-generation/runtime.ts, src/image-generation/types.ts, src/agents/tools/image-generate-tool.ts)
• vincentkoc: Recent provider transport normalization and media request shaping commits are directly adjacent to the guarded provider HTTP helper and SSRF/proxy behavior. (role: transport-policy owner; confidence: medium; commits: 6ee8e194c027, b0f94a227b3e, f28f0f29ba90; files: src/media-understanding/shared.ts, extensions/google/image-generation-provider.ts, src/agents/provider-transport-fetch.ts)
• DhtIsCoding: Recent merged proxy-mode work changed guarded remote HTTP behavior sharing the same provider-helper surface implicated here. (role: adjacent maintainer; confidence: medium; commits: f408bba9de72; files: src/media-understanding/shared.ts)

Remaining risk / open question:

• No after-fix real behavior proof was provided from a Clash/Surge or equivalent fake-IP provider setup.
• The fix touches SSRF policy propagation; incomplete or overly broad forwarding could leave provider paths broken or widen egress unexpectedly.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 9859c23badd9.