openclaw - 💡(How to fix) Fix [Bug]: TUI/Web turns remain In progress with Runtime: OpenAI Codex on 2026.5.22 after successful OAuth

Bug type

Regression / runtime hang

Summary

After upgrading/using OpenClaw 2026.5.22 (a374c3a), both TUI and Web Control can connect to the local gateway and /status reports a healthy openai-codex OAuth profile, but normal user messages remain stuck in running / In progress and do not reliably produce an assistant reply.

This appears tied to the Runtime: OpenAI Codex path. Authentication and model discovery look healthy (Auth yes), but actual agent turns hang, time out, or return to idle without a reliable assistant message.

Environment

• OpenClaw version: 2026.5.22 (a374c3a)
• OS / hardware: macOS on Intel MacBook Pro. This is an Intel-based Mac, not Apple Silicon.
• Gateway target: ws://127.0.0.1:18789
• Agent/session: agent main; new TUI sessions are also affected
• Auth: openai-codex OAuth via openclaw models auth login --provider openai-codex --set-default
• Runtime shown in /status: Runtime: OpenAI Codex
• Install method: local macOS install; exact package manager not yet confirmed

Symptoms

1. TUI starts and connects successfully:

connected | idle
agent main | session ... | openai/gpt-5.5 | tokens ?/200k

1. /status returns normally and shows OAuth + OpenAI Codex runtime:

Model: openai/gpt-5.5 · oauth (openai-codex:<redacted>)
Execution: direct · Runtime: OpenAI Codex · Think: medium · Text: low
Queue: steer (depth 0)

1. Sending a trivial message such as halo, 在吗, or 只回复 OK often leaves the turn stuck:

running · connected
agent main | session main | openai/gpt-5.5 | think medium

or shows:

This response is taking longer than expected. Send another message to continue.

Sometimes the session returns to idle, but the assistant message is missing or not reliably shown.

1. Web Control shows the same behavior: Run status stays In progress.

Commands and observations

OAuth login completes successfully:

openclaw models auth login --provider openai-codex --set-default

Output includes:

OpenAI OAuth complete
Auth profile: openai-codex:<redacted> (openai-codex/oauth)
Default model set to openai/gpt-5.5

openclaw models shows usable runtime auth:

Default       : openai/gpt-5.5
Runtime auth
- openai via codex uses openai-codex ... status=usable
OAuth/token status
- openai-codex usage: ... ok

openclaw models list shows all relevant models as authenticated:

Model                                      Input      Ctx         Local Auth  Tags
openai/gpt-5.5                             text       195k        no    yes   default,configured
openai/gpt-5.5-pro                         text       195k        no    yes   configured
openai/gpt-5.4                             text       195k        no    yes   configured,alias:gpt
codex/gpt-5.5                              text       195k        no    yes   configured
codex/gpt-5.2                              text+image 266k        no    yes
codex/gpt-5.3-codex                        text+image 266k        no    yes
codex/gpt-5.4                              text+image 266k        no    yes
codex/gpt-5.4-mini                         text+image 266k        no    yes

openclaw models status --agent main --probe has also previously shown Codex app-server timeout-like messages, for example:

[agents/harness] Codex agent harness failed; not falling back to embedded PI backend
codex app-server startup timed out

and/or:

codex app-server turn idle timed out waiting for progress
codex app-server client retired after timed-out turn

Reproduction steps

1. Start with OpenClaw 2026.5.22 (a374c3a) on macOS Intel MacBook Pro.
2. Authenticate with:

   openclaw models auth login --provider openai-codex --set-default

3. Confirm auth/model status:

   openclaw models
   openclaw models list

4. Restart gateway:

   openclaw gateway restart

5. Start TUI:

   openclaw tui

6. Run:

   /status

   Confirm it shows Runtime: OpenAI Codex.
7. Send a trivial prompt, e.g.:

   halo

8. Observe the turn staying running / In progress, or returning to idle without a reliable assistant response.

Expected behavior

A trivial message such as halo or 只回复 OK should complete quickly and display the assistant response in TUI/Web Control.

Actual behavior

The turn remains in progress or does not reliably emit the assistant reply, despite OAuth/model status being healthy.

What has been tried

• Re-authenticated openai-codex OAuth multiple times; auth completes successfully.
• Restarted gateway.
• Killed stale gateway/TUI/Codex app-server processes.
• Created new TUI sessions.
• Tried both openai/gpt-5.5 and openai/gpt-5.4; the problem appears to follow the runtime path rather than a single model.
• Tried setting:

  openclaw config set models.providers.openai.agentRuntime.id pi
  openclaw gateway restart

  but /status still reports Runtime: OpenAI Codex, so this did not appear to override the runtime for this route/session.

Why this seems runtime-related

The reported auth/model state is healthy, and the gateway/TUI connection is alive. The hang happens when an actual agent turn is run through Runtime: OpenAI Codex.

Related issues that look similar or adjacent:

• #64744 — Codex bundled harness hangs indefinitely on initialize
• #82710 — need Codex app-server viability checks beyond auth probe
• #84567 — Codex bundled harness initialize still hangs in isolated cron
• #85999 — 2026.5.22 gateway pre-warm blocks event loop / startup stalls

Impact

This blocks normal TUI/Web usage. The UI appears connected and authenticated, but messages remain stuck in In progress or do not return reliably. It is difficult for users to distinguish auth success from actual Codex app-server turn viability.

Additional notes

This report is specifically from an Intel-based MacBook Pro, not an Apple Silicon Mac.

If there is an officially supported way to force OpenAI models back to PI runtime / non-Codex harness on 2026.5.22, please clarify the exact config key and whether it applies to existing/new sessions. The attempted provider-level agentRuntime.id = pi did not appear to change /status in this environment.

Happy to provide sanitized config/logs or run additional diagnostics if maintainers need them.