openclaw - 💡(How to fix) Fix openai-completions chat requests bypass HTTPS_PROXY in proxy-required sandbox (regression of closed #56841) [1 comments, 2 participants]

Environment

• OpenClaw 2026.4.26 (also reproduced on 2026.4.23)
• Pi 0.70
• Node v22.22.1
• Bundled openai SDK v6.35.0
• DGX Spark (GB10) running NVIDIA openshell community image, sandbox connectivity gated by HTTPS_PROXY=http://127.0.0.1:3128 → 10.200.0.1:3128 → openshell egress proxy
• All non-loopback HTTPS egress is policy-gated. Sandbox policy v2 (per-sandbox) explicitly allows api.openai.com:443 for node + openclaw binaries.

Symptom

When openclaw is configured with an openai-completions provider whose baseUrl: https://api.openai.com/v1, gateway calls produce:

LLM request failed: network connection error. rawError=Connection error.

…followed by silent fallback to the agent's model.primary. No retry, no proxy log entry. Same gateway PID's xAI / Anthropic / Telegram / Discord requests succeed and ARE visible in the proxy log.

Smoking gun (proxy log)

Same gateway PID, three providers in flight in the same minute:

dst_host=api.x.ai          → action=allow policy=xai          ✓
dst_host=api.telegram.org  → action=allow policy=telegram     ✓
dst_host=discord.com       → action=allow policy=discord      ✓
dst_host=api.openai.com    → no entry                         ✗

OpenAI requests never reach the proxy — they die at the network namespace level (where direct egress is denied) and resurface as the SDK retry-layer error.

What I've already ruled out

1. API key invalid — direct node -e "fetch('https://api.openai.com/v1/embeddings', ...)" from inside the sandbox returns 200 using the same key.
2. Sandbox policy denies api.openai.com — proxy log shows action=allow policy=openai_codex for direct fetch tests.
3. Bundled SDK doesn't honor HTTPS_PROXY — direct import OpenAI from 'openai'; setGlobalDispatcher(new EnvHttpProxyAgent()); from node -e works fine, returns clean streaming 200, with same prompt_cache_key / stream / stream_options / store:false / max_completion_tokens params pi-ai sends.
4. Gateway env vars not propagating — gateway log shows [UNDICI-EHPA] Warning: EnvHttpProxyAgent is experimental at startup, proving setGlobalDispatcher(new EnvHttpProxyAgent()) IS being called per the fix in #42311 (configureEmbeddedAttemptHttpRuntime() in pi-embedded-runner/run/attempt-http-runtime.ts).
5. Provider config schema — name, reasoning, input fields all present. Gateway accepts the provider entry without validator errors.
6. xAI works through the same openai-completions adapter — but at runtime, openclaw silently rewrites api: openai-completions → api: openai-responses for any baseUrl.includes("api.x.ai") (see extensions/xai/api.ts's shouldUseXaiResponsesTransport). xAI does NOT exercise the actual openai-completions code path.
7. Embeddings work — /v1/embeddings against the same models.providers.openai block goes through fine. Memory-core dreaming embedder (text-embedding-3-small, 1536-dim, sqlite-vec) round-trips successfully via the gateway. Bug is scoped to /v1/chat/completions, not OpenAI as a whole.

Where I think the bug is (untraced)

pi-ai's streamOpenAICompletions constructs new OpenAI({apiKey, baseURL: "https://api.openai.com/v1"}) with no custom fetch handler — should use Node's globalThis.fetch → undici → global dispatcher (which IS configured). So one of:

1. Special-case fetch override triggered by model.baseUrl.includes("api.openai.com") (mirroring the shouldUseXaiResponsesTransport pattern but in the opposite direction).
2. Worker thread / forked subprocess for chat-completions inference that doesn't inherit the parent's undici global dispatcher — embeddings might run in-process while chat-completions runs out-of-process.
3. Multiple undici copies in the dependency tree — openclaw/node_modules/undici vs openai/node_modules/undici — setGlobalDispatcher only affects one.
4. Build-time bake — internal http config that targets the literal api.openai.com host differently from other base URLs.

The proxy-log absence pattern is the diagnostic — without it I'd never have figured out it's a routing bypass and not a denial.

Why #56841's closing claim is incomplete

#56841 was closed as "fixed/currently not reproducible on main" — but the maintainer's verification used localhost 127.0.0.1:11434 Ollama as the OpenAI-compatible target. That doesn't exercise the proxy code path, since localhost connections aren't proxy-eligible. The proxy-required case (which is ours, and longavailable's in #56841 comment 4) was not re-tested in the closing verification.

Reproduction steps

1. Sandbox where direct egress is denied; HTTPS only via configured HTTPS_PROXY.
2. Configure provider:

   {
     "models": { "providers": { "openai": {
       "baseUrl": "https://api.openai.com/v1",
       "api": "openai-completions",
       "apiKey": "sk-proj-...",
       "models": [{
         "id": "gpt-5.5",
         "name": "openai/gpt-5.5",
         "contextWindow": 400000,
         "maxTokens": 8000,
         "reasoning": true,
         "input": ["text"],
         "cost": { "input": 5, "output": 15 }
       }]
     } } }
   }

3. Wire an agent's model.primary: openai/gpt-5.5.
4. Send a single inference: openclaw agent --agent <id> -m 'hi' --json.
5. Observe error=LLM request failed: network connection error. rawError=Connection error. in gateway log. Observe dst_host=api.openai.com is absent from the openshell egress proxy log for the gateway PID, while same-PID xAI/Anthropic requests are present.

Workarounds tried

Untried (proposed):

• Reverse-proxy api.openai.com/v1/chat/completions via a custom passthrough host (https://my-passthrough.example.com/openai/) to dodge any host-literal special-casing.
• Run gateway HOST-side instead of in-sandbox.

Related issues

• #42311 (closed 2026-04-24): NODE_USE_ENV_PROXY required for openai-codex; fix at configureEmbeddedAttemptHttpRuntime(). Present in our install.
• #56841 (closed 2026-04-27): exact symptom match; closed-fix verification used localhost Ollama, not real proxy.
• #46306 (closed 2026-03-31): same shape for web_search / web_fetch behind proxy.