/copy copies an older response instead of the most recent one

Resolved 💬 3 comments Opened Apr 1, 2026 by abaidalgarni Closed Apr 5, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Description

/copy copies a stale assistant response instead of the latest one in a multi-turn conversation.

Expected behavior

When I run /copy, it should copy the most recent assistant response in the current conversation.

Actual behavior

It copies an older assistant response instead of the latest one.

Steps to reproduce

Have a conversation with multiple assistant responses (at least 3–4 turns).
The most recent response should be a long response (e.g., an audit/review).
Run /copy.
Paste clipboard contents — observe it contains an earlier response, not the latest.

Example

Most recent response started with: "I'm reviewing the Claude sandbox against the current ..."
But /copy copied an older response: "## Block 4 Sandbox Package ..."

Frequency

Always (100% reproducible in my environment).

Environment

Product: Codex CLI
Terminal: iTerm2
OS: macOS (latest update)
Timestamp: 2026-04-01, Asia/Riyadh timezone

Notes

This is distinct from #16019 (where /copy fails entirely) and #15452 (SSH-specific failure). Here /copy succeeds but returns the wrong message.

View original on GitHub ↗

3 Comments

EmmrisScott1 · 4 months ago

That's a good idea

etraut-openai contributor · 4 months ago

Which version of the CLI are you using? Is it 0.118.0?

Also, do you have reason to think that this is a recent regression? Did you see this behavior with previous versions (in particular, prior to 0.117.0)?

etraut-openai contributor · 4 months ago

Thanks for the bug fix. This will be addressed in the next release.