codex - 💡(How to fix) Fix Ctrl+V in TUI is image-only when it reaches Codex as a key event; add symmetric text paste [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#17103Fetched 2026-04-09 08:02:23
View on GitHub
Comments
2
Participants
2
Timeline
6
Reactions
0
Author
Timeline (top)
labeled ×3commented ×2unlabeled ×1

In the TUI, Ctrl+V currently behaves as an image-paste shortcut if it reaches Codex as a key event.

That means when the clipboard contains text, and the terminal does not convert the paste into a bracketed Paste(...) event, Codex tries to paste an image instead and shows an error like:

Failed to paste image: no image on clipboard: ...

Root cause

There are currently two different paste paths:

  • text paste: relies on terminal/crossterm Event::Paste(...)
  • Ctrl+V: handled as clipboard image paste in the TUI keybinding layer

So if the terminal forwards Ctrl+V as a keypress instead of surfacing a paste event, text paste does not happen inside Codex.

Proposed behavior

  • Ctrl+V in local desktop sessions:
    • try clipboard text first
    • if non-empty text exists, route it through the existing composer paste path
    • if no text exists, fall back to image paste
  • Alt+V:
    • remain explicit image paste
  • SSH/remote sessions:
    • do not do process-local text clipboard reads
    • rely on terminal-owned paste
    • if Ctrl+V reaches Codex as a key event, show a short hint instead of reading the remote process clipboard

Why this shape

  • preserves terminal-native Paste(...) handling
  • preserves explicit image paste
  • avoids incorrect clipboard semantics in SSH sessions
  • makes Ctrl+V symmetric for local users whose terminal forwards the keypress

Local implementation + verification

I implemented this in a local clone and verified with:

  • just fmt
  • cargo clippy -p codex-tui --tests
  • cargo test -p codex-tui

The change includes:

  • text clipboard read helper
  • WSL text fallback
  • Ctrl+V text-first shortcut policy
  • Alt+V image-only policy
  • SSH hint path
  • updated footer/snapshots/tests

If this approach matches the intended direction, I can turn it into a PR if invited.

Error Message

paste an image instead and shows an error like:

Root Cause

Root cause

RAW_BUFFERClick to expand / collapse

Summary

In the TUI, Ctrl+V currently behaves as an image-paste shortcut if it reaches Codex as a key event.

That means when the clipboard contains text, and the terminal does not convert the paste into a bracketed Paste(...) event, Codex tries to paste an image instead and shows an error like:

Failed to paste image: no image on clipboard: ...

Root cause

There are currently two different paste paths:

  • text paste: relies on terminal/crossterm Event::Paste(...)
  • Ctrl+V: handled as clipboard image paste in the TUI keybinding layer

So if the terminal forwards Ctrl+V as a keypress instead of surfacing a paste event, text paste does not happen inside Codex.

Proposed behavior

  • Ctrl+V in local desktop sessions:
    • try clipboard text first
    • if non-empty text exists, route it through the existing composer paste path
    • if no text exists, fall back to image paste
  • Alt+V:
    • remain explicit image paste
  • SSH/remote sessions:
    • do not do process-local text clipboard reads
    • rely on terminal-owned paste
    • if Ctrl+V reaches Codex as a key event, show a short hint instead of reading the remote process clipboard

Why this shape

  • preserves terminal-native Paste(...) handling
  • preserves explicit image paste
  • avoids incorrect clipboard semantics in SSH sessions
  • makes Ctrl+V symmetric for local users whose terminal forwards the keypress

Local implementation + verification

I implemented this in a local clone and verified with:

  • just fmt
  • cargo clippy -p codex-tui --tests
  • cargo test -p codex-tui

The change includes:

  • text clipboard read helper
  • WSL text fallback
  • Ctrl+V text-first shortcut policy
  • Alt+V image-only policy
  • SSH hint path
  • updated footer/snapshots/tests

If this approach matches the intended direction, I can turn it into a PR if invited.

extent analysis

TL;DR

Implement a conditional paste logic for Ctrl+V to prioritize text paste over image paste when the clipboard contains text.

Guidance

  • Review the proposed behavior for Ctrl+V in local desktop sessions to ensure it aligns with the intended functionality.
  • Verify that the terminal-owned paste handling is preserved for SSH/remote sessions.
  • Test the Alt+V shortcut to confirm it remains an explicit image paste.
  • Consider implementing a fallback mechanism for cases where the clipboard contents cannot be determined.

Example

No code snippet is provided as the issue does not contain explicit code references.

Notes

The proposed solution relies on the terminal's native paste handling and aims to provide a symmetric experience for local users. However, the implementation details and potential edge cases should be carefully reviewed before proceeding.

Recommendation

Apply the proposed workaround by implementing the conditional paste logic for Ctrl+V as described, prioritizing text paste over image paste when the clipboard contains text. This approach preserves terminal-native paste handling and provides a symmetric experience for local users.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING