openclaw - 💡(How to fix) Fix [Bug]: openai-completions to api.openai.com bypasses env-proxy dispatcher in HTTPS_PROXY-only sandbox; xAI / Anthropic / Discord on the same gateway PID work fine (2026.4.26) [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In a sandbox where the only route to the public internet is an HTTPS forward proxy (HTTPS_PROXY=http://<proxy>:3128), gateway requests to api.openai.com via openai-completions fail every turn with LLM request failed: network connection error. rawError=Connection error., while requests to api.x.ai, api.anthropic.com, api.telegram.org, and discord.com issued by the same gateway PID using the same code path succeed and appear in the egress proxy log normally.

This is a follow-up to #56841 which @steipete closed on 2026-04-27 as "fixed/currently not reproducible on main." After upgrading to 2026.4.26 and reproducing the failure, I'm filing this as a fresh issue because the maintainer's verification used localhost-Ollama / direct-net access, which does not exercise the HTTPS_PROXY-only code path. A DGX Spark / Ubuntu 24.04 reproducer in #56841 comment by @longavailable matches my environment.

The fix from #42311 (configureEmbeddedAttemptHttpRuntime → ensureGlobalUndiciEnvProxyDispatcher) is present and does run in 2026.4.26 (gateway log emits the [UNDICI-EHPA] Warning: EnvHttpProxyAgent is experimental line at startup), but OpenAI requests still don't traverse the env-proxy dispatcher.

Steps to reproduce

1. Install OpenClaw 2026.4.26 in an environment with no direct egress — outbound 443 must go through HTTPS_PROXY=http://<proxy>:3128. External DNS for public hosts does not resolve directly; CONNECT-via-proxy is the only path out.
2. Configure two providers identically against api: openai-completions:
   • xai: baseUrl: https://api.x.ai/v1, valid xAI key, model grok-4.20-reasoning
   • openai: baseUrl: https://api.openai.com/v1, valid platform OpenAI key, model gpt-5.5
3. Confirm the gateway's process inherits HTTPS_PROXY, HTTP_PROXY, ALL_PROXY, NODE_USE_ENV_PROXY=1 from the parent shell.
4. Send a minimal turn against the xAI-routed agent: openclaw agent -m 'Reply OK' --agent X --json --timeout 60. Succeeds (winnerProvider: xai).
5. Repoint the agent's model to openai/gpt-5.5 (hot-reload via agents.list). Send the same minimal turn. Fails every retry with LLM request failed: network connection error. rawError=Connection error., then silent fallback to the configured fallback model.
6. Inspect the egress proxy access log during step 5: there is no entry for dst_host=api.openai.com. The xAI / Discord / Telegram entries from the same gateway PID are visible.

Expected behavior

Either:

• openai-completions requests to api.openai.com route through the global env-proxy dispatcher (same as xAI/Anthropic/Discord/Telegram on the same PID), and a successful turn returns; or
• A clear error states which step in the OpenAI-specific code path is bypassing the configured proxy dispatcher (e.g. "OpenAI SDK uses internal http.Agent that ignores globalThis undici dispatcher").

Actual behavior

[agent/embedded] embedded run agent end: ... isError=true model=gpt-5.5 provider=openai error=LLM request failed: network connection error. rawError=Connection error.
[agent/embedded] embedded run failover decision: ... stage=assistant decision=surface_error reason=timeout from=openai/gpt-5.5 profile=- rawError=Connection error.
[model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai/gpt-5.5 candidate=openai/gpt-5.5 reason=timeout

Evidence

1. The env-proxy dispatcher IS installed at gateway startup. Gateway log shows the bootstrap warning, twice (one per node process):

(node:NNNN) [UNDICI-EHPA] Warning: EnvHttpProxyAgent is experimental, expect them to change at any time.
(node:NNNN) [UNDICI-EHPA] Warning: EnvHttpProxyAgent is experimental, expect them to change at any time.
[gateway] loading configuration…
...
[gateway] ready (8 plugins: ...)

This proves setGlobalDispatcher(new EnvHttpProxyAgent()) from src/infra/net/undici-global-dispatcher.ts ran in the gateway process — the fix from #42311 (configureEmbeddedAttemptHttpRuntime) IS active.

2. xAI and other providers route through the egress proxy correctly. From the egress proxy access log for the same gateway PID:

The proxy-log absence IS the diagnostic — the gateway's OpenAI requests don't fail at the proxy edge, they never get there at all.

3. Standalone Node test against the same endpoint succeeds. From the same shell, with the same HTTPS_PROXY env, using the bundled OpenClaw node_modules/openai SDK v6.34.0:

import { setGlobalDispatcher, EnvHttpProxyAgent } from "undici";
import OpenAI from "openai";
setGlobalDispatcher(new EnvHttpProxyAgent());
const c = new OpenAI({ apiKey: process.env.OPENAI_KEY, baseURL: "https://api.openai.com/v1" });
const s = await c.chat.completions.create({
  model: "gpt-5.5", stream: true, store: false, max_completion_tokens: 32,
  prompt_cache_key: "x", stream_options: { include_usage: true },
  messages: [{ role: "user", content: "Reply OK" }]
});
for await (const chunk of s) console.log(chunk.choices?.[0]?.delta?.content);
// → 200 OK, "OK" streamed
// proxy log shows: dst_host=api.openai.com action=allow

So the dispatcher, SDK, key, baseUrl, request shape, and proxy ALL work in isolation. Only the gateway's OpenAI calls bypass the proxy.

4. xAI works because it doesn't actually exercise the openai-completions adapter. extensions/xai/api.ts rewrites api: "openai-completions" → "openai-responses" for any model whose baseUrl is api.x.ai (via shouldUseXaiResponsesTransport). So xAI working through openai-completions configs is misleading — at runtime it's routed through openai-responses. The bare openai-completions code path against api.openai.com is not actually proven to work in any of the test setups maintainers have used to verify #56841.

5. 18 separate copies of undici in the OpenClaw dep tree. Each provider extension and pi-ai itself has its own node_modules/undici. setGlobalDispatcher mutates module-local state; if the OpenAI SDK's fetch path resolves to a different undici copy than the one openclaw bootstraps, the env-proxy dispatcher isn't visible there. (This is a hypothesis for why xAI/Anthropic/Discord work and OpenAI doesn't — different copies, different effective globals.)

$ find /path/to/node_modules/openclaw -type d -name undici | wc -l
18

OpenClaw version

2026.4.26 (also reproduces on 2026.4.23 and 2026.4.22)

Operating system

Ubuntu 24.04 in a user-namespace sandbox

Install method

npm global

Model

openai/gpt-5.5 (also reproduces with openai/gpt-4o-mini)

Provider / routing chain

agent → openai/gpt-5.5
provider openai: api=openai-completions, baseUrl=https://api.openai.com/v1, apiKey=<platform-key>
sandbox network namespace: no direct egress; HTTPS_PROXY=http://<proxy>:3128 (CONNECT) is the only path out

Same machine, same gateway, same env: xai/grok-4.20-reasoning with api: openai-completions, baseUrl: https://api.x.ai/v1 ✅ works fine.

Additional setup details

Provider config (sanitized):

"openai": {
  "baseUrl": "https://api.openai.com/v1",
  "api": "openai-completions",
  "apiKey": "<platform-key>",
  "models": [{
    "id": "gpt-5.5",
    "name": "openai/gpt-5.5",
    "reasoning": true,
    "input": ["text"],
    "contextWindow": 256000,
    "maxTokens": 32000,
    "cost": { "input": 1.25, "output": 10.0, "cacheRead": 0.125, "cacheWrite": 1.25 }
  }]
}

Gateway env (verified inherited from parent shell):

HTTPS_PROXY=http://<proxy>:3128
HTTP_PROXY=http://<proxy>:3128
ALL_PROXY=http://<proxy>:3128
NO_PROXY=localhost,127.0.0.1,::1,<proxy-host>
NODE_USE_ENV_PROXY=1

Logs

[agent/embedded] embedded run agent end: runId=<id> isError=true model=gpt-5.5 provider=openai error=LLM request failed: network connection error. rawError=Connection error.
[agent/embedded] embedded run agent end: ... (retry 2)
[agent/embedded] embedded run agent end: ... (retry 3)
[agent/embedded] embedded run agent end: ... (retry 4)
[agent/embedded] embedded run failover decision: ... stage=assistant decision=surface_error reason=timeout from=openai/gpt-5.5 profile=- rawError=Connection error.
[model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai/gpt-5.5 candidate=openai/gpt-5.5 reason=timeout

Retry intervals: 2.4s → 5.4s → 5.4s → 9.3s. Each retry returns ~immediately, consistent with sandbox-level connection-refused — confirming requests are NOT going through the configured proxy (a real proxy attempt would either succeed or stall on CONNECT, not fail-fast).

Suggested investigation direction

• Audit the openai-completions adapter (@mariozechner/pi-ai/dist/providers/openai-completions.js). Its createClient builds new OpenAI({ apiKey, baseURL }) with no custom fetch. Does the OpenAI SDK's internal fetch path use globalThis.fetch (which would honor the env-proxy dispatcher) or its own node-fetch / http.Agent shim?
• Check whether the OpenAI extension's bundled node_modules/undici is loaded by the request path, and if so whether setGlobalDispatcher from openclaw's bootstrap undici copy crosses module boundaries on Node 22 / 24.
• Add a per-request log showing which dispatcher kind (env-proxy vs Agent vs custom) is active at the moment openai-completions.streamOpenAICompletions issues its fetch, so users in proxy environments can confirm proxy routing.
• Consider documenting that #56841's fix only covers direct-egress environments, and that proxy-required environments still fail until this is resolved.

Impact and severity

Severity: medium-high for any user running OpenClaw in a corporate-proxy / sandboxed / forward-proxy-only environment with OpenAI as the configured provider. Failure is silent (model fallback eats it; the user sees "OpenAI is slow / unreliable today") rather than an actionable error.

Frequency: 100% reproducible.

Additional information

Happy to share more diagnostics if helpful. The decisive evidence is the proxy log: same gateway PID, four upstream destinations succeed, only api.openai.com is invisible to the proxy. That's enough to localize the bug to the OpenAI-specific dispatch path inside the embedded runner.