Surface: CLI
Codex version:0.154.0
OS and IDE/browser, if relevant: Linux Arch
Model and plan or API-key authentication: Plus
What happened, and what did you expect?
Steps or a minimal prompt/example:
Exact error, relevant logs, or screenshot:
EricGT
September 12, 2026, 9:05pm
2
Welcome to the forum!
You posted this in the appropriate place on the forum for discussing and documenting a Codex bug. The forum, however, is not the official issue tracker. If the problem needs to be formally reported and tracked by the Codex maintainers, the official place is the OpenAI Codex GitHub issue tracker .
It might help if more details from the posting requirements for the Codex Bugs subcategory were added:
Report reproducible bugs in the Codex CLI, IDE extension, app, or web experience.
Include your Codex version, environment, steps to reproduce, and expected versus actual behavior. Provide a minimal reproducible example where possible.
Model hallucinations or differences in generated output alone are not considered bugs for this category.
Keep each topic focused on one bug. Use the main Codex category for discussions and Feature Requests for proposed improvements.
When a fix is available, con…
I asked ChatGPT to search for the closest related issue, and it identified:
opened 02:54AM - 08 Aug 26 UTC
bug
model-behavior
CLI
app
### What version of Codex CLI is running?
`codex-cli 0.147.0`
### What subscri… ption 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:
```text
<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:
```json
{
"type": "response_item",
"payload": {
"type": "message",
"role": "assistant",
"id": "<redacted>"
}
}
```
The corresponding completion event is:
```json
{
"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:
```text
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](https://github.com/openai/codex/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](https://github.com/openai/codex/issues/34174) reports internal stream/protocol fragments in Codex App replies, but covers a different Desktop corruption pattern and no matching persisted-message schema.
- [#33033](https://github.com/openai/codex/issues/33033) concerns reasoning snippets rendered after a final App response; it is an event-ordering/display case, not this message classification evidence.
- [#30190](https://github.com/openai/codex/issues/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](https://github.com/openai/codex/issues/31664) concerned literal `` placeholders in persisted `reasoning` summaries and is closed after a server-side fix; the item type differs from this report.
- [#17523](https://github.com/openai/codex/issues/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.
I also asked it to look for issues related to using Portuguese as I can not tell what part of the conversation is yours and what part is from the AI and it identified
opened 10:10PM - 27 Dec 25 UTC
enhancement
### What feature would you like to see?
## Problem
Agent reasoning in TUI is a… lways displayed in English, regardless of the user's input language. This breaks the narrative flow for non-English users.
## Impact
- **Cognitive load**: Users must mentally switch between languages while reading reasoning + writing prompts
- **Lost context**: The reasoning is the primary way users understand agent decisions — if it's in a foreign language, this value is diminished
- **Inconsistent UX**: User writes in their language → agent reasons in English → creates jarring experience
## Proposed solution
Add language detection for user input and instruct the model to output reasoning in the matched language.
Alternatively, expose a `reasoning_language` config option in `config.toml`:
```toml
[model]
reasoning_language = "auto" # or "en", "ru", "zh", etc.
```
## Prior art
Claude Code handles this gracefully — reasoning appears in the language the user communicates in.
### Additional information
Tested on macOS with Codex CLI. User input in Russian, all reasoning output appeared in English.
If those issue describes the same problem you are experiencing, consider adding a
If either does not match your problem closely enough, search the existing Codex issues for a better match. If you cannot find one, consider opening a new issue and include as much relevant information as possible, such as your Codex version, operating system, environment, reproduction steps, expected behavior, actual behavior, and any relevant logs or error messages.
reaction to the GitHub issue itself, rather than only reacting to this forum topic. GitHub reactions can help the maintainers gauge how many users are affected.