Codex App: expose reasoning summaries or progress traces when configured

Open 💬 2 comments Opened Jun 9, 2026 by tlerbao

What problem are you trying to solve?

In Codex App, turns currently only show a brief blinking Thinking state and then the final answer. Even with reasoning-related config enabled, I do not see an expandable reasoning summary, progress trace, or Thought-style section while the turn is running or after it completes.

This makes it harder to understand what the agent is doing on longer tasks, compare behavior with other agent UIs, or debug cases where the answer is surprising.

Current behavior

I submit a prompt in Codex App.
The UI shows a blinking Thinking label.
The final response appears.
No visible reasoning summary / progress trace is shown.

Expected behavior

It would be helpful if Codex App exposed an optional, expandable reasoning-summary/progress panel when configured, similar in spirit to the way some agent UIs show a Thought: or trace section. This does not need to expose private chain-of-thought verbatim; a surfaced reasoning summary or structured progress trace would be enough.

Ideally this would work consistently with the existing config knobs:

model_reasoning_summary = "detailed"
hide_agent_reasoning = false
show_raw_agent_reasoning = true

If Codex App intentionally does not support showing these events, it would also be helpful for the UI or docs to make that clear.

Environment

Codex App: 26.602.71036 (bundle version 3685)
Codex CLI: 0.137.0
macOS: 13.3 (22E252)
Model: gpt-5.5
Reasoning effort: high
Service tier: fast

Related context

I found a few possibly related issues where reasoning summaries / progress traces appear to be present in some layer but are not reliably visible in a client UI:

#24287
#16801
#9470

This request is specifically for Codex App / desktop UI behavior.

View original on GitHub ↗

2 Comments

rodja · 1 month ago

We can add a controlled data point that suggests this is not (only) a UI
rendering gap: on the app-server path the backend returns reasoning items
with an empty summary array, while the identical request via
codex exec receives summary text.

Setup: codex-cli 0.144.1 (rust, Linux x86_64), ChatGPT Pro account
(OAuth), model gpt-5.6-sol, model_reasoning_effort=medium. Both paths
use the same transport (wss://chatgpt.com/backend-api/codex/responses),
and the rollout files' turn_context shows the same requested settings
("summary": "auto", effort medium) in both cases. Same prompt, runs
interleaved within minutes (2026-07-13).

| Path | Result |
|---|---|
| codex exec (auto, detailed, and with CODEX_INTERNAL_ORIGINATOR_OVERRIDE=openclaw) | summary_text present, 5/5 runs |
| codex app-server, minimal JSON-RPC client (initialize → thread/start → turn/start, no special params; experimentalRawEvents on/off) | "summary": [], 6/6 runs |
| app-server production traffic via a third-party host (OpenClaw), models gpt-5.4/5.5/5.6 | 0 of 4093 rollouts with summary text (2026-05-01…07-13) |

Notes:

The empty summaries are visible in the app-server's **own rollout

files** (reasoning items complete with "summary": [] while
encrypted_content is present), so the data never reaches the client —
unlike #16801, where summaries made it into the session log and only
the TUI dropped them.

Since it reproduces with a minimal app-server client, is independent of

the originator header, and the requested reasoning.summary is the
same on both paths, it looks like the backend decides whether to
generate summary text from the surface the thread registers as
(app-server threads show source: "vscode" in session_meta) rather
than from the request settings. That would also explain the Codex
App/IDE behavior reported in this issue.

Possibly adjacent to the elision regression discussed in the community

thread "Codex, I miss the reasoning summaries" (since ~Jul 9), but our
app-server data is empty since at least May, so this looks
longer-standing.

Happy to share the minimal app-server repro script (~100 lines of Python,
JSON-RPC over stdio) if useful.

ropepop · 15 days ago

Complementary data point from the client read-path side (2026-08-12), on the remote surface — the mechanism rodja diagnosed from the backend side shows up again from the view-selection side here:

On ChatGPT remote (iOS), a settled thread renders via thread/resume with turns at itemsView:"summary" — per turn it materializes only the user message and the final answer. Everything rodja described (summaries present in the rollout/provided paths, hidden from the client) also appears here, but for the whole middle (reasoning + tool items), because the remote client's default view simply never asks the server for them.

Concretely, live on this thread: native gpt-5.6 thread opened from iOS remote shows traces/tool activity while streaming, then no expand button once completed — the summary view hides the whole middle. Leaving and reopening the thread forces thread/turns/list (full view) and the middle reappears; identical behavior is seen with a custom provider (DeepSeek via OmniRoute/OpenCodex), confirming this is a client-render-path gate, not a provider- or originator-specific one.

So the app-server's empty-summary-vs-filled-summary split rodja proved would still need this client-side fix on top: the settled remote view must fetch and render the full item history — summary view drops it regardless of what the backend populated. (Related, different half of the delivery problem: #16801 / TUI; also #35371 where image-bearing items drop from the completed mobile render in the same summary-only way.)