Reasoning summary events can contain and render literal `<!-- -->` placeholders
What happened?
Reasoning summaries can contain a literal empty HTML comment placeholder, <!-- -->. This placeholder then shows up in user-facing surfaces such as the TUI progress/history view and codex exec --json output.
Example observed in the TUI:
• <!-- -->
Clarifying Codex comment leaks and prevention
<!-- -->
Proposing global instruction update
<!-- -->
A later clean-isolation run reproduced the same issue in exec --json and persisted session JSONL, so this is broader than a TUI-only rendering issue.
Environment
codex-cli: 0.143.0
release tag checked: rust-v0.143.0
model: gpt-5.5
model_reasoning_effort: xhigh
model_reasoning_summary: auto / concise / detailed / none tested
OS: macOS 26.5.1, arm64
terminal: Ghostty 1.3.2-HEAD-+05c3e29
install: Homebrew cask
subscription/auth: ChatGPT Pro auth
The regular user config originally had:
model_reasoning_summary = "auto"
model_reasoning_effort = "xhigh"
codex doctor --json reported overallStatus = warning, but the warning was about rollout/session inventory mismatch with an empty historical session file; it appears unrelated. Config parsing and auth were OK, and the responses websocket handshake succeeded.
Clean-isolation reproduction
I reproduced with a fresh temporary HOME and CODEX_HOME, copying only auth.json so the CLI could authenticate. The invocation used --ignore-user-config --ignore-rules, a temp working directory, and no user hooks, personal skills, AGENTS.md, project instructions, or user config.
Command shape:
ISO_ROOT=$(mktemp -d /tmp/codex-clean-iso2.XXXXXX)
ISO_HOME="$ISO_ROOT/home"
ISO_CODEX="$ISO_ROOT/codex"
mkdir -p "$ISO_HOME" "$ISO_CODEX"
cp "$HOME/.codex/auth.json" "$ISO_CODEX/auth.json"
HOME="$ISO_HOME" CODEX_HOME="$ISO_CODEX" \
codex --ask-for-approval never --sandbox workspace-write \
exec --json --ignore-user-config --ignore-rules --skip-git-repo-check \
-C "$ISO_ROOT" -m gpt-5.5 \
-c 'model_reasoning_effort="xhigh"' \
-c 'model_reasoning_summary="auto"' \
< "$ISO_ROOT/prompt.txt" > "$ISO_ROOT/out.jsonl"
Prompt:
Without using the network, inspect this empty temp workspace. Run `pwd` and `ls -la`, then answer with two concise bullet points: what files are present and the current working directory basename.
Result: reproduced in exec --json:
{"type":"item.completed","item":{"id":"item_0","type":"reasoning","text":"**Planning parallel command execution**\n\n<!-- -->"}}
The persisted isolated session JSONL also contained the placeholder in both agent_reasoning and completed reasoning.summary_text:
{"type":"event_msg","payload":{"type":"agent_reasoning","text":"**Planning parallel command execution**\n\n<!-- -->"}}
{"type":"response_item","payload":{"type":"reasoning","summary":[{"type":"summary_text","text":"**Planning parallel command execution**\n\n<!-- -->"}]}}
A minimal no-tool prompt in the same isolation style did not reproduce; its session had "summary": []. So the issue appears task-shape dependent and intermittent, but it reproduces without my local config/hooks/skills/project instructions.
Matrix
I then ran a small clean-isolation matrix: model_reasoning_summary x task shape.
summary_mode task_shape stdout <!-- --> session <!-- --> agent_reasoning events reasoning summary items
auto no_tool 0 0 0 0
auto tool 0 0 0 0
concise no_tool 0 0 1 1
concise tool 0 0 1 1
detailed no_tool 0 0 0 0
detailed tool 1 2 1 1
none no_tool 0 0 0 0
none tool 0 0 0 0
The detailed + tool run produced:
{"kind":"agent_reasoning","text":"**Running parallel directory commands**\n\n<!-- -->"}
{"kind":"reasoning","summary":["**Running parallel directory commands**\n\n<!-- -->"]}
I also repeated the auto + tool case five times with the same isolated prompt. Runs 1-4 did not emit summaries; run 5 emitted two reasoning summary items, both with the placeholder:
run stdout <!-- --> session <!-- --> agent_reasoning events reasoning summary items
1 0 0 0 0
2 0 0 0 0
3 0 0 0 0
4 0 0 0 0
5 2 4 2 2
Run 5 summary texts:
**Planning parallel execution of pwd and ls**\n\n<!-- -->
**Preparing to execute pwd and ls commands**\n\n<!-- -->
Local session frequency
In my normal ~/.codex/sessions/2026/07/08 data, before the clean-isolation checks, I found:
files with agent_reasoning containing <!-- -->: 9
agent_reasoning entries containing <!-- -->: 1680
Representative normal-session lines:
{"type":"event_msg","payload":{"type":"agent_reasoning","text":"**Clarifying Codex comment leaks and prevention**\n\n<!-- -->"}}
{"type":"event_msg","payload":{"type":"agent_reasoning","text":"**Proposing global instruction update**\n\n<!-- -->"}}
{"type":"response_item","payload":{"type":"reasoning","summary":[{"type":"summary_text","text":"**Clarifying Codex comment leaks and prevention**\n\n<!-- -->"},{"type":"summary_text","text":"**Proposing global instruction update**\n\n<!-- -->"}]}}
Those entries predated the user later copying the visible leak back into the conversation, so they were not merely echoes of user-provided text.
Source-path notes from rust-v0.143.0
I checked the release tag corresponding to the installed version. The user-facing path appears to pass summary text through without filtering:
codex-rs/codex-api/src/sse/responses.rs:354-369mapsresponse.reasoning_summary_text.delta/doneintoResponseEvent::ReasoningSummaryDelta/Doneusing the server-provideddelta/textas-is.codex-rs/core/src/session/turn.rs:2337-2368turnsReasoningSummaryDone.textintoReasoningContentDeltaEvent.deltaas-is for streaming to the client.codex-rs/core/src/event_mapping.rs:177-195maps completedResponseItem::Reasoning.summary[].textintoReasoningItem.summary_textwithtext.clone().codex-rs/protocol/src/legacy_events.rs:104-110turns everyReasoningItem.summary_textintoAgentReasoningEvent { text: summary.clone() }.codex-rs/exec/src/event_processor_with_jsonl_output.rs:150-158joinsThreadItem::Reasoning.summaryand emits it as anexec --jsonreasoning item iftext.trim()is non-empty.codex-rs/exec/src/event_processor_with_human_output.rs:468-482similarly joins summary entries for human output.codex-rs/tui/src/chatwidget/streaming.rs:200-235appends reasoning deltas directly intoreasoning_bufferand later callsnew_reasoning_summary_block.codex-rs/tui/src/history_cell/messages.rs:486-499splits**header**from the remaining content. For**Header**\n\n<!-- -->, the remaining content is non-empty, so the final reasoning cell displays the literal placeholder.
Expected behavior
User-facing reasoning summaries should not expose literal empty HTML comment placeholders.
Either:
- Do not generate
<!-- -->in reasoning summary text, or - Normalize/filter placeholder-only HTML comment lines before emitting user-facing reasoning summary events and rendering them.
If raw ResponseItem persistence should remain untouched for debugging, the filter could live in the user-facing conversion/rendering layers, such as the AgentReasoningEvent / ThreadItem::Reasoning / exec --json / TUI history conversion path.
Workaround
model_reasoning_summary = "none" parses successfully and avoided the issue in the matrix, but it disables reasoning summaries entirely.
16 Comments
I can reproduce this with Codex CLI when reasoning summaries are enabled.
Environment:
codex-cli 0.143.0gpt-5.5model_reasoning_effort = "xhigh"model_reasoning_summary = "auto"hide_agent_reasoning = falseMinimal Codex CLI repro:
Observed JSONL event:
I can also reproduce it at the raw Responses SSE layer. The placeholder is already present in
response.reasoning_summary_text.delta/done, before client storage or rendering:This suggests the placeholder is emitted as part of the reasoning summary text itself. Clients that request and display reasoning summaries can surface the literal empty HTML comment placeholder.
I believe it's the server would no longer send out the actual reasoning summaries, instead they send out the placeholder html tag. It's not a rendering issue:
Either they intentionally did this (which is a really bad customer facing action), or it was a regression in their server side. I think an openai engineer needs to explain this.
Still happening using gpt-5.6 with latest codex 0.144.0
My codex recovered with the original setup, without codex cli update/model change. I think they have resolved the server side issue.
This appears to be a model-side issue. GPT-5.6 was released today, and after my testing, only the 5.6 series models exhibit this problem — it reproduces consistently and reliably. It's unrelated to which client/tool is being used. Interestingly, some users reported seeing this same phenomenon with 5.5 yesterday, before 5.6 was even released — likely because they had already been grayscale-rolled into the 5.6 model under the hood.
Issue recovered for my GPT 5.5 usage, but when i upgraded the codex and started using GPT 5.6, same issue recurred. Probably the symptom was indeed from GPT 5.6, and they were limiting the reasoning transparency for their strongest model.
I can confirm this issue occurs in OpenCode v.1.17.11 as well.
This issue interferes with harness customization and plugin development. Even the limited thinking block summary of GPT models provide important diagnostic data on model behavior necessary to tune system prompts, tool descriptions, skills, and determine where and why a workflow failed. Without thinking blocks, model harness performance will degrade relative to other models - it breaks the feedback loops needed to have the model self-assess it's failure point, or have external models perform a retrospective analysis of the GPT session data.
Additional reproduction and local-injection audit from Linux x86_64:
codex-cli 0.144.1./rawdoes not remove the placeholder.response_itemrecords withpayload.type = "reasoning", specifically inpayload.summary[].text. The pairedevent_msg/agent_reasoningrecord then contains the same text. This agrees with the raw SSE evidence above: the TUI is displaying an already-contaminated summary.response_item/reasoningrecords and 17,515 downstreamevent_msg/agent_reasoningrecords. Smaller counts in messages, tool results, and compacted records were copies created after the marker was discussed or replayed.gpt-5.6-sol,gpt-5.6-terra,gpt-5.5,gpt-5.4-mini, andcodex-auto-reviewacross CLI0.143.0and0.144.1. This does not appear isolated to one local model profile.AGENTS.md, Codex config, hooks, agent definitions, installed skills/plugins, shell startup configuration, Localsetup-managed context, the complete installed@openai/codexnpm package, and the native Codex executable. None contained the literal. The only non-runtime local hits were documentation of this defect and unrelated HTML-comment parser examples.Sanitized current configuration relevant to visibility:
Setting summaries to
noneor hiding agent reasoning avoids displaying the symptom by suppressing summaries, but/rawis not a workaround because the literal is already part of the received reasoning-summary text.Suggested regression acceptance check: for normal, raw, and
exec --jsonsurfaces, exercise no-tool and tool-using prompts underauto,concise, anddetailed; no user-facing reasoning summary should contain a placeholder-only HTML comment line, while legitimate summary text remains intact.I sincerely hope this does not end up like https://github.com/anthropics/claude-code/issues/8477 where Anthropic silently took away one of Claude's most important features (thinking visibility), and forced many of us to patch their minified JS binaries.
But if OpenAI's redaction is server-side there is nothing we can do.
<img width="1808" height="1894" alt="Image" src="https://github.com/user-attachments/assets/9def310d-4341-4fcd-86fc-acd3122281cd" />
<img width="1126" height="1380" alt="Image" src="https://github.com/user-attachments/assets/0633c9ac-73d5-4d01-a75e-a2a1a0899152" />
I can confirm when I use codex via codex-acp in an acp client (fabriqa) I see this same thinking blocks rendered with those HTML placeholder literals.
Cross ref to https://community.openai.com/t/codex-i-miss-the-reasoning-summaries/1386528
Note this is codex api specific, reasoning works fine in responses api
Emitting these empty placeholders was unintentional and we've since rolled out a fix on the server -- should be resolved!
Still no thinking summaries in OpenCode v1.17.11. Just thought titles, and now absent the
<!-- -->So this confirms it was a "feature", not a bug :(
No more detailed reasoning summaries for GPT 5.6.
That is not confirmed detailed reasoning works on for pay api per: https://community.openai.com/t/codex-i-miss-the-reasoning-summaries/1386528/4?u=sam.saffron
It is unclear if the removal is deliberate or not on codex
so what is the official stance on that? thinking summaries are removed for the codex endpoint or no?