Proposed fix: add native Windows bitmap clipboard fallback

Open 💬 0 comments Opened Jul 12, 2026 by JoNil-Botta

Summary

Native Windows Codex can fail to read clipboard images that are exposed through classic bitmap formats. The existing arboard path reports that no requested image format is available even though Windows applications and screenshot tools have placed an image on the clipboard.

The proposed fix:

  • keeps arboard as the first-choice image provider
  • falls back to clipboard-win's CF_BITMAP reader on Windows
  • decodes the complete BMP byte stream and feeds it through Codex's existing PNG attachment flow
  • uses checked width and height conversions in the existing RGBA path

Addresses #15612.

Proposed patch

The change is intentionally independent of the Windows terminal-input fix so it can be reviewed or declined separately.

Validation

  • cargo +1.95.0 check --locked -p codex-tui
  • just test -p codex-tui decodes_windows_bitmap_clipboard_payload: 1 passed
  • just test -p codex-tui: 3007 passed; 3 existing Windows home-path assertion failures unrelated to clipboard code
  • just bazel-lock-update
  • just fix -p codex-tui
  • just fmt
  • live native-Windows image attachment confirmed with Alt+V

The live check confirms the clipboard-to-attachment flow, but it was not instrumented to identify which provider succeeded. The added unit test directly covers BMP payload decoding; this report does not claim that the live attempt specifically exercised the fallback.

View original on GitHub ↗