`/copy fails in long resumed CLI session but works in fresh session on same SSH/OSC52 path`

What version of Codex CLI is running?

codex-cli 0.154.0

What subscription do you have?

ChatGPT Pro Lite

Which model were you using?

gpt-5.6-sol medium

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

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

Linux 4.18.0-513.11.1.el8_9.x86_64 x86_64 x86_64, Windows PowerShell: 5.1.19041.7725,Terminal topology: VS Code integrated terminal on Windows PowerShell-origin terminal SSH from that terminal to the RHEL workstation Codex CLI executes on the remote RHEL host No tmux, screen, or zellij

Codex doctor report

### Codex doctor

`codex doctor --json` was run directly at the remote RHEL host shell,
outside the Codex execution sandbox.

Result:
{
  "schemaVersion": 1,
  "generatedAt": "1789070994s since unix epoch",
  "overallStatus": "ok",
  "codexVersion": "0.154.0",
  "checks": {
    "app_server.status": {
      "id": "app_server.status",
      "category": "app-server",
      "status": "ok",
      "summary": "background server is not running",
      "details": {
        "control socket": "/home/<user>/.codex/app-server-control/app-server-control.sock",
        "daemon state dir": "/home/<user>/.codex/app-server-daemon",
        "mode": "ephemeral",
        "pid file": "/home/<user>/.codex/app-server-daemon/app-server.pid (missing)",
        "settings": "/home/<user>/.codex/app-server-daemon/settings.json (missing)",
        "status": "not running",
        "update-loop pid file": "/home/<user>/.codex/app-server-daemon/app-server-updater.pid (missing)"
      },
      "remediation": null,
      "durationMs": 0
    },
    "auth.credentials": {
      "id": "auth.credentials",
      "category": "auth",
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "auth file": "/home/<user>/.codex/auth.json",
        "auth storage mode": "File",
        "stored API key": "false",
        "stored ChatGPT tokens": "true",
        "stored agent identity": "false",
        "stored auth mode": "chatgpt"
      },
      "remediation": null,
      "durationMs": 0
    },
    "config.load": {
      "id": "config.load",
      "category": "config",
      "status": "ok",
      "summary": "config loaded",
      "details": {
        "CODEX_HOME": "/home/<user>/.codex",
        "active thread overrides": "not inspected",
        "config.toml": "/home/<user>/.codex/config.toml",
        "config.toml parse": "ok",
        "configuration load ms": "17",
        "configuration scope": "invocation config, including cloud-managed policy"
      }
    }
  }
}


OVERALL_STATUS=ok
CODEX_VERSION=0.154.0
PROVIDER_REACHABILITY=ok
WEBSOCKET_REACHABILITY=ok
UPDATE_STATUS=ok
AUTH=ok
CONFIG=ok
INSTALLATION=ok
STATE_DATABASES=ok

What issue are you seeing?

/copy fails to update the local Windows clipboard correctly in a long,
resumed Codex CLI conversation, while /copy works correctly in a fresh
conversation using the same Codex binary, terminal, SSH connection, remote
host, and OSC 52 clipboard path.

Environment:

• Codex CLI: 0.154.0
• Model: gpt-5.6-sol, medium reasoning
• Client: Windows 10 x64
• Terminal: VS Code integrated terminal
• Terminal originated as Windows PowerShell, then SSH was used to connect to
  a RHEL Linux workstation
• Codex CLI executes on the remote RHEL host
• Remote kernel: Linux 4.18.0-513.11.1.el8_9.x86_64
• SSH_CONNECTION and SSH_TTY are present
• DISPLAY and WAYLAND_DISPLAY are empty
• TMUX and TMUX_PANE are empty
• No tmux, screen, or zellij

The affected conversation is unusually long, approximately 208K tokens used
of a 258K context window, and has been resumed multiple times.

Failing case

In the long-running conversation, Codex produces a completed assistant
response. Running:

/copy

reports success, for example:

Copied Whole response to clipboard

However, the Windows clipboard does not contain the current assistant
response. In controlled testing, the clipboard retained content that had
already been copied before /copy was executed.

Restarting Codex and reopening the same conversation with:

codex resume --last

did not correct the problem.

Passing control

Without changing the Codex version, VS Code window, terminal, SSH connection,
RHEL host, or Windows clipboard path, I started a new Codex conversation with:

codex

I then used this prompt:

Reply with exactly this single line and nothing else:

CODEX-FRESH-COPY-TEST-20260910

Codex responded:

CODEX-FRESH-COPY-TEST-20260910

I placed a different known sentinel value in the Windows clipboard and then
ran:

/copy

Codex reported:

Copied Whole response to clipboard

Pasting into Windows Notepad produced exactly:

CODEX-FRESH-COPY-TEST-20260910

Result:

• Fresh conversation: /copy PASS
• Long resumed conversation: /copy FAIL

Independent clipboard transport test

I independently emitted a small OSC 52 clipboard payload from the same remote
SSH shell. It successfully replaced the Windows clipboard.

Manual VS Code terminal-selection copy also works correctly.

Therefore these paths were independently verified:

• SSH transport: PASS
• OSC 52 remote-to-local clipboard: PASS
• VS Code OSC 52 handling: PASS
• Windows clipboard: PASS
• Manual terminal-selection copy: PASS
• Fresh-session Codex /copy: PASS
• Long/resumed-session Codex /copy: FAIL

A direct host-level codex doctor --json reports overall status ok,
including authentication, configuration, installation, provider reachability,
WebSocket reachability, update status, and state databases.

This appears to isolate the defect to long/resumed conversation state or
transcript replay/copy-source state rather than the underlying SSH/OSC 52
clipboard transport.

Separate /export observation

In the same long conversation, copying a full /export to the clipboard
fails explicitly with:

OSC 52 clipboard copy failed over SSH: OSC 52 payload too large (3128329 bytes; max 100000)

This appears to be an expected size-limit condition and is included only to
distinguish it from the /copy defect.

What steps can reproduce the bug?

Affected thread ID:

01a081f7-0bd9-7c90-8ce5-ce02e8de07e1

The affected thread is a long-lived conversation using approximately 208K of
a 258K context window at the time of testing.

Reproduction — failing resumed thread

1. Start from a shell on the remote Linux host and resume the affected
   conversation:

codex resume --last

Allow Codex to restore the long conversation and produce or display a
completed assistant response.
Put a known sentinel value into the local Windows clipboard, for example:
PRE-COPY-SENTINEL
In Codex, run:
/copy
Codex reports success, for example:
Copied Whole response to clipboard
Paste the Windows clipboard into Notepad or another local application.

Observed result:

The clipboard does not contain the latest assistant response. In repeated
tests it retained content that was already in the clipboard before /copy
was executed.

Restarting Codex and again using:

codex resume --last

does not correct the problem.

Control — fresh thread passes

Using the same Codex 0.154.0 binary, VS Code terminal, SSH connection, Linux
host, and Windows clipboard path, start a new conversation:

codex

Send this prompt:

Reply with exactly this single line and nothing else:

CODEX-FRESH-COPY-TEST-20260910

Codex responds:

CODEX-FRESH-COPY-TEST-20260910

Put a different sentinel value into the Windows clipboard, then run:

/copy

Codex reports:

Copied Whole response to clipboard



### What is the expected behavior?

Paste into Windows Notepad.

Observed result:

CODEX-FRESH-COPY-TEST-20260910

Therefore, under the same host/terminal/SSH/OSC52 environment:

Fresh conversation:        /copy PASS
Long resumed conversation: /copy FAIL

OSC 52 transport control

A small OSC 52 payload was also emitted directly from the same remote SSH
shell and successfully replaced the local Windows clipboard.

This independently verifies that SSH transport, OSC 52 forwarding, VS Code
terminal handling, and the Windows clipboard are functional.

A direct host-level:

codex doctor --json

also returns overall status ok, including state databases, authentication,
configuration, provider reachability, WebSocket reachability, installation,
and update status.


Because the GitHub issue is public, the **thread ID is the one piece I would consider optional**. OpenAI's form explicitly requests it, so including it may help them inspect server-side/session metadata. If you prefer not to publish that identifier, replace the first two lines with:

```text
Affected thread ID: available to OpenAI maintainers on request.

Everything else above is already sanitized and directly reflects our controlled reproduction.

### Additional information


### Related issues

This appears related to, but is not an exact duplicate of:

- #16454 — `/copy` copies an older response instead of the most recent one.
  That report describes stale copy-source behavior in a multi-turn conversation.
  My reproduction differs because the failure is isolated specifically to a
  long/resumed thread: `/copy` fails there while a fresh thread passes using
  the same Codex binary, terminal, SSH connection, remote host, OSC 52 path,
  and Windows clipboard.

- #32551 — `/copy` may use a previous completed assistant response in a TUI
  state where the current response is truncated/incomplete.
  My case does not require observed TUI truncation and remains reproducible
  after restarting Codex and resuming the long thread.

Start with the /copy command and the response-selection state used after codex resume --last; reproduce the issue with the supplied long thread and compare it with a fresh codex session. The fix is complete when /copy places the latest assistant response in the Windows clipboard for the resumed thread, while the existing OSC 52 size-limit behavior remains distinct.