Bug type

Regression (worked before, now fails)

Summary

After #38736, openai-codex/gpt-5.4 still times out in some runtime paths. The issue appears to be that OpenClaw still uses a non-Codex transport/base-URL combination for part of the openai-codex flow.

Steps to reproduce

1. Install OpenClaw 2026.3.8 (also observed on 2026.3.7).
2. Authenticate openai-codex via ChatGPT / Codex OAuth.
3. Set openai-codex/gpt-5.4 as the primary model.
4. Run:

openclaw models status --probe --probe-provider openai-codex --probe-timeout 30000 --probe-max-tokens 32 --json

5. Run:

openclaw agent --agent main --message 'Reply exactly with OK.' --json --timeout 120

6. Compare behavior before/after forcing:

• models.providers.openai-codex.baseUrl = "https://chatgpt.com/backend-api/codex"
• SSE transport for openai-codex/gpt-5.4 and openai-codex/gpt-5.3-codex

Expected behavior

• openai-codex/gpt-5.4 should consistently use the Codex-compatible transport path after fix: use codex-responses transport for openai-codex gpt-5.4 fallback #38736.
• Provider probes should succeed.
• Embedded agent runs should complete on openai-codex/gpt-5.4 without timing out or unnecessarily falling back.

Actual behavior

• openai-codex provider probes still time out in some cases.
• Embedded GPT-5.4 runs still stall or time out.
• The same setup recovers immediately when forcing the Codex-specific base URL and SSE transport.
• This suggests at least one remaining runtime path is still using a non-Codex transport/base-URL combination.

OpenClaw version

2026.3.8 (also observed on 2026.3.7)

Operating system

Ubuntu Linux

Install method

npm global install

Logs, screenshots, and evidence

Related existing issue/fix:
- #38706
- #38736

Official Codex upstream references:
- openai/codex uses https://chatgpt.com/backend-api/codex for ChatGPT-authenticated Codex base URL:
  https://github.com/openai/codex/blob/main/codex-rs/core/src/model_provider_info.rs
- official Codex source also references:
  https://chatgpt.com/backend-api/codex/responses
  https://github.com/openai/codex/blob/main/codex-rs/core/src/error.rs

Local workaround that restores normal behavior:

{
  "models": {
    "providers": {
      "openai-codex": {
        "baseUrl": "https://chatgpt.com/backend-api/codex"
      }
    }
  },
  "agents": {
    "defaults": {
      "models": {
        "openai-codex/gpt-5.4": {
          "params": {
            "transport": "sse"
          }
        },
        "openai-codex/gpt-5.3-codex": {
          "params": {
            "transport": "sse"
          }
        }
      }
    }
  }
}


Observed A/B result:
- without /codex in base URL -> reproducible timeout
- with /codex in base URL -> provider probe returns status: ok and GPT-5.4 runs recover

Impact and severity

Affected users: users of openai-codex/gpt-5.4 via ChatGPT / Codex OAuth
Severity: High
Frequency: Reproducible on my setup
Consequence: GPT-5.4 appears configured correctly but runtime behavior remains unstable, causing timeouts, stalls, and misleading fallback/debugging behavior

Additional information

• This does not appear to be only a session-size/compaction issue; I reproduced provider-level failure with direct probes.
• This also does not appear to be only a pure 2026.3.8 regression, since I saw similar behavior on 2026.3.7.
• My best reading is:
  • fix: use codex-responses transport for openai-codex gpt-5.4 fallback #38736 fixed part of the issue
  • but not all runtime paths
  • and at least one remaining path still routes openai-codex traffic through a non-Codex transport/base-URL combination