CLI /copy reports success but writes to devcontainer’s virtual X11 clipboard instead of VS Code host clipboard

What version of Codex CLI is running?

codex-cli 0.144.6

What subscription do you have?

Pro

Which model were you using?

_No response_

What platform is your computer?

_No response_

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

_No response_

Codex doctor report

What issue are you seeing?

Problem

Both /copy and Ctrl+O display:

Copied last message to clipboard

However, pasting into VS Code or another host application shows that the host clipboard was not updated. No error is reported.

Claude Code, running in the exact same dev container and VS Code terminal, copies responses to the host clipboard successfully. This demonstrates that the terminal has a working host-clipboard path.

Environment

Codex CLI is running in the VS Code integrated terminal inside a dev container.

TERM_PROGRAM=vscode
TERM=xterm-256color
REMOTE_CONTAINERS=true
DISPLAY=:1
WAYLAND_DISPLAY=<unset>
SSH_CONNECTION=<unset>
SSH_TTY=<unset>
TMUX=<unset>
Linux 6.12.76-linuxkit aarch64

DISPLAY=:1 is reachable, but it belongs to a separate virtual X11/Blackbox desktop rather than the VS Code host desktop.

Expected behavior

The latest Codex response should be placed on the clipboard of the machine running VS Code.

Alternatively, Codex should report that it copied only to the container’s X11 clipboard rather than reporting unconditional success.

Actual behavior

Codex reports success, but the text is written to the virtual X11 clipboard inside the container. The VS Code host clipboard remains unchanged.

Suspected cause

The current clipboard selection logic treats this as a local Linux session because neither SSH_TTY nor SSH_CONNECTION is set.

For local sessions, Codex tries arboard before OSC 52:

https://github.com/openai/codex/blob/rust-v0.144.6/codex-rs/tui/src/clipboard_copy.rs#L94-L124

Because arboard can successfully connect to DISPLAY=:1, it returns success and Codex never sends the OSC 52 sequence that would reach the VS Code terminal’s host clipboard.

The environment provides both REMOTE_CONTAINERS=true and TERM_PROGRAM=vscode, but these are not considered when selecting the clipboard backend.

Workaround

Starting Codex without the virtual display variables forces the OSC 52 fallback:

env -u DISPLAY -u WAYLAND_DISPLAY codex resume --last

This is inconvenient because commands spawned by Codex may legitimately need access to the container’s virtual display.

Suggested fix

One or more of the following would resolve this:

• Prefer terminal-mediated OSC 52 when running under VS Code Remote Containers.
• Consider REMOTE_CONTAINERS=true when selecting the clipboard backend.
• Add an explicit clipboard backend setting such as auto, native, or osc52.
• Allow an environment variable to force OSC 52 without removing DISPLAY from Codex-spawned commands.

Related issues

• #12836 covers /copy failures in WSL, SSH, and VS Code dev containers, but primarily where native clipboard access fails outright.
• #15663 covered false success on local X11 due to clipboard ownership lifetime; that issue is closed and has a different cause.
• #25465 covers the host/container clipboard boundary for clipboard reads, but explicitly excludes the write direction.

This case is the remaining false-success path where native X11 access technically succeeds, but targets the wrong clipboard and therefore suppresses the working OSC 52 fallback.

What steps can reproduce the bug?

1. Open a VS Code integrated terminal attached to a dev container.
2. Ensure the container has a reachable virtual X11 display such as DISPLAY=:1.
3. Start Codex CLI.
4. Ask Codex for a recognizable response.
5. Run /copy or press Ctrl+O.
6. Paste into VS Code or another host application.

What is the expected behavior?

The latest Codex response should be placed on the clipboard of the machine running VS Code.

Alternatively, Codex should report that it copied only to the container’s X11 clipboard rather than reporting unconditional success.

Additional information

_No response_