Codex CLI replays terminal capability queries from persisted tool output on session resume

What version of Codex CLI is running?

codex-cli 0.150.0-alpha.12.2

What subscription do you have?

Pro

Which model were you using?

No response

What platform is your computer?

Linux 5.10.0-60.18.0.50.r865_35.hce2.aarch64 aarch64 aarch64

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

tmux

Codex doctor report

What issue are you seeing?

Description

Codex CLI may replay terminal control sequences contained in persisted tool output when resuming an interactive session.

If historical PTY output contains terminal capability queries such as:

• ESC [ c (Primary Device Attributes)
• ESC [ > c (Secondary Device Attributes)
• ESC [ > q (terminal version query)

resuming the session can write those sequences back to the active terminal. Inside tmux, tmux interprets them as live terminal queries and injects responses into the pane's input stream.

Example responses from tmux include:

ESC [ > 84 ; 0 ; 0 c
ESC P > | tmux 3.5a ESC \

Parts of those responses may then appear as literal text in the Codex pane:

84;0;0c>|tmux 3.5a

A fresh Codex session does not exhibit the problem. It is associated with the persisted history of the resumed session.

What steps can reproduce the bug?

1. Start tmux:

   tmux
   

2. Start a new interactive Codex CLI session:

   codex
   

3. In that session, cause a tool or PTY command result to contain terminal capability queries. For example, ask Codex to run:

   printf '\033[c\033[>c\033[>q'
   

4. Exit Codex after the tool output has been persisted.

5. Resume the same session:

   codex resume <SESSION_ID>
   

6. Observe whether text similar to the following appears in the Codex pane:

   84;0;0c>|tmux 3.5a
   

7. As a control, start a fresh Codex session with no persisted terminal-query output. The text should not appear.

Additional verification

The affected rollout can be checked for an encoded Secondary Device Attributes query without printing the transcript:

rg -a -l '\\u001b\\[>c' ~/.codex/sessions

In the observed case:

• The rollout remained valid JSON.
• The tmux response strings were not present in the stored transcript.
• The stored transcript did contain encoded terminal query sequences.
• A read-only resume reproduced the response text without starting a new turn.
• --no-alt-screen did not prevent the issue.

This indicates that the response is generated at runtime by tmux rather than being corrupt text already stored in the session.

What is the expected behavior?

Expected behavior

Historical tool output should be rendered as inert text.

Terminal control sequences stored in a transcript should not be emitted as active terminal protocol commands during session restoration.

Terminal query responses should also be recognized and consumed rather than treated as keyboard input or printable text.

Actual behavior

When the affected session is resumed:

1. Codex restores historical PTY/tool output.
2. Stored terminal queries are written to the active pane.
3. tmux interprets the queries and sends its device/version responses to the pane input.
4. Printable parts of the responses appear in the Codex TUI.

The issue can occur during startup or periodically while session history is being restored or rendered.

Additional information

Environment

• Linux
• tmux 3.5a
• Outside tmux: TERM=xterm-256color
• Inside tmux: TERM=tmux-256color
• Codex CLI interactive TUI

Start by reproducing the issue with tmux, a persisted terminal query, and codex resume <SESSION_ID>; inspect the session data under ~/.codex/sessions and trace session restoration and PTY output rendering. Verify that historical tool output is restored as inert text, terminal queries are not emitted to tmux, and their responses do not appear as input in the Codex TUI.