Linux X11: clipboard owner advertises text/plain targets it refuses to serve, so some apps paste nothing

What version of Codex CLI is running?

codex-cli 0.149.1

What platform is your computer?

Ubuntu 24.04.4 LTS, kernel 7.0.0-30-generic, local X11 session (XDG_SESSION_TYPE=x11), KDE Plasma.

What issue are you seeing?

After copying text out of the Codex TUI, codex correctly takes and keeps ownership of the X11 CLIPBOARD selection — but the selection it serves is inconsistent: it advertises three text targets in TARGETS and only answers one of them. Requests for the other two are answered with SelectionNotify / property = None, i.e. "conversion refused".

Any application that picks one of the advertised-but-unserved targets receives nothing and pastes an empty string, while reporting no error. This is not the older "clipboard stays empty" bug (#15663, fixed in 0.121/0.122) — ownership is held correctly here, and one target does return the data.

What steps can reproduce the bug?

1. Copy some text out of the Codex TUI so that codex becomes the CLIPBOARD owner.
2. Inspect the advertised targets:

$ xclip -o -selection clipboard -t TARGETS
UTF8_STRING
text/plain;charset=utf-8
text/plain;charset=UTF-8
TARGETS
SAVE_TARGETS

1. Request each advertised target:

$ xclip -o -selection clipboard -t UTF8_STRING | wc -c
8478

$ xclip -o -selection clipboard -t 'text/plain;charset=utf-8'
Error: target text/plain;charset=utf-8 not available

$ xclip -o -selection clipboard -t 'text/plain;charset=UTF-8'
Error: target text/plain;charset=UTF-8 not available

Confirming that the owner really is codex (via the X-Resource extension, XResQueryClientIds on the selection owner window):

CLIPBOARD owner window: 0x7800000
  pid = 2003984
  cmdline: .../@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin/codex

What is the expected behavior?

A selection owner must be able to convert every target it lists in TARGETS (ICCCM 2.2). Either:

• serve text/plain;charset=utf-8 and text/plain;charset=UTF-8 with the same bytes as UTF8_STRING, or
• advertise only the targets that are actually served.

Additionally, TIMESTAMP and MULTIPLE are mandatory targets for any selection owner per ICCCM 2.6.2, and neither is advertised; STRING and TEXT are conventionally expected for text selections and are also missing.

What do you see instead?

Whether a paste works depends on which target the receiving application happens to ask for:

| Application | Target requested | Result |
| --- | --- | --- |
| Kate, Konsole, Firefox, VS Code | UTF8_STRING | text pastes correctly |
| CudaText 1.236 (Lazarus/Qt5) | UTF8_STRING, then text/plain;charset=UTF-8 | pastes nothing |

The failing application is not doing anything exotic — it asks for a target that the owner published.

I confirmed the causal chain on a separate Xvfb display with a ~70-line X11 selection owner that mimics this behaviour, so no Codex or editor internals are involved:

• owner advertises the three targets and serves only UTF8_STRING → paste produces an empty string
• same owner, same client, serving all advertised targets → paste produces the text

Owner-side log of the failing case, showing the refusal (231 = UTF8_STRING, 233 = text/plain;charset=UTF-8):

request target=231 -> served
request target=233 -> refused

Additional information

Killing codex makes the problem disappear, because the desktop clipboard manager (Klipper) then takes ownership and serves a complete, consistent target list. Re-publishing the same bytes with xclip also fixes it. This all points at the clipboard backend used for X11 rather than at anything in the TUI itself.