What version of Codex CLI is running?

codex-cli 0.116.0

What subscription do you have?

Team

Which model were you using?

5.4

What platform is your computer?

Linux 5.14.0-570.62.1.el9_6.x86_64 x86_64 x86_64

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

TERM=xterm-256color, no tmux, local X11 session (XDG_SESSION_TYPE=x11, DISPLAY=:1). Terminal emulator name/version unknown. Gnome Terminal

What issue are you seeing?

On local AlmaLinux 9 X11, /copy reports Copied latest Codex output to clipboard. but the clipboard stays empty.

This is not an SSH/OSC52 case and not a broken desktop clipboard:

• xclip -selection clipboard works normally in the same shell session
• xclip -o -selection clipboard stays empty after /copy
• adding CopyQ only makes it work intermittently, which suggests a clipboard ownership race rather than a missing dependency

I reproduced this with codex-cli 0.116.0 on a local X11 session and no multiplexer.

What steps can reproduce the bug?

1. Start Codex CLI in a local Linux X11 desktop session.
2. Ask Codex for any response with recognizable text.
3. Run /copy.
4. Observe the success message: Copied latest Codex output to clipboard.
5. Paste into another application or inspect the clipboard with xclip -o -selection clipboard.

The clipboard is empty even though /copy reported success.

Control checks:

• printf 'codex-x11-test' | xclip -selection clipboard works and can be pasted correctly
• session=x11 display=:1 wayland= ssh= ssh_tty= term=xterm-256color tmux= confirms this is local X11, not SSH or tmux

What is the expected behavior?

After /copy, the latest completed Codex output should remain available in the system clipboard and be pasteable into other applications.

Additional information

Root-cause hypothesis:

• On Linux, copy_text_to_clipboard() creates arboard::Clipboard, calls set_text(...), and then returns immediately.
• On X11/Wayland, that can drop clipboard ownership before another client requests the data.
• With no clipboard manager, the clipboard stays empty.
• With CopyQ running, it only works intermittently, which is consistent with a race to capture clipboard ownership.

I tested a local patch that keeps the Linux arboard::Clipboard object alive in ChatWidget after /copy instead of dropping it immediately. That made /copy reliable on the same AlmaLinux 9 X11 session.

Patch outline:

• change copy_text_to_clipboard() to return an optional Linux-only clipboard lease
• store that lease on ChatWidget
• replace the lease on the next /copy

If this issue is useful, I can share the tested patch or open an invited PR.