›_ Codex Issues
Codex Issues / #15452

/copy fails after successful output in SSH session (regression in 0.116.0)

Resolved 💬 6 comments Opened Mar 22, 2026 by Pein2017 Closed Jul 21, 2026
💡 Likely answer: A maintainer (won-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.116.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

All models

What platform is your computer?

Linux x86_64 Ubuntu

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

SSH remote session (from local machine) → Ubuntu server Terminal: bash

What issue are you seeing?

Issue: /copy fails even after successful model output

Environment:

  • Codex CLI version: 0.116.0
  • OS: Ubuntu (remote)
  • Access method: SSH into remote machine
  • Terminal: (fill in if known, e.g. bash / zsh / tmux)

Reproduction steps:

  1. Start a fresh Codex CLI session
  2. Enter a simple prompt: hi
  3. Wait until the model output fully completes and CLI is idle
  4. Run /copy

Expected behavior:

  • /copy should copy the latest completed model output

Actual behavior:

  • Error message:

/copy is unavailable before the first Codex output or right after a rollback

Notes:

  • The model output is clearly visible and completed before running /copy
  • No rollback or undo actions were performed
  • This worked correctly in earlier Codex CLI versions (regression)
  • Issue is reproducible consistently

Additional context:

  • Running entirely in a remote SSH session (no local GUI clipboard)
  • Unsure if related to TUI state sync or SSH environment handling

What steps can reproduce the bug?

Uploaded thread: 019d15a0-162b-78b1-8610-7ea7469cfd26

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

6 Comments

won-openai contributor · 5 months ago

Does it happen only for the first turn of messages? or does /copy not work in general?

haha505254 · 5 months ago

I am experiencing the exact same issue on the newer version.

Environment:

Codex App Version: v0.117.0

Model: gpt-5.3 codex xhigh (Plus subscription)

Platform: Windows 11 running WSL (Ubuntu)

Like the OP, the error /copy is unavailable before the first Codex output or right after a rollback appears every time I try to use /copy after a generated response. It seems the CLI is failing to access the system clipboard properly in headless/subsystem environments like SSH and WSL.

no1x0 · 5 months ago

I am also on a Plus subscription using version v0.117.0, and I am experiencing the exact same /copy issue. The previous version was working perfectly fine for me.

Note: I am not using SSH, WSL, or any remote/headless environment. I am running the CLI directly on my local machine. The /copy command was working initially on this version as well, but then it suddenly started failing with this error.

My Environment:

  • Subscription: Plus
  • Kernel: Linux 6.12.74+deb13+1-amd64 x86_64
  • Codex App Version: v0.117.0
etraut-openai contributor · 5 months ago

@no1x0, it sounds like you might be seeing a different issue. You mentioned that it was previously working for you in 0.116.0. Can you confirm by downgrading? If that's the case, then it's likely that you're seeing a regression. The OP is not reporting a regression but rather a limitation in the current implementation. If you're seeing a regression, please open a new bug so we can track and prioritize it as such.

Boulea7 · 5 months ago

I dug through the current TUI /copy path. I haven't reproduced this end-to-end locally because my local Cargo setup is currently blocked by unrelated mirror/dependency resolution issues, so this is source inspection only.

What looks important is that /copy fails before it ever reaches the SSH / OSC52 clipboard backend if last_copyable_output is None. That cache is updated from completed plan output and, for normal assistant replies, mainly from TurnComplete.last_agent_message.

There are also existing TUI tests covering the case where assistant text was already rendered, but TurnComplete.last_agent_message is still None. In that case, /copy is expected to show the same "unavailable before the first Codex output..." message.

So my current read is that this is probably upstream of the SSH clipboard layer. A visible reply can exist in the transcript while the "latest copyable output" cache is still empty. If 0.116 changed some turn-completion path so the final visible reply is no longer propagated into TurnComplete.last_agent_message, that would fit this symptom pretty well.

So this looks more like a copy-state / final-message propagation regression than an OSC52-specific failure.

etraut-openai contributor · 1 month ago

Merged PR #16966 addresses this. If you're still seeing related problems, please open a new bug report with repro steps.