Codex CLI pre-fills prompt with OSC palette reply on macOS Terminal

What version of Codex is running?

0.46.0

Which model were you using?

_No response_

What platform is your computer?

codex running on Linux. ssh from MacOS Terminal to Linux.

What steps can reproduce the bug?

Steps to Reproduce

1. Open Terminal on macOS and start an SSH session into the Debian host.
2. Run codex (or any wrapper that just execs it).
3. Switch away and back to the Codex window, or simply wait for the UI to render the prompt.

What is the expected behavior?

_No response_

What do you see instead?

_No response_

Additional information

Environment

• macOS Terminal (built‑in app) on Mac (user is ssh-ing in; Terminal likely 3.x, macOS 14/15).
• Remote host: Debian 13 (“Trixie”), kernel 6.12.48+deb13-cloud-amd64.
• Codex CLI version: 0.46.0 (binary installed via npm at /usr/lib/node_modules/@openai/codex).
• SSH session using the default login shell (bash) with stock .bashrc.

Observed Result

• Each time the Codex TUI finishes drawing (especially after Terminal regains focus), a line beginning with the palette response 10;rgb:ffff/ffff/

ffff11;rgb:2b5f/66a6/c977 appears in the input buffer. The Codex prompt is still there, but the reply from the terminal is pasted into the same line,
so the user has to manually delete it before typing a command.

Expected Result

• Codex should consume the terminal’s OSC 10/11 response internally (or not request palette info unless it will handle the reply), leaving the user

prompt empty.

Notes

• The string matches Apple Terminal’s OSC 10/11 color reply format (ESC]10;rgb:...BEL). It seems Codex sends the query but doesn’t discard the response,

so the raw text becomes user input.

• The issue occurs even with default shell configuration; no prompt hooks are involved.
• Other terminal emulators (e.g., iTerm2) may or may not echo the same response, but the bug is easiest to reproduce on the stock macOS Terminal.

Workaround Tried

• Attempted to disable tui.apply_terminal_palette, but Codex still issued the OSC request.
• Shell-level filters work but are intrusive, so a fix in the CLI would be preferable.