Regression: /copy fails in 0.117.0 after first Codex output in a normal session

Resolved 💬 3 comments Opened Mar 27, 2026 by no1x0 Closed Mar 28, 2026

What version of Codex CLI is running?

codex-cli 0.117.0

What subscription do you have?

Plus

Which model were you using?

all

What platform is your computer?

Linux 6.12.74+deb13+1-amd64 x86_64 unknown

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

Terminator 2.1.4 (TERM=xterm-256color)

What issue are you seeing?

/copy fails in Codex CLI 0.117.0 with the following error:

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

However, I am running /copy after Codex has already produced output, and I am not doing it immediately after a rollback.

I downgraded to 0.116.0 and tested the same workflow on the same machine. In 0.116.0, /copy works correctly. After upgrading back to 0.117.0, the error returns.

Because 0.116.0 works and 0.117.0 does not, this looks like a regression rather than the currently documented limitation

<img width="756" height="291" alt="Image" src="https://github.com/user-attachments/assets/449a6db7-4a07-4124-a48e-b76772044107" />

What steps can reproduce the bug?

  1. Install and run Codex CLI 0.117.0
  2. Start a fresh Codex session
  3. Send any prompt and wait for the first Codex response
  4. Do not rollback
  5. Run /copy

Result:

  • Codex shows: /copy is unavailable before the first Codex output or right after a rollback`

Control test:

  1. Downgrade to 0.116.0
  2. Repeat the exact same steps on the same machine
  3. /copy works normally

Upgrade test:

  1. Upgrade back to 0.117.0
  2. Repeat the same steps again
  3. The error appears again

I do not have a thread id to share for this reproduction because it happens in a fresh normal session.

What is the expected behavior?

/copy should copy the last Codex message after the first Codex output has been produced in a normal session.

It should not show the "before the first Codex output or right after a rollback" error unless the command is actually being used in one of those two situations.

Additional information

  • Last known working version: 0.116.0
  • Broken version: 0.117.0
  • Subscription: Plus
  • Model: reproduced with all models
  • Platform: Linux 6.12.74+deb13+1-amd64 x86_64 unknown

I originally commented on another issue, but was advised to open a separate bug if this was a regression. Based on downgrade/upgrade testing, this appears to be a regression.

Additional note: 0.117.0 did not fail immediately after upgrade. /copy worked for me at first, then later started failing. Downgrading to 0.116.0 fixed it, and upgrading back to 0.117.0 brought the issue back.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗