PR #59749: fix(media-understanding): forward pinDns through postJsonRequest and postTranscriptionRequest

• Repository: openclaw/openclaw
• Author: linghaoSu
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/59749

Description (problem / solution / changelog)

Summary

• Problem: postJsonRequest() and postTranscriptionRequest() in src/media-understanding/shared.ts never forwarded a pinDns parameter to fetchWithTimeoutGuarded(), so the pinned DNS dispatcher was always used — bypassing configured env proxy (HTTP_PROXY/HTTPS_PROXY/ALL_PROXY).
• Why it matters: Google image generation (and all media understanding requests) fail with "fetch failed" for any user running the gateway behind a proxy, even with NODE_USE_ENV_PROXY=1 set. 100% repro on affected systems.
• What changed: Added pinDns?: boolean to both helper function params and forwarded it in the options object to fetchWithTimeoutGuarded(). Callers can now pass pinDns: false to disable the pinned DNS dispatcher and let native fetch respect env proxy settings.
• What did NOT change (scope boundary): No callers were updated in this PR — this is the structural fix at the shared helper layer. Caller-side changes (passing pinDns: false from Google/Moonshot providers when proxy is active) are a planned follow-up.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #59686
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: postJsonRequest and postTranscriptionRequest were written without a pinDns param. The options object passed to fetchWithTimeoutGuarded only carried ssrfPolicy (via allowPrivateNetwork), never pinDns. In fetchWithSsrFGuard, pinDns defaults to undefined, which satisfies pinDns !== false, so createPinnedDispatcher is always used — an undici dispatcher that does not respect env proxy settings.
• Missing detection / guardrail: No test covering the proxy-aware fetch path through these helpers.
• Prior context: The pinDns parameter has existed on fetchWithTimeoutGuarded and fetchWithSsrFGuard since the SSRF guard was introduced, but was never wired into the media understanding helpers.
• Why this regressed now: Not a regression — this was always missing. Became visible as more users adopted proxy-based gateway deployments.
• If unknown, what was ruled out: N/A

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/media-understanding/shared.test.ts
• Scenario the test should lock in: When pinDns: false is passed to postJsonRequest, it should appear in the options forwarded to fetchWithTimeoutGuarded.
• Why this is the smallest reliable guardrail: A seam test mocking fetchWithSsrFGuard and asserting the pinDns value in the call args directly validates the forwarding without needing a real proxy.
• If no new test is added, why not: The fix is a minimal param-threading change with no branching logic. The existing type system enforces the param is accepted, and the forwarding is a single property assignment. A dedicated test is warranted but deferred to the caller-side follow-up where the end-to-end proxy path can be tested together.

User-visible / Behavior Changes

None — no callers pass pinDns yet. This is a backwards-compatible API addition. Behavior changes will come in the follow-up when callers opt in.

Diagram (if applicable)

Before:
caller -> postJsonRequest(no pinDns) -> fetchWithTimeoutGuarded(pinDns: undefined)
  -> fetchWithSsrFGuard(pinDns: undefined) -> pinDns !== false -> createPinnedDispatcher (bypasses proxy)

After:
caller -> postJsonRequest(pinDns: false) -> fetchWithTimeoutGuarded(pinDns: false)
  -> fetchWithSsrFGuard(pinDns: false) -> pinDns === false -> no custom dispatcher -> native fetch respects env proxy

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Note: passing pinDns: false disables the pinned DNS dispatcher (an SSRF mitigation), but callers must explicitly opt in. The default (undefined) retains the existing secure behavior. The TRUSTED_ENV_PROXY mode and SSRF hostname resolution still apply when the env proxy path is used.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22+
• Model/provider: Google (gemini-3.1-flash-image-preview)
• Integration/channel (if any): Any channel using image generation
• Relevant config (redacted): HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NODE_USE_ENV_PROXY=1 set in gateway env

Steps

1. Configure proxy env vars on the gateway host
2. Send an image generation request using a Google model
3. Observe fetch failed error

Expected

• Image generation request routes through the configured proxy

Actual

• Request bypasses proxy, uses pinned DNS dispatcher, fails with fetch failed

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

pnpm tsgo — type check passes. pnpm test -- src/media-understanding/shared.test.ts — 5/5 tests pass.

Human Verification (required)

• Verified scenarios: Type check, unit tests, code review of fetchWithTimeoutGuarded and fetchWithSsrFGuard confirming undefined pinDns preserves existing behavior.
• Edge cases checked: Passing {} vs undefined as options to fetchWithTimeoutGuarded — confirmed equivalent via optional chaining on all fields.
• What you did not verify: End-to-end proxy test with a real proxy (requires proxy infrastructure). Caller-side integration (deferred to follow-up).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Callers passing pinDns: false disable DNS pinning SSRF protection for those requests.
  • Mitigation: pinDns is opt-in (default unchanged). The env proxy path (EnvHttpProxyAgent) still runs SSRF hostname resolution. Security posture is unchanged until callers explicitly opt in.

Changed files

• extensions/discord/src/monitor/agent-components-helpers.ts (modified, +2/-2)
• extensions/discord/src/monitor/agent-components.ts (modified, +8/-8)
• extensions/discord/src/monitor/message-handler.preflight.ts (modified, +3/-2)
• extensions/discord/src/monitor/message-handler.process.ts (modified, +2/-2)
• extensions/discord/src/monitor/native-command.ts (modified, +5/-5)
• extensions/discord/src/monitor/provider.ts (modified, +6/-6)
• extensions/line/src/bot-message-context.ts (modified, +1/-1)
• extensions/matrix/src/matrix/client.test.ts (modified, +1/-4)
• extensions/matrix/src/matrix/monitor/index.ts (modified, +1/-1)
• extensions/telegram/src/bot.ts (modified, +1/-1)
• extensions/whatsapp/src/auto-reply/monitor/process-message.ts (modified, +1/-1)
• src/agents/auth-profiles/usage.ts (modified, +1/-4)
• src/agents/pi-embedded-runner/run/helpers.ts (modified, +3/-1)
• src/commands/channel-setup/plugin-install.ts (modified, +5/-3)
• src/media-understanding/shared.ts (modified, +12/-12)
• src/plugin-sdk/anthropic-vertex-auth-presence.ts (modified, +1/-3)
• src/plugin-sdk/browser-config.ts (modified, +1/-1)
• src/plugin-sdk/command-surface.ts (modified, +1/-4)
• src/plugin-sdk/session-store-runtime.ts (modified, +1/-4)
• src/plugin-sdk/whatsapp-auth-presence.ts (modified, +1/-1)
• ui/src/ui/views/chat.ts (modified, +84/-109)

PR #59755: fix(media-understanding): forward pinDns through postJsonRequest and postTranscriptionRequest

• Repository: openclaw/openclaw
• Author: linghaoSu
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/59755

Description (problem / solution / changelog)

Summary

• Problem: postJsonRequest() and postTranscriptionRequest() in src/media-understanding/shared.ts never forwarded a pinDns parameter to fetchWithTimeoutGuarded(), so the pinned DNS dispatcher was always used — bypassing configured env proxy (HTTP_PROXY/HTTPS_PROXY/ALL_PROXY).
• Why it matters: Google image generation (and all media understanding requests) fail with "fetch failed" for any user running the gateway behind a proxy, even with NODE_USE_ENV_PROXY=1 set. 100% repro on affected systems.
• What changed: Added pinDns?: boolean to both helper function params and forwarded it in the options object to fetchWithTimeoutGuarded(). Also simplified the options construction to always pass an object (instead of conditionally passing undefined), since fetchWithTimeoutGuarded handles absent fields identically via optional chaining.
• What did NOT change (scope boundary): No callers were updated — this is the structural fix at the shared helper layer. Caller-side changes (passing pinDns: false from Google/Moonshot providers when proxy is active) are a planned follow-up.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #59686
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: postJsonRequest and postTranscriptionRequest were written without a pinDns param. The options object passed to fetchWithTimeoutGuarded only carried ssrfPolicy and dispatcherPolicy, never pinDns. In fetchWithSsrFGuard, pinDns defaults to undefined, which satisfies pinDns !== false, so createPinnedDispatcher is always used — an undici dispatcher that does not respect env proxy settings.
• Missing detection / guardrail: No test covering the proxy-aware fetch path through these helpers.
• Prior context: The pinDns parameter has existed on fetchWithTimeoutGuarded and fetchWithSsrFGuard since the SSRF guard was introduced, but was never wired into the media understanding helpers.
• Why this regressed now: Not a regression — this was always missing. Became visible as more users adopted proxy-based gateway deployments.
• If unknown, what was ruled out: N/A

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/media-understanding/shared.test.ts
• Scenario the test should lock in: When pinDns: false is passed to postJsonRequest, it should appear in the options forwarded to fetchWithTimeoutGuarded.
• Why this is the smallest reliable guardrail: A seam test mocking fetchWithSsrFGuard and asserting the pinDns value in the call args directly validates the forwarding without needing a real proxy.
• If no new test is added, why not: The fix is a minimal param-threading change with no branching logic. The existing type system enforces the param is accepted, and the forwarding is a single property assignment. A dedicated test is warranted but deferred to the caller-side follow-up where the end-to-end proxy path can be tested together.

User-visible / Behavior Changes

None — no callers pass pinDns yet. This is a backwards-compatible API addition. Behavior changes will come in the follow-up when callers opt in.

Diagram (if applicable)

Before:
caller -> postJsonRequest(no pinDns) -> fetchWithTimeoutGuarded(pinDns: undefined)
  -> fetchWithSsrFGuard(pinDns: undefined) -> pinDns !== false -> createPinnedDispatcher (bypasses proxy)

After:
caller -> postJsonRequest(pinDns: false) -> fetchWithTimeoutGuarded(pinDns: false)
  -> fetchWithSsrFGuard(pinDns: false) -> pinDns === false -> no custom dispatcher -> native fetch respects env proxy

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Note: passing pinDns: false disables the pinned DNS dispatcher (an SSRF mitigation), but callers must explicitly opt in. The default (undefined) retains the existing secure behavior. The TRUSTED_ENV_PROXY mode and SSRF hostname resolution still apply when the env proxy path is used.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22+
• Model/provider: Google (gemini-3.1-flash-image-preview)
• Integration/channel (if any): Any channel using image generation
• Relevant config (redacted): HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NODE_USE_ENV_PROXY=1 set in gateway env

Steps

1. Configure proxy env vars on the gateway host
2. Send an image generation request using a Google model
3. Observe fetch failed error

Expected

• Image generation request routes through the configured proxy

Actual

• Request bypasses proxy, uses pinned DNS dispatcher, fails with fetch failed

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

pnpm tsgo — type check passes. pnpm test -- src/media-understanding/shared.test.ts — 5/5 tests pass.

Human Verification (required)

• Verified scenarios: Type check, unit tests, code review of fetchWithTimeoutGuarded and fetchWithSsrFGuard confirming undefined pinDns preserves existing behavior.
• Edge cases checked: Passing {} vs undefined as options to fetchWithTimeoutGuarded — confirmed equivalent via optional chaining on all fields.
• What you did not verify: End-to-end proxy test with a real proxy (requires proxy infrastructure). Caller-side integration (deferred to follow-up).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Callers passing pinDns: false disable DNS pinning SSRF protection for those requests.
  • Mitigation: pinDns is opt-in (default unchanged). The env proxy path (EnvHttpProxyAgent) still runs SSRF hostname resolution. Security posture is unchanged until callers explicitly opt in.

Changed files

• src/media-understanding/shared.ts (modified, +12/-12)

PR #59766: Fix Google image generation behind env proxy

• Repository: openclaw/openclaw
• Author: HiddenPuppy
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/59766

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

If this PR fixes a plugin beta-release blocker, title it fix(<plugin-id>): beta blocker - <summary> and link the matching Beta blocker: <plugin-name> - <summary> issue labeled beta-blocker. Contributors cannot label PRs, so the title is the PR-side signal for maintainers and automation.

• Problem:
• Why it matters:
• What changed:
• What did NOT change (scope boundary):

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

• Root cause:
• Missing detection / guardrail:
• Prior context (git blame, prior PR, issue, or refactor if known):
• Why this regressed now:
• If unknown, what was ruled out:

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should have caught this. Otherwise write N/A.

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file:
• Scenario the test should lock in:
• Why this is the smallest reliable guardrail:
• Existing test that already covers this (if any):
• If no new test is added, why not:

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

Diagram (if applicable)

For UI changes or non-trivial logic flows, include a small ASCII diagram reviewers can scan quickly. Otherwise write N/A.

Before:
[user action] -> [old state]

After:
[user action] -> [new state] -> [result]

Security Impact (required)

• New permissions/capabilities? (Yes/No)
• Secrets/tokens handling changed? (Yes/No)
• New/changed network calls? (Yes/No)
• Command/tool execution surface changed? (Yes/No)
• Data access scope changed? (Yes/No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS:
• Runtime/container:
• Model/provider:
• Integration/channel (if any):
• Relevant config (redacted):

Steps

Expected

Actual

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
• Edge cases checked:
• What you did not verify:

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No)
• Config/env changes? (Yes/No)
• Migration needed? (Yes/No)
• If yes, exact upgrade steps:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

• Risk:
  • Mitigation:

Changed files

• extensions/google/image-generation-provider.proxy.test.ts (added, +152/-0)
• extensions/google/image-generation-provider.ts (modified, +2/-0)
• src/media-understanding/shared.post-json.test.ts (added, +47/-0)
• src/media-understanding/shared.ts (modified, +3/-1)

PR #59873: fix(google): disable pinned dns for image generation

• Repository: openclaw/openclaw
• Author: luoyanglang
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/59873

Description (problem / solution / changelog)

Summary

• add pinDns passthrough support to postJsonRequest
• disable DNS pinning for Google image generation requests so env-proxy setups can be used
• add regression coverage for the shared helper and Google image generation provider

Testing

• pnpm.cmd exec vitest run extensions/google/image-generation-provider.test.ts
• pnpm.cmd exec vitest run src/media-understanding/shared.test.ts
• pnpm.cmd lint extensions/google/image-generation-provider.ts extensions/google/image-generation-provider.test.ts src/media-understanding/shared.ts src/media-understanding/shared.test.ts

Closes #59686.

Changed files

• extensions/google/image-generation-provider.test.ts (modified, +37/-0)
• extensions/google/image-generation-provider.ts (modified, +1/-0)
• src/media-understanding/shared.test.ts (modified, +56/-0)
• src/media-understanding/shared.ts (modified, +6/-2)