Reasoning summary events can contain and render literal `<!-- -->` placeholders

Resolved 💬 16 comments Opened Jul 8, 2026 by Eridanus117 Closed Jul 13, 2026
💡 Likely answer: A maintainer (charliemarsh-oai, contributor) responded on this thread — see the highlighted reply below.

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-369 maps response.reasoning_summary_text.delta/done into ResponseEvent::ReasoningSummaryDelta/Done using the server-provided delta/text as-is.
  • codex-rs/core/src/session/turn.rs:2337-2368 turns ReasoningSummaryDone.text into ReasoningContentDeltaEvent.delta as-is for streaming to the client.
  • codex-rs/core/src/event_mapping.rs:177-195 maps completed ResponseItem::Reasoning.summary[].text into ReasoningItem.summary_text with text.clone().
  • codex-rs/protocol/src/legacy_events.rs:104-110 turns every ReasoningItem.summary_text into AgentReasoningEvent { text: summary.clone() }.
  • codex-rs/exec/src/event_processor_with_jsonl_output.rs:150-158 joins ThreadItem::Reasoning.summary and emits it as an exec --json reasoning item if text.trim() is non-empty.
  • codex-rs/exec/src/event_processor_with_human_output.rs:468-482 similarly joins summary entries for human output.
  • codex-rs/tui/src/chatwidget/streaming.rs:200-235 appends reasoning deltas directly into reasoning_buffer and later calls new_reasoning_summary_block.
  • codex-rs/tui/src/history_cell/messages.rs:486-499 splits **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:

  1. Do not generate <!-- --> in reasoning summary text, or
  2. 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.

View original on GitHub ↗

16 Comments

willvar · 11 days ago

I can reproduce this with Codex CLI when reasoning summaries are enabled.

Environment:

  • codex-cli 0.143.0
  • Linux x86_64
  • model: gpt-5.5
  • Responses API
  • config:
  • model_reasoning_effort = "xhigh"
  • model_reasoning_summary = "auto"
  • hide_agent_reasoning = false

Minimal Codex CLI repro:

codex exec --json 'Calculate 19 times 23. Keep the final answer short.'

Observed JSONL event:

{"type":"item.completed","item":{"id":"item_0","type":"reasoning","text":"**Providing final calculation answer**\n\n<!-- -->"}}

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:

event: response.reasoning_summary_text.delta
data: {"type":"response.reasoning_summary_text.delta","delta":"**Completing final multiplication**\n\n<!--",...}

event: response.reasoning_summary_text.delta
data: {"type":"response.reasoning_summary_text.delta","delta":" -->",...}

event: response.reasoning_summary_text.done
data: {"type":"response.reasoning_summary_text.done","text":"**Completing final multiplication**\n\n<!-- -->",...}

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.

efJerryYang · 11 days ago

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:

{
  "timestamp": "2026-07-09T15:25:25.419Z",
  "type": "event_msg",
  "payload": {
    "type": "agent_reasoning",
    "text": "**<normal text content>**\n\n<!-- -->"
  }
}
{
  "timestamp": "2026-07-09T15:25:25.419Z",
  "type": "response_item",
  "payload": {
    "type": "reasoning",
    "id": <id>,
    "summary": [
      ...
      {
        "type": "summary_text",
        "text": "**<normal text content>**\n\n<!-- -->"
      },
      {
        "type": "summary_text",
        "text": "**<another normal text content>**\n\n<!-- -->"
      },
      {
        "type": "summary_text",
        "text": "**<yet another normal text content>**\n\n<!-- -->"
      }
    ],
    "encrypted_content": ...,
    "internal_chat_message_metadata_passthrough": {
      "turn_id": <uuid>
    }
  }
}

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.

yusing · 11 days ago

Still happening using gpt-5.6 with latest codex 0.144.0

efJerryYang · 11 days ago

My codex recovered with the original setup, without codex cli update/model change. I think they have resolved the server side issue.

ligen131 · 10 days ago

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.

efJerryYang · 10 days ago

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.

NamedIdentity · 10 days ago

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.

CruxExperts · 10 days ago

Additional reproduction and local-injection audit from Linux x86_64:

  • Current affected client: codex-cli 0.144.1.
  • Switching the interactive TUI to /raw does not remove the placeholder.
  • In the current session JSONL, the literal is already present in response_item records with payload.type = "reasoning", specifically in payload.summary[].text. The paired event_msg/agent_reasoning record then contains the same text. This agrees with the raw SSE evidence above: the TUI is displaying an already-contaminated summary.
  • A read-only archive audit inspected 3,467 session files. At audit time, 194 files contained the literal, including 5,954 marker-bearing response_item/reasoning records and 17,515 downstream event_msg/agent_reasoning records. Smaller counts in messages, tool results, and compacted records were copies created after the marker was discussed or replayed.
  • Marker-bearing reasoning summaries were recorded with gpt-5.6-sol, gpt-5.6-terra, gpt-5.5, gpt-5.4-mini, and codex-auto-review across CLI 0.143.0 and 0.144.1. This does not appear isolated to one local model profile.
  • I fixed-string searched the effective assembled instructions plus global/repository AGENTS.md, Codex config, hooks, agent definitions, installed skills/plugins, shell startup configuration, Localsetup-managed context, the complete installed @openai/codex npm 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:

model_reasoning_summary = "detailed"
hide_agent_reasoning = false
show_raw_agent_reasoning = false

Setting summaries to none or hiding agent reasoning avoids displaying the symptom by suppressing summaries, but /raw is not a workaround because the literal is already part of the received reasoning-summary text.

Suggested regression acceptance check: for normal, raw, and exec --json surfaces, exercise no-tool and tool-using prompts under auto, concise, and detailed; no user-facing reasoning summary should contain a placeholder-only HTML comment line, while legitimate summary text remains intact.

anthrotype · 10 days ago

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.

hancengiz · 9 days ago

<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.

SamSaffron · 9 days ago

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

charliemarsh-oai contributor · 7 days ago

Emitting these empty placeholders was unintentional and we've since rolled out a fix on the server -- should be resolved!

NamedIdentity · 6 days ago
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 <!-- -->

anthrotype · 6 days ago

So this confirms it was a "feature", not a bug :(

No more detailed reasoning summaries for GPT 5.6.

SamSaffron · 6 days ago

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

kzhrv · 5 days ago

so what is the official stance on that? thinking summaries are removed for the codex endpoint or no?