fix(docs): `/copy` docs say it copies the latest output immediately, but it opens a block selection first

Il testo errato si trova nella sezione /copy, nella riga della tabella dei comandi slash e nel suggerimento da tastiera della pagina della documentazione dei comandi per sviluppatori, non nel codice sorgente Rust. Leggi codex-rs/tui/src/chatwidget/copy_picker.rs e codex-rs/tui/src/chatwidget/slash_dispatch.rs per confermare il comportamento del selettore e della modalità di copia della trascrizione, poi verifica i test indicati nella issue. È completato quando la documentazione descrive il passaggio di selezione (la modalità di copia della trascrizione nella vista a schermo intero predefinita e il selettore in modalità inline) e mantiene Ctrl+O come copia diretta dell'intera risposta.

Documentation issue type

Documentation is incorrect, Documentation is missing

Where did you find it?

https://learn.chatgpt.com/docs/developer-commands.md?surface=cli, section "Copy the latest response with /copy" (lines 617-628 of the Markdown page), the /copy row of the slash-command table (line 378), and the keyboard tip at line 326. The same text appears in the aggregate https://learn.chatgpt.com/docs/codex-manual.md (lines 17547, 20492 and 20728).

Summary

The CLI slash-command reference says that typing /copy and pressing Enter copies the latest completed Codex output to the clipboard. In the shipped TUI, /copy copies nothing at first. It opens a selection, and the user then chooses the whole response or one block of it. The default full-screen transcript in 0.162.0 enters an in-transcript copy mode, and inline mode and earlier releases open a "Copy to clipboard" picker. The page mentions neither, so its stated result is wrong in both modes. Ctrl+O still copies the whole response directly, as the page says.

Steps to reproduce

1. Read the /copy section of the page above.
2. Inspect the SlashCommand::Copy arm in codex-rs/tui/src/chatwidget/slash_dispatch.rs, which calls show_copy_picker(), and codex-rs/tui/src/chatwidget/copy_picker.rs at the release tag under Runtime or environment. This assumes no /status output is pending, because after /status both paths offer status fields instead.
   • If the TUI owns the transcript, show_copy_picker sends AppEvent::SelectTranscriptCopy. The app then calls transcript_view.begin_copy_mode. With the defaults (tui.fullscreen_transcript = true and tui.alternate_screen = "auto"), the TUI owns the transcript, except in Terminal.app over SSH.
   • Otherwise it opens a selection view titled "Copy to clipboard", which lists "Whole response" and each code block and blockquote.
   • In both cases nothing is copied until the user confirms a choice.
3. Not executed for this report: in an interactive 0.162.0 session with default settings, wait for a completed response that contains a fenced sh code block, then type /copy and press Enter. Per the source and the upstream tests named under Evidence, the transcript enters copy mode with the latest response selected as "Whole response". Up and Down (or j and k) move between blocks, and Enter or the copy key copies the selection. With --no-alt-screen, tui.alternate_screen = "never" or tui.fullscreen_transcript = false, or on 0.160.1 or 0.161.0, the same steps open the "Copy to clipboard" picker. There, pressing 1 copies the whole response and 2 copies the code block.

Expected behavior

The page should describe what the shipped /copy does. It opens a selection of the latest response, either as transcript copy mode in the default full-screen transcript or as a picker in inline mode. The user then copies the whole response or one of its blocks. The page should also say that Ctrl+O copies the whole response without a selection step.

Actual behavior

The page says: "Type /copy and press Enter. Expected: Codex copies the latest completed Codex output to your clipboard." The table row says "Copy the latest completed Codex output", and line 326 says "Press Ctrl+O or run /copy to copy the latest completed Codex output". The page does not mention a selection step or partial copies. In every build checked, /copy opens a selection instead of copying. From 0.162.0 on, the default full-screen transcript uses in-transcript copy mode. The picker remains for inline mode and is the only path in 0.160.1 and 0.161.0. The slash popup describes the command as "copy the last response or part of it". The 0.162.0 release notes announce "Navigate and copy transcript blocks with /copy".

Evidence

• Expected source: shipped TUI behavior at rust-v0.162.0. The relevant files are codex-rs/tui/src/slash_command.rs line 108 (popup description), codex-rs/tui/src/chatwidget/copy_picker.rs (the owned-transcript handoff and the picker), codex-rs/tui/src/transcript_mode.rs, and codex-rs/tui/src/transcript_view/copy_mode.rs. The default for tui.fullscreen_transcript is in codex-rs/config/src/types.rs. Upstream tests cover both paths. owned_copy_opens_transcript_selection in codex-rs/tui/src/chatwidget/tests/copy_export_picker_tests.rs covers the owned mode. slash_copy_picker_uses_completed_commentary_during_active_turn and slash_copy_state_tracks_plan_item_completion in codex-rs/tui/src/chatwidget/tests/slash_commands.rs cover the inline picker; they force terminal transcript mode and assert that the popup lists "Whole response" and "sh code".
• Failure source: the /copy section, table row and keyboard tip of the developer commands page, quoted under Actual behavior.
• Evidence provenance: static
• Local verification: static-proof
• Reproduction completeness: complete

Runtime reproduction was not run, because a completed response requires a signed-in model turn and this check used no credentials or model turns. The static proof covers several points: the supported entry point (typing /copy in the composer), the dispatch to show_copy_picker, the condition that selects transcript copy mode or the picker, the defaults that make transcript copy mode the usual 0.162.0 path, and the upstream tests for each path. The Ctrl+O path (prepare_last_response_copy in codex-rs/tui/src/chatwidget/interaction.rs) copies the whole response directly, consistent with the page's Ctrl+O sentence.

Restoration check

Today the page says that /copy followed by Enter copies the latest output and mentions no selection step. The fix restores agreement when the /copy section, the table row and the keyboard tip describe the selection step for the default full-screen transcript. Its whole-response and block choices must be included, and so must the inline-mode picker. A page that describes only the inline picker would still misstate the default 0.162.0 behavior. Ctrl+O should remain documented as the direct whole-response copy.

Runtime or environment

• Documentation pages fetched on 2026-10-08 (Pacific time).
• Source checked at tags rust-v0.160.1, rust-v0.161.0 and rust-v0.162.0 (the latest stable release when checked), and at main commit c9e0fffbbc05c36478686444f6ab1edbadfe2768. The owned-transcript copy mode handoff is present in 0.162.0 and main but not in 0.160.1 or 0.161.0.

Triage assessment

• Impact level: P3
• Assessment status: supported
• Impact basis: The defect is wording in reference documentation. A reader who follows the page gets a selection step instead of an immediate copy and needs one more keypress. No data is lost and no workflow is blocked.
• Workaround status: available
• Workaround basis: Ctrl+O copies the whole latest response directly in both transcript modes. Without pending /status output, both selections start on the latest whole response, so pressing Enter (or 1 in the picker) copies it.