Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

generateImage runtime in runtime-CRr5T-P1.js does not propagate the user's ssrfPolicy.allowRfc2544BenchmarkRange setting into the image-generation provider HTTP path, so image-generation providers (e.g. google, minimax) are blocked by SSRF guard whenever the user runs behind a fake-IP proxy (Clash TUN, Surge, etc.) that resolves outbound hostnames to 198.18.0.0/15 — even when the user has explicitly set allowRfc2544BenchmarkRange: true at the runtime level.

Steps to reproduce

1. Install OpenClaw 2026.4.22 on a host running Clash with TUN mode (so nslookup api.minimaxi.com returns an address in 198.18.0.0/15).
2. Configure agent runtime with ssrfPolicy.allowRfc2544BenchmarkRange: true (the same flag that already enables generic fetch tools to reach those hosts).
3. Run any image-generation request that targets a configured provider whose hostname resolves into the 198.18.0.0/15 block (e.g. google Gemini, minimax).
4. Observe that the agent response surfaces a Hostname not allowed / SSRF block error from the image provider call, while a plain fetch tool against the same host succeeds.

Expected behavior

Image-generation providers should honor the same ssrfPolicy.allowRfc2544BenchmarkRange flag that the generic fetch tool honors. Per openclaw-tools-D2PgzZeK.js:8353-8377 (generic fetch tool path), the flag is read from params.ssrfPolicy?.allowRfc2544BenchmarkRange and threaded into the policy passed to the underlying HTTP layer; the same threading should apply to provider.generateImage(...) calls.

Actual behavior

generateImage in node_modules/openclaw/dist/runtime-CRr5T-P1.js:160-205 builds the provider call with this argument set:

provider.generateImage({
  provider, model, prompt, cfg, agentDir, authStore,
  count, size, aspectRatio, resolution, inputImages
})

No ssrfPolicy is forwarded. The downstream image-generation providers (e.g. image-generation-provider-4T53ms0v.js, etc.) call fetchWithSsrFGuard from fetch-guard-DTBKKyU3.js without inheriting the user-configured allowRfc2544BenchmarkRange, so the IP rule in ip-BDZZzbo_.js:156-158 flags 198.18.x.x as blocked.

The ssrfPolicy schema itself is already declared in the agent-runtime config (plugin-sdk/src/config/zod-schema.agent-runtime.d.ts:141, :227, :1069) and :515-516 documents the flag for "fake-IP proxy compatibility (e.g., Clash TUN mode, Surge)" — so the configuration surface already exists and works for other tools; image generation is the one path missing the wiring.

OpenClaw version

2026.4.22

Additional context

• Workaround in place locally: route image generation through a separate path (e.g. local codex CLI subprocess for vision/generation) that bypasses the OpenClaw fetch guard entirely.
• The same code path likely affects other media-generation capabilities (TTS / video / etc.) that go through similar provider runtime modules — worth a wider audit while fixing this.
• I noticed comparable threads in Heartbeat isolated mode: cadence stalls, 'heartbeat last' mislabels exec-events, lightContext stays heavy, heartbeat-state writer appears missing #65161 and Cron session accumulation can silently exhaust agent context window — no guardrails or warnings #38730 around isolated/light contexts and SSRF-adjacent behavior; flagging here for cross-reference, but this report is specifically about media-generation provider plumbing missing the existing ssrfPolicy flag.