bug(cli): reasoning summaries may be omitted and some responses stream events can crash the CLI

Open 💬 6 comments Opened Apr 4, 2026 by steveday763
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.118.0

Which model were you using?

gpt-5.4

What platform is your computer?

Linux x86_64

What issue are you seeing?

I started investigating a TUI rendering issue where reasoning summaries are present in the session JSONL but not shown in the live TUI.

While validating a minimal local fix for that, I also ran into crashes in the same Responses stream handling path, for example:

  • ReasoningSummaryPartAdded without active item
  • OutputTextDelta without active item

So there appear to be two closely related problems here:

  1. completed reasoning items can contain summary text that is recorded but not rendered live
  2. the stream state machine is brittle when reasoning/output-text events arrive before the corresponding active item is established

What steps can reproduce the bug?

  1. Run Codex CLI on the Responses API path.
  2. Enable reasoning summaries in config, for example:
model_reasoning_effort = "xhigh"
model_reasoning_summary = "auto"
use_experimental_reasoning_summary = true
hide_agent_reasoning = false
show_raw_agent_reasoning = false
model_supports_reasoning_summaries = true
  1. Start a session that returns reasoning summary data.
  2. Observe that the reasoning summary may be recorded in the session log but not shown in the live TUI.
  3. While validating that path, some streams can also trigger crashes because reasoning/output-text events arrive before the corresponding active item is active.

What is the expected behavior?

  • If a completed reasoning item contains summary text, the live TUI should render it.
  • The client should handle these event-ordering edge cases without crashing.

Additional information

I found a session entry like this in the JSONL log:

{
  "timestamp": "2026-04-04T14:53:06.784Z",
  "type": "response_item",
  "payload": {
    "type": "reasoning",
    "summary": [
      {
        "type": "summary_text",
        "text": "..."
      }
    ]
  }
}

This suggests the reasoning summary is present in the stream/session log, but the live TUI still does not render it.

The crashes I hit while validating this path were:

  • ReasoningSummaryPartAdded without active item
  • OutputTextDelta without active item

I put together a small branch in my fork with two commits covering both aspects:

  • branch: steveday763/fix/reasoning-and-output-delta-ordering
  • commits:
  • 7a1a825 fix(tui): render live reasoning summaries from completed items
  • 9795819 fix(core): tolerate orphan reasoning and output text events

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15720

Powered by Codex Action

etraut-openai contributor · 3 months ago

Are you using the standard OpenAI responses endpoint, or are you using Azure-hosted models, an LLM proxy, or some other responses endpoint?

Have you seen this more than once?

Do you still have this session around? Can you resume it without a crash? If so, use /feedback to upload your session details and post the thread ID here.

steveday763 · 3 months ago

I'm using the OpenAI Responses API through a very thin reverse proxy. In this setup it just forwards the stream and does not intentionally rewrite or transform upstream events.

I can reproduce the missing reasoning-summary issue very frequently. On my side, cases where the reasoning summary shows up correctly are actually rare.

I've also seen a few other people around me run into the same behavior, so it does not look isolated to just my environment.

I also inspected packet captures of the real upstream OpenAI response stream, and I could see the same event-ordering anomalies there before any local handling on my side. That makes me think the ordering issue is not being introduced by my proxy.

One clarification on the crash reports: the crash came from my local validation / hardening patch while I was testing this stream-handling path. Stock Codex CLI does not crash in my normal repro for the missing-summary issue itself.

Expected behavior:

  • If a response contains reasoning.summary, the live TUI should render it.

<img width="1035" height="528" alt="Image" src="https://github.com/user-attachments/assets/0398aaa0-c555-413b-9319-c2387eb1e5bb" />
like this

Actual behavior:

  • The live TUI often does not show the reasoning summary, even though the corresponding session / JSONL entry clearly contains the reasoning.summary payload.

<img width="1710" height="650" alt="Image" src="https://github.com/user-attachments/assets/984eac09-fb98-4bfd-904c-92943b0b5f64" />
<img width="1695" height="636" alt="Image" src="https://github.com/user-attachments/assets/581cd512-4908-4424-9966-1427237622d2" />

I uploaded feedback from a repro session. Thread ID:
019d5cb9-f102-7422-8457-e0a0508eaecb

etraut-openai contributor · 3 months ago

Thanks for the additional details. Your logs do show evidence of out-of-order reasoning-summary events.

On first inspection, it doesn't appear that our responses API would produce events in this order. It's possible that we've missed something in our initial analysis, but at this point we suspect that it may be your LLM proxy that's reordering events. Could you please eliminate that from the equation to see if the problem goes away?

steveday763 · 3 months ago

I tested it without the proxy, and the problem still exists.

I also asked around, and three of my friends have the same issue. They are using direct Codex OAuth login, not proxy. I think there's a bug on the server side.

Btw, it's happening much less often now.

etraut-openai contributor · 3 months ago

OK, thanks for the confirmation.