tui: Markdown table rendering clones body cells and wrapped hyperlink lines

Start in codex-rs/tui/src/markdown_render.rs, reading render_table_lines, render_table_row, wrap_cell, TableCell, and TableState. Trace the cited clones and measure the current rendering path before evaluating an ownership flow that preserves rendered output and hyperlink ranges while reducing avoidable copies.

What variant of Codex are you using?

CLI

What feature would you like to see?

I found a potential performance concern in the current TUI source, rather than a confirmed user-visible bug. Please consider a behavior-preserving ownership flow for Markdown table rendering that avoids copying rich table data when the renderer already owns it.

Additional information

Evidence

• TableCell owns Vec<HyperlinkLine> and derives Clone; TableState owns its body rows.
• render_table_lines takes TableState by value, but it iterates the owned state's rows and uses row.cells.clone() for every retained body row; its spillover path also uses first().cloned(). Thus rich cells, their lines, spans, and annotations are copied before layout.
• render_table_row then builds wrapped cells, clones the selected HyperlinkLine for each rendered row line, and clones each selected hyperlink while constructing the output. wrap_cell establishes the wrapped-line collection that this stage reads.
• Repetition is realistic rather than hypothetical: the table design intentionally keeps an in-progress table as a mutable tail because new rows can change column widths, and finalized source-backed tables re-render on width changes (#22052). The later streaming optimization retains this canonical full-render path when required (#34045).

Impact

Not measured. The unknown is allocation volume and rendering latency per table render. The source-proven copies scale with retained body cells, rich spans and hyperlink annotations, generated wrapped lines, and the number of renders. Multi-row tables with links or hard breaks are realistic inputs; a table that grows during streaming or is reflowed at a new width can repeat the work. This report does not claim observed stutter or a measured regression.

Question

Would it make sense to revise the table-rendering ownership flow so retained non-spillover rows and freshly wrapped cells can be consumed where possible while preserving rendered output and hyperlink ranges?

I checked all relevant issues, comments, pull requests, discussions, and release notes; this report is not a duplicate.

I am reporting this finding only and am not proposing a pull request unless a maintainer invites one.

Disclosure

Investigated thoroughly with GPT-5.6 Sol (runtime-default reasoning effort), using Oh My Pi as the agent framework.

This report is not generic or unreviewed AI-generated output. Its claims were checked against the cited evidence, and it includes the relevant detail intended to help maintainers resolve the issue.

If reports like this are not useful to the project, please let me know and I will refrain from submitting similar ones. My intent is to help without wasting maintainer time or energy or discouraging their work.

Thank you for your work.