Summary

• Problem: ensureGlobalUndiciStreamTimeouts() kept a plain undici Agent even when HTTP_PROXY / HTTPS_PROXY were configured.
• Why it matters: embedded runner requests such as openai-codex/gpt-5.4 could still try direct connections and time out behind HTTP proxies.
• What changed: when HTTP_PROXY / HTTPS_PROXY are present, the dispatcher now upgrades Agent -> EnvHttpProxyAgent, and it re-applies the extended timeouts if another subsystem replaces that global dispatcher. Tests cover the upgrade path, the re-apply path, and the ALL_PROXY-only non-upgrade path.
• What did NOT change (scope boundary): this PR does not add ALL_PROXY support and does not change Telegram-specific proxy selection logic.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• 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

• Related [Bug]: Feishu DM is received and dispatched, but embedded agent times out with LLM request timed out #41046

User-visible / Behavior Changes

• Before: embedded runner requests could still time out with LLM request timed out even when HTTP_PROXY / HTTPS_PROXY were set.
• After: embedded runner requests use EnvHttpProxyAgent when HTTP_PROXY / HTTPS_PROXY are set.
• After: if another subsystem replaces the global env-proxy dispatcher, embedded runner setup restores the extended stream timeouts on the next run.
• Out of scope: ALL_PROXY-only setups are unchanged.

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)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS 14.x
• Runtime/container: Node.js v24.14.0
• Model/provider: openai-codex/gpt-5.4
• Integration/channel (if any): Gateway-backed agent CLI
• Relevant config (redacted):

  {
    "agents": {
      "defaults": {
        "model": {
          "primary": "openai-codex/gpt-5.4"
        }
      }
    }
  }

Steps

1. Set agents.defaults.model.primary to openai-codex/gpt-5.4.
2. Run OpenClaw with working HTTP_PROXY / HTTPS_PROXY values.
3. Run:

   openclaw agent --session-id proxy-check-gpt54-gateway --message "Reply with only OK." --json --timeout 120

Expected

• Embedded runner traffic uses the configured HTTP proxy.
• The openai-codex/gpt-5.4 turn completes successfully.

Actual

• Before fix: embedded run agent end: ... error=LLM request timed out.
• After fix: the gateway-backed agent turn completes with status: ok and reply OK.

Evidence

Attach at least one:

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

Log Before Fix

warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=... isError=true error=LLM request timed out.

Log / Command After Fix

$ openclaw agent --session-id proxy-check-gpt54-gateway --message "Reply with only OK." --json --timeout 120
{
  "status": "ok",
  "result": {
    "payloads": [
      {
        "text": "OK"
      }
    ]
  }
}

Unit Tests

$ pnpm exec vitest run src/infra/net/undici-global-dispatcher.test.ts
✓ src/infra/net/undici-global-dispatcher.test.ts (8 tests)

Human Verification (required)

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

• Verified scenarios:
  • HTTP_PROXY / HTTPS_PROXY configured on macOS
  • gateway-backed openai-codex/gpt-5.4 turn succeeds
  • unit tests for dispatcher upgrade behavior pass
• Edge cases checked:
  • existing EnvHttpProxyAgent remains on env-proxy path
  • an externally replaced EnvHttpProxyAgent is re-applied with extended timeouts
  • ALL_PROXY-only setup does not upgrade in this PR
  • custom ProxyAgent remains untouched
• What you did not verify:
  • ALL_PROXY support
  • Windows
  • Docker / containerized installs
  • non-OpenAI embedded providers

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)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this commit
• Files/config to restore:
  • src/infra/net/proxy-env.ts
  • src/infra/net/undici-global-dispatcher.ts
  • src/infra/net/undici-global-dispatcher.test.ts
• Known bad symptoms reviewers should watch for:
  • HTTP_PROXY / HTTPS_PROXY configured but embedded runner traffic still behaves like direct-connect
  • unexpected dispatcher changes when a custom proxy dispatcher is already installed

Risks and Mitigations

• Risk: readers may assume this also fixes ALL_PROXY-only environments.
  • Mitigation: scope is explicitly limited in code, tests, and this PR description to HTTP_PROXY / HTTPS_PROXY.
• Risk: changing the default dispatcher path could affect embedded runner networking behavior.
  • Mitigation: the change only applies when a plain Agent is active and HTTP_PROXY / HTTPS_PROXY are already configured; custom proxy dispatchers remain untouched, and tests cover re-application after an external dispatcher swap.