Bug: dist/entry.js main-path breaks Codex OAuth image generation on Linux, while direct runCli() / provider path succeeds

Summary

On 192.168.1.159 (Ubuntu 24.04, Node v22.22.2, OpenClaw 2026.4.24), openclaw infer image generate --model openai/gpt-image-2 ... fails with TypeError: fetch failed, but the same machine succeeds when bypassing the dist/entry.js main-entry path and calling either:

• runCli(argv) directly from dist/run-main-*.js
• the OpenAI image provider directly from dist/image-generation-provider-*.js
• guarded postJsonRequest(...) directly from dist/shared-*.js
• raw fetch() directly to https://chatgpt.com/backend-api/codex/responses

This strongly suggests the regression is in the entry/main bootstrap path, not in Codex OAuth itself, not in the OpenAI image provider implementation, and not in the underlying Codex Responses backend.

Environment

• Host: Ubuntu 24.04 (192.168.1.159 / dck01)
• OpenClaw: 2026.4.24 (cbcfdf6)
• Node: v22.22.2
• Install path: /home/jackalchiu/.hermes/node/lib/node_modules/openclaw
• CLI: /home/jackalchiu/.local/bin/openclaw
• Auth: openai-codex OAuth profile (openai-codex:[email protected])
• No OPENAI_API_KEY

Control machine:

• macOS 149 host
• OpenClaw 2026.4.23
• same user account family
• same Codex OAuth image flow works there with openclaw infer image generate

Primary failing repro

env -u OPENAI_API_KEY openclaw infer image generate \
  --model openai/gpt-image-2 \
  --prompt "a red lobster robot in flat illustration style" \
  --size 1024x1024 \
  --output ~/Backup/openclaw-image-test/repro-159.png \
  --json

Observed output:

[image-generation/openai] image auth selected: provider=openai-codex mode=oauth transport=codex-responses requestedModel=gpt-image-2 responsesModel=gpt-5.4 timeoutMs=180000
[image-generation] candidate failed: openai/gpt-image-2: fetch failed
TypeError: fetch failed

Other observed variants after process-level network flags:

fetch failed | Client network socket disconnected before secure TLS connection was established

and

fetch failed | other side closed

Evidence that lower layers are healthy on the same host

1. Raw HTTPS fetch to Codex Responses succeeds

Using the saved openai-codex OAuth access token from:

• ~/.openclaw/agents/main/agent/auth-profiles.json

A direct fetch() POST to:

• https://chatgpt.com/backend-api/codex/responses

returns:

• HTTP 200
• SSE body begins with event: response.created

So:

• auth token is valid
• backend is reachable
• basic HTTPS path works

2. Guarded provider HTTP helper succeeds

Direct import and call of:

• postJsonRequest(...) from dist/shared-C_SB36H2.js

returns an object with keys:

• response
• finalUrl
• release

and response.status === 200.

3. OpenAI image provider succeeds directly

Direct import and call of:

• dist/image-generation-provider-DCtzDaXb.js
• provider.generateImage(req)

succeeds on the same host with the same openai/gpt-image-2 request.

Result contains:

• images.length === 1
• mimeType: image/png
• normal usage metadata

4. Direct runCli(argv) succeeds

A Node script importing:

• dist/run-main-bbWXFk-0.js
• runCli(argv)

with argv equivalent to the failing CLI command succeeds and writes a valid PNG.

This is the most important datapoint.

Critical differential diagnosis

These succeed on 159:

1. raw fetch() to Codex Responses
2. guarded postJsonRequest(...)
3. direct provider generateImage(...)
4. direct runCli(argv) import from run-main-*.js

These fail on 159:

1. openclaw infer image generate ...
2. node ~/.hermes/node/lib/node_modules/openclaw/openclaw.mjs infer image generate ...
3. node ~/.hermes/node/lib/node_modules/openclaw/dist/entry.js infer image generate ...

Therefore the failure boundary is not provider/runtime/backend. It is the entry/main invocation path.

Strong narrowing: dist/entry.js main-path side effects

Directly executing dist/entry.js as the main module reproduces the failure.

But importing dist/entry.js as a module (non-main) and then calling runCli(argv) still succeeds.

That means the bug is specifically in the main-module branch of dist/entry.js, not merely in its import graph.

Relevant structure observed in dist/entry.js:

• main branch calls:
  • ensureOpenClawExecMarkerOnProcess()
  • installProcessWarningFilter()
  • normalizeEnv()
  • respawn policy / argv normalization
  • then runMainOrRootHelp(...)

Reproduction matrix

On the same host:

• runCli(argv) directly → success
• enableCompileCache(); runCli(argv) → success
• ensureOpenClawExecMarkerOnProcess(); runCli(argv) → success
• installProcessWarningFilter(); runCli(argv) → success
• normalizeEnv(); runCli(argv) → success
• pairwise combinations of those → success
• but a script that mimics the entry.js main prelude before calling runCli(...) → failure

One failing mimic was:

• ensureOpenClawExecMarkerOnProcess()
• installProcessWarningFilter()
• normalizeEnv()
• argv normalization / profile parsing
• then runCli(process.argv)

This produced the same image-generation failure.

So the bug appears to require a specific combination of entry/main-path setup steps, not any single helper in isolation.

Network context

This host resolves chatgpt.com to both IPv4 and IPv6.

Observed:

• IPv4 A records exist
• IPv6 AAAA records exist
• direct IPv6 TCP connect to returned AAAA addresses fails with ENETUNREACH

This may be relevant, but it is not sufficient by itself to explain the bug because:

• raw fetch() still succeeds
• guarded postJsonRequest(...) still succeeds
• direct provider and direct runCli() still succeed

So even if IPv6 contributes, the immediate bug still appears to be entry/main-path-specific behavior.

Expected behavior

All of the following invocation styles should behave the same:

• openclaw infer image generate ...
• node openclaw.mjs infer image generate ...
• programmatic runCli(argv)

If the provider/backend/auth path is healthy, the CLI entry path should not introduce a fetch failure.

Actual behavior

Only the main entry invocation path fails. Lower-level and programmatic paths succeed on the same host.

Why this matters

This breaks operator trust because:

• the advertised CLI command fails
• the same codebase works when invoked programmatically
• the same host can reach the backend and produce the image when bypassing entry/main bootstrap

It also makes debugging misleading because it looks like a provider/backend/auth issue, but the real failure is much higher in the startup chain.

Suggested investigation areas

1. Compare dist/entry.js main-module path vs direct runCli(argv) path.
2. Look for process-wide side effects in the entry prelude that can affect fetch/network behavior.
3. Focus on interactions among:
   • ensureOpenClawExecMarkerOnProcess()
   • installProcessWarningFilter()
   • normalizeEnv()
   • argv/profile/container normalization
4. Verify whether entry-path startup changes any process-global fetch/dispatcher/network state before provider execution.
5. Check whether the combination of those steps changes behavior only on hosts with IPv6-unreachable / IPv4-working DNS results.

Local evidence files

Successful outputs written on 159 by non-entry paths:

• ~/Backup/openclaw-image-test/plain-runcli-159.png
• ~/Backup/openclaw-image-test/entry-import-sideeffect-159.png
• ~/Backup/openclaw-image-test/compilecache-effect-159.png
• ~/Backup/openclaw-image-test/exec-marker-effect-159.png
• ~/Backup/openclaw-image-test/warning-filter-effect-159.png
• ~/Backup/openclaw-image-test/normalize-prelude-effect-159.png

Failing entry-path commands produced no output PNG:

• ~/Backup/openclaw-image-test/entrypoint-retest-159.png
• ~/Backup/openclaw-image-test/entry-js-no-respawn-159.png

Bottom line

This looks like an OpenClaw CLI entry bootstrap bug, not a Codex OAuth / provider / backend bug.