Bug type

Regression (worked before, now fails)

Summary

On OpenClaw 2026.4.25, agent runs targeting openai-codex/gpt-5.5 hang indefinitely on first turn. The model never streams a token, no error is logged, and the only way to recover is an external abort (stop button / external timeout). The trajectory artifact shows assistantTexts: [] and itemLifecycle.startedCount: 0 — the run never actually starts producing output.

The legacy openai-codex/gpt-5.4 path on the same OAuth profile, same host, same gateway works fine. Direct codex exec --model gpt-5.5 on the same OAuth profile also works fine (~4s round-trip). Direct POST /v1/responses against gpt-5.5 with API-key auth also works (~1.9s, returns gpt-5.5-2026-04-23).

So upstream is healthy and OAuth is healthy. The hang is inside the OpenClaw openai-codex-responses adapter for gpt-5.5 specifically.

Environment

• OpenClaw: 2026.4.25 (aa36ee6) — installed via npm global
• Host: macOS 25.4.0 / arm64 (Apple Silicon M1)
• Node: v25.9.0
• codex CLI: v0.118.0
• Provider: openai-codex (legacy OAuth path, not the new bundled codex/* harness)
• Auth: ChatGPT/Codex OAuth (Plus subscription)
• Channel: webchat (also reproduced via openclaw agent --agent main --message ...)

Config (relevant excerpt)

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai-codex/gpt-5.5",
        "fallbacks": []
      },
      "models": {
        "openai-codex/gpt-5.4": {},
        "openai-codex/gpt-5.5": {}
      },
      "timeoutSeconds": 300,
      "thinkingDefault": "medium"
    }
  },
  "auth": {
    "profiles": {
      "openai-codex:<redacted>": {
        "provider": "openai-codex",
        "mode": "oauth"
      }
    }
  }
}

Steps to reproduce

1. On OpenClaw 2026.4.25, with an OAuth-backed openai-codex profile that works for gpt-5.4, set agents.defaults.model.primary to openai-codex/gpt-5.5.
2. Hot-reload picks up the change ([reload] config hot reload applied).
3. Send any prompt via webchat or openclaw agent.
4. Run hangs. No tokens stream. No errors in gateway.log / gateway.err.log other than the eventual external-abort surfaced ~5 min later by the embedded run timeout (timeoutSeconds: 300).

Expected behavior

gpt-5.5 should respond on the same OAuth profile that works in the codex CLI. Or, if some adapter-level incompatibility exists, it should surface a clear error rather than silently hang.

Actual behavior — trajectory artifact

From ~/.openclaw/agents/main/sessions/<runId>.trajectory.jsonl:

{
  "type": "model.completed",
  "provider": "openai-codex",
  "modelId": "gpt-5.5",
  "modelApi": "openai-codex-responses",
  "data": {
    "aborted": true,
    "externalAbort": true,
    "timedOut": true,
    "idleTimedOut": false,
    "compactionCount": 0,
    "promptError": "This operation was aborted | This operation was aborted",
    "promptErrorSource": "prompt",
    "assistantTexts": [],
    "messagesSnapshot": []
  }
}

Followed by:

{
  "type": "trace.artifacts",
  "data": {
    "finalStatus": "error",
    "aborted": true,
    "externalAbort": true,
    "timedOut": true,
    "itemLifecycle": {
      "startedCount": 0,
      "completedCount": 0,
      "activeCount": 0
    },
    "toolMetas": [],
    "didSendViaMessagingTool": false
  }
}

startedCount: 0 is the key signal — the run never even started producing items.

Gateway log evidence

After the gateway restart at 09:18 PDT today:

2026-04-27T09:18:11 [gateway] agent model: openai-codex/gpt-5.5
...
2026-04-27T10:16:38 [agent/embedded] embedded run failover decision:
  runId=7a85c138-... stage=assistant decision=surface_error
  reason=timeout from=openai-codex/gpt-5.5 profile=sha256:2ed3747bab55

Zero auth errors in this window: grep -iE "401|403|oauth|expired|refresh" returns nothing for the openai-codex provider.

A/B isolation evidence

Three orthogonal probes, same machine, same OAuth profile where applicable:

This isolates the failure to OpenClaw 2026.4.25's openai-codex-responses adapter, specifically when the model is gpt-5.5. Same adapter on gpt-5.4 works fine.

Related issues

• [Bug]: codex/gpt-5.4 via bundled Codex harness hangs indefinitely on initialize in v2026.4.10 (macOS, codex-cli 0.118.0 and 0.120.0) #64744 — same mechanical pattern (silent hang on init, no timeout protection on CodexAppServerClient.initialize()), but reporter saw it on the new bundled codex/* path while the legacy openai-codex/* path was still working at 2026.4.10. This report describes the same failure mode now affecting the legacy path for gpt-5.5 specifically as of 2026.4.25.
• Add support for GPT-5.5 in openai-codex provider (released 2026-04-23) #70834 / Add gpt-5.5 catalog support (OpenAI in-house model, released 2026-04-23) #70854 — gpt-5.5 catalog support added to the openai-codex provider. Catalog now resolves (no "Unknown model" error), but request execution silently hangs. Likely the routing patch landed without proper request-path coverage for gpt-5.5.
• [Bug]: openai-codex gpt-5.1/5.2/5.3 rejected on ChatGPT/Codex OAuth, only gpt-5.4 works #67158 — different OAuth-rejection symptom for older 5.x variants; this report is distinct (no auth error, model is 5.5 not 5.1-5.3).
• openai-codex provider broken since 2026.4.5 — Cloudflare challenge + missing OAuth scope #68033 — Cloudflare-challenge symptom on openai-codex; not reproduced here (no HTML in response, no Cloudflare 403 in logs).

Workaround

Setting agents.defaults.model.primary = openai-codex/gpt-5.4 fully restores agent function. No re-auth needed.

Suggested fix direction

Per #64744's analysis, CodexAppServerClient.initialize() and related request-path entry points lack timeoutMs protection. Even if the underlying gpt-5.5 routing bug has its own root cause, adding the timeout would at minimum surface a real error instead of a silent infinite hang.