GPT-5.6 Sol leaks literal <thinking> tool-planning text as visible assistant messages in CLI and Codex App

[MrZoyo]

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

Not recorded for the affected session.

Which model were you using?

gpt-5.6-sol, reasoning effort max (from the affected rollout's turn metadata).

What platform is your computer?

The primary affected CLI rollout was on Linux x86_64 (Linux 6.9.12-060912-generic x86_64 x86_64). A separate occurrence was observed in the Codex App running on Windows with a WSL-based environment; its app build was not captured.

What terminal emulator and version are you using (if applicable)?

The rollout identifies the CLI/TUI (codex-tui); the terminal emulator was not recorded.

Codex doctor report

codex doctor --json was run with CLI 0.147.0 and reviewed for redaction. Sanitized result: schema version 1, overall status warning, 18 checks total (17 ok, one config.load warning). The full report is omitted because it contains local paths and provider/auth-state details that are unrelated to this bug.

What issue are you seeing?

Intermittently, GPT-5.6 Sol emits low-level, internal-looking tool-routing/planning text wrapped in a literal <thinking>...</thinking> block as ordinary user-visible assistant output. This is distinct from supported user-facing reasoning/progress summaries.

Short examples observed in visible output include:

<thinking>**Realizing tool name is functions.exec absent in listed namespace?** ...</thinking>
<thinking>**Noticing repeated tool misuse due UI autocomplete?** ...</thinking>

The leaked text discusses tool namespaces, recipients, and direct tool invocation strategy. It is rendered as a raw-looking assistant message while normal progress summaries (for example, Clarifying function call usage) continue to render in their usual reasoning/progress presentation.

Important persisted-session evidence

I inspected only matching records from one affected CLI rollout; no complete JSONL is attached. The relevant records have this sanitized shape:

{
  "type": "response_item",
  "payload": {
    "type": "message",
    "role": "assistant",
    "id": "<redacted>"
  }
}

The corresponding completion event is:

{
  "type": "event_msg",
  "payload": {
    "type": "item_completed",
    "item": {
      "type": "AgentMessage",
      "id": "<same redacted id>"
    }
  }
}

There is no explicit phase field in these records. A separate preceding response_item has payload.type: "reasoning" with a different item ID. Thus, in the persisted session artifact, the leaked text is stored as an assistant message / derived AgentMessage, not as a reasoning item. This means the evidence does not support describing the problem primarily as a renderer displaying an actual reasoning item incorrectly.

Observations and reproduction scope

The following are observations rather than a deterministic minimal reproduction:

1. In the primary CLI session, the leak occurred more than once around tool-routing/execution work. The affected rollout metadata records CLI 0.147.0, source codex-tui, model gpt-5.6-sol, and effort max.
2. In a separate Codex App working session, the visible conversation independently contained <thinking>Spawning archive agent with plaintext issue</thinking> and <thinking>Calling collaboration spawn_agent directly</thinking>. This suggests the behavior is not specific to the CLI renderer or to functions.exec alone.
3. Another CLI session exposed similar low-level discussion of functions.exec, functions.wait, and tool recipients while investigating this report. I treat that as supporting evidence only, because the prompt itself mentioned the suspected leak and tool names.

The observed cases occurred during normal multi-step work involving tool or collaboration routing; I have not established a reliable clean prompt that reproduces it on demand.

What steps can reproduce the bug?

No deterministic minimal reproduction is available yet. The observed workflow is:

1. Use GPT-5.6 Sol in Codex CLI or Codex App with normal tool/collaboration support enabled.
2. Run a multi-step task that requires tool routing or collaboration.
3. Watch the visible assistant output for a literal <thinking>...</thinking> block containing low-level tool-planning text.
4. If it occurs in CLI, inspect only the matching rollout records and check whether the item is persisted as payload.type: "message", role: "assistant" / AgentMessage rather than reasoning.

What is the expected behavior?

Internal model/tool-routing/planning text must never be emitted as an ordinary user-visible assistant message. If reasoning summaries are enabled, only supported user-facing summaries should be shown. Low-level namespace resolution, recipient selection, direct tool invocation strategy, and literal <thinking> blocks should remain non-visible/internal. A malformed or ambiguous tool call should recover cleanly without converting internal planning into a normal assistant message.

Additional information

The exact fault boundary is unclear. The observed pipeline is:

model / Responses / Codex processing
          -> persisted response_item (message, assistant)
          -> derived AgentMessage
          -> UI

This leaves at least two hypotheses: GPT-5.6 Sol may have emitted the content into a visible channel, or an upstream Responses/Codex/app-server adapter may have classified/converted it incorrectly. I have not established which, and I am not claiming that the model, server, or renderer alone is definitively responsible.

Possibly related issues:

• #34245 also involves GPT-5.6 Sol, malformed tool calls, and reasoning-like leakage, but does not document literal <thinking> text or the persisted message/AgentMessage evidence here.
• #34174 reports internal stream/protocol fragments in Codex App replies, but covers a different Desktop corruption pattern and no matching persisted-message schema.
• #33033 concerns reasoning snippets rendered after a final App response; it is an event-ordering/display case, not this message classification evidence.
• #30190 concerns AgentMessage.phase being dropped in an exec/SDK path. The missing phase is relevant context, but that report does not explain why this text became an assistant message.
• #31664 concerned literal <!-- --> placeholders in persisted reasoning summaries and is closed after a server-side fix; the item type differs from this report.
• #17523 reports raw subagent notification JSON in the main chat, but is an older/different multi-agent envelope and does not cover this Sol <thinking> behavior.

Affected CLI session ID: 019fdcdf-2aa6-7a63-a8b4-db731ca62886.

I intentionally omitted complete session JSONL, prompts, project content, absolute paths, hostnames, usernames, provider details, and secrets. Only short literal examples and the minimum event-type evidence are included.