[Windows] Pasting files from Explorer freezes Codex for 5-7 seconds; drag-and-drop is instant

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex 26.818.5229.0 (x64 MSIX); embedded Chromium 151.0.7922.170

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 25H2, build 26200.9168)

What issue are you seeing?

On Codex for Windows, pressing Ctrl+V after copying a file in File Explorer blocks the Codex renderer for roughly 5-7 seconds before the attachment appears. Dragging the exact same file into the same composer is immediate.

In the current installation, clipboard screenshots/images paste immediately; the remaining reproducible problem is specific to files copied by Explorer (CF_HDROP). The problem may be absent during the first few seconds after launching Codex, then becomes reproducible after the app has finished starting.

This reproduced with tiny local text files, so it is not explained by source-file size or network upload time. The visible stall happens before the attachment is materialized in the composer.

What steps can reproduce the bug?

1. Start Codex for Windows and open any task.
2. In File Explorer, copy any small local file, for example a tiny .txt file.
3. Focus the Codex composer and press Ctrl+V.
4. Observe that Codex becomes non-interactive for roughly 5-7 seconds before the attachment appears.
5. Remove or disregard the attachment.
6. Drag the exact same file from File Explorer into the same composer.
7. Observe that drag-and-drop attaches it immediately.

The result is unchanged after exiting clipboard-manager and file-sync applications, switching to Microsoft IME, restarting Codex, or launching Codex as administrator.

What is the expected behavior?

Pasting a copied file should attach it immediately, with latency comparable to dragging the same file into the composer. The renderer should remain responsive while the Windows clipboard payload is processed.

Additional information

Diagnostic controls

• Windows OLE/FileDrop extraction completed in under 60 ms; each individual clipboard format tested completed in under 9 ms.
• A minimal synthetic CF_HDROP payload containing only FileDrop, FileNameW, and FileName also reproduced the delay.
• The same copied file pasted immediately into a simple test page in Chrome.
• Codex path retrieval and the DOM paste handler completed in under 1 ms after the paste event arrived.
• During the stall, one Codex renderer consumed roughly one logical CPU core.
• CPU profiling placed the unexplained time before the DOM paste event, in the native Chromium/Electron clipboard path rather than the app's attachment handler.
• The issue reproduced in both 26.818.3698.0 and 26.818.5229.0.

These controls do not support Node.js installation, filesystem access, current elevation, source-file size, clipboard extraction latency, the input method, or the app's JavaScript attachment handler as the primary cause.

Workaround A/B result

Launching Codex with:

--disable-renderer-accessibility

removed most of the delay, but was not consistently instant. Launching with:

--disable-renderer-accessibility --disable-features=NonBlockingOsClipboardReads,PlatformClipboardMonitor

made repeated file-paste tests immediate.

This does not identify which of the two clipboard feature switches is individually necessary; they were tested together. The first switch also has an important accessibility tradeoff because it can affect screen readers and UI Automation, so this is only a temporary diagnostic workaround, not a suitable product fix.

Related issue and historical behavior

This appears related to #25997, which reports slow image clipboard paste with fast drag-and-drop. The current reproduction is distinct: screenshot/image paste is immediate, while Explorer file paste remains slow.

Before a reinstall, both screenshot paste and file paste could stall, and launching as administrator happened to avoid both. In the current installation, administrator launch no longer changes file-paste latency. This may indicate an earlier elevation-sensitive failure mode in addition to the current file-only path.

Raw traces are not attached because they can contain local paths and machine-specific metadata. No personal files, file contents, conversation text, usernames, or local paths are included in this report. Sanitized measurements can be provided if maintainers need them.