Add exact per-code-block copy actions to Codex CLI responses

What variant of Codex are you using?

CLI

What feature would you like to see?

Problem

When an assistant response contains a fenced Markdown code block, Codex CLI renders it with syntax highlighting, prefixes, padding, and terminal-width wrapping. At that point the terminal no longer knows where the original Markdown block began or ended.

As a result, selecting a rendered command can include TUI indentation, prefixes, or newlines introduced only by visual wrapping. The current workarounds are to enter /raw, clean up the selection manually, or use /copy / Ctrl+O and extract one block from the entire Markdown response.

/copy solves whole-message export, but not the common action: “copy this one code block exactly”.

Requested behavior

Please expose a copy action for each fenced code block in assistant responses.

The copied value should:

• exclude the opening and closing fences and the language info string;
• preserve intentional indentation and explicit newlines;
• exclude TUI prefixes, padding, borders, and soft-wrap newlines;
• work when a response contains multiple code blocks;
• provide brief confirmation that the block was copied.

Proposed UX

A progressive UX could provide:

1. An inline copy button in terminal emulators that support clickable code-block controls.
2. A portable /copy-block command and keymap action for every terminal.
3. When multiple blocks are present, a picker labeled by language and first line.
4. When only one block is present, /copy-block could copy it immediately.
5. The existing /copy behavior should remain unchanged for copying the whole response.

The copy operation should use the original Markdown source, not scrape the rendered terminal cells.

Additional information

Technical feasibility

Codex already retains the raw assistant Markdown in AgentMarkdownCell::markdown_source and re-renders it for the current terminal width:

https://github.com/openai/codex/blob/main/codex-rs/tui/src/history_cell.rs

Codex also already has a clipboard backend used by /copy and Ctrl+O, including local clipboard, SSH, tmux, and OSC 52 handling:

https://github.com/openai/codex/blob/main/codex-rs/tui/src/clipboard_copy.rs

https://github.com/openai/codex/blob/main/codex-rs/tui/tooltips.txt

This means fenced blocks can be parsed from the source-backed message and copied through the existing clipboard path without reconstructing them from rendered cells.

Optional iTerm2 progressive enhancement

iTerm2 3.6.9 and later supports native code-block regions and copy/custom buttons through OSC 1337:

• OSC 1337;Block=id=...;attr=start|end
• OSC 1337;Button=type=copy;block=...
• OSC 1337;Button=type=custom;code=...;icon=...

Documentation:

https://iterm2.com/documentation-escape-codes.html#blocks

A custom button may be preferable for exact-copy semantics: clicking it could send an event back to Codex, after which Codex copies the corresponding raw block through its existing clipboard backend. This avoids copying visual padding or soft wraps.

This should be feature-detected and treated as an optional enhancement. Unsupported terminals, SSH/tmux environments without passthrough, and keyboard-only users should retain the /copy-block fallback.

The implementation should not require global mouse capture, since preserving native terminal scrolling and text selection is important.

Suggested acceptance criteria

• Copies the logical source content of an individual fenced block.
• Does not copy fence delimiters, language tags, TUI decoration, or soft wraps.
• Supports multiple blocks in one response.
• Has a keyboard-accessible fallback on all supported terminals.
• Does not change native scrolling or selection behavior.
• Continues to work through the existing local/SSH/tmux clipboard strategy.
• Unsupported terminals receive no unknown proprietary escape sequences.

Related issues

This request is intentionally narrower than the existing copy/export requests:

• #2880 covers copying or exporting an entire message as Markdown.
• #1247 covers general mouse selection and copy/paste behavior.
• #1500 covers TUI borders and decoration entering manual selections.
• #1246 covers Markdown rendering generally.
• #8344 discusses preserving native terminal scrolling, selection, and copy behavior.

I could not find an existing issue specifically scoped to exact per-code-block copy actions or iTerm2 OSC 1337 Block/Button integration.

I understand that external contributions are by invitation only. I am happy to provide testing and implementation analysis, and to prepare a focused PR if the maintainers decide this direction fits the roadmap and invite one.