Codex desktop terminal keyboard paste inserts text twice on Windows

I already tried the following, but the issue still happens:

• Rebooted Windows.
• Reinstalled Codex.
• Tested Codex chat input: paste works normally.
• Tested external terminals: paste works normally.
• Tested right-click paste in Codex terminal: works normally.
• Tested Ctrl+V, Ctrl+Shift+V, and Shift+Insert in Codex terminal: all paste twice.
• Tested PowerShell/PSReadLine-related troubleshooting.
• Disabled Windows clipboard history.
• Ran Codex as administrator.
• Checked for keyboard/clipboard helper apps, but none appear to be installed or running.
• Reset Codex/OpenAI local app data by renaming:
• C:\Users\8to93\AppData\Local\OpenAI
• C:\Users\8to93\AppData\Local\Codex, if present
• C:\Users\8to93\AppData\Roaming\Codex, if present
• After resetting local app data and restarting Codex, the issue still happens.

This appears to be specific to the Codex embedded terminal keyboard paste handler. It does not seem to be caused by clipboard contents, PowerShell, PSReadLine, Windows clipboard history, or Codex user settings.

Adding confirmation from a duplicate report (#21729), now closed in favor of this issue.

Additional repro details from my environment:

• Codex App version: 26.506.21252
• OS: Windows 10 Pro 25H2, build 26200.8328
• Keyboard paste duplicates the text in the embedded terminal.
• Right-click paste works normally.
• The duplication reproduces across PowerShell, PowerShell 7.6.1 (pwsh), and Command Prompt.
• Removing PSReadLine does not change the behavior.
• The duplicated text is written into the real input buffer, not just rendered twice visually.

This supports the current hypothesis that the issue is in the Codex App embedded terminal keyboard-paste/input handling path rather than in a specific shell.

Adding another Windows confirmation with a slightly different repro detail and a code-level lead.

Environment:

• Codex Windows Store package path/version: OpenAI.Codex_26.506.3484.0_x64__2p2nqsd0c76g0
• Shell: Windows PowerShell 5.1 in the Codex embedded terminal
• Repro: both keyboard paste and right-click paste insert the clipboard contents twice in the embedded terminal

Local checks that did not fix it:

• Removed the PowerShell profile used during testing
• Disabled Windows Console QuickEdit under HKCU:\Console and the PowerShell console subkeys
• Verified/restarted Codex after those changes
• Tested as administrator; the paste duplication still reproduces

Code-level observation from the bundled app renderer:

The embedded terminal bundle contains an xterm paste handler shaped like:

handlePasteEvent = function (e, textarea, coreService, optionsService) {
  e.stopPropagation();
  if (e.clipboardData) paste(e.clipboardData.getData("text/plain"), textarea, coreService, optionsService);
}

That handler manually sends the clipboard text to the terminal but does not call e.preventDefault(). In Electron/Chromium, the default paste action can still insert the same clipboard text into the hidden textarea, which then flows through the normal input path. That would explain a double insert, and it also matches the right-click paste duplication seen here.

I prepared a local test patch that changes the handler to call preventDefault() before stopPropagation():

e.preventDefault();
e.stopPropagation();

I could not safely apply it to the installed Store package on the affected machine because WindowsApps/TrustedInstaller blocks writes to app.asar, but this looks like a likely minimal fix in the terminal paste event path.

Adding another Windows confirmation where all keyboard paste paths duplicate text in the Codex embedded terminal.

Environment:

• Codex Windows Store package: OpenAI.Codex 26.506.3741.0 (OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0)
• OS: Windows 11 Pro, version 10.0.26100, build 26100, x64
• Shell in embedded terminal: Windows PowerShell 5.1.26100.7920

Repro:

1. Open the Codex desktop app embedded terminal with PowerShell.
2. Copy plain text into the clipboard.
3. Paste once using Ctrl+V, Ctrl+Shift+V, or Shift+Insert.

Expected: clipboard text is inserted once.

Actual: clipboard text is inserted twice.

Scope / negative checks:

• External PowerShell does not reproduce the issue, regardless of paste method.
• No third-party keyboard macro or clipboard helper tools are involved.
• Restarting Codex and updating to the latest available version did not fix it.
• The behavior is specific to the Codex embedded terminal, not PowerShell itself.

This looks consistent with duplicate paste handling in the Codex app terminal frontend.

It's doing this on Cloud / web-based version as well

I've encountered this issue as well. It's relatively minor but still annoying, so hopefully it can be fixed soon.
I asked Codex to debug the installed Windows app and here's the diagnosis, if it helps:

I inspected the packaged Electron app (`OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0`) and the duplicate appears to come from two paste paths in the terminal bottom panel.

In the bundled terminal chunk (`webview/assets/thread-page-bottom-panel-state-D1Lz0U4Y.js`):

- The terminal uses xterm, which already registers native `paste` listeners on the hidden terminal textarea / terminal element.
- Codex also attaches a custom key handler via `attachCustomKeyEventHandler(...)`.
- On Windows, that handler treats `Ctrl+V`, `Ctrl+Shift+V`, and `Shift+Insert` as paste shortcuts, reads `navigator.clipboard`, then calls `term.paste(text)` manually.
- Chromium/Electron also dispatches a native paste event to xterm for those same shortcuts, so the same clipboard text is sent to the PTY twice.
- This matches the symptom: keyboard paste duplicates, but right-click paste only pastes once because it goes through one path.

Suggested fix: remove/disable the custom Windows keyboard paste branch for the xterm terminal and rely on xterm/native paste handling. A fallback would be suppressing Electron/native edit-menu paste while the terminal is focused, but that seems broader and riskier.

I couldn't find the desktop webview source in the public `openai/codex` repo, so I wasn't able to prepare a PR. The affected code seems to exist only in the packaged desktop app bundle.

Hope this gets fixed soon, because it's really annoying

Same here, bug is real

igual

I investigated this locally on Windows and I think the duplicate paste comes from an interaction between explicit paste events and the existing PasteBurst fallback.

Observed path:

1. Event::Paste(pasted) is mapped to TuiEvent::Paste(pasted) in tui/event_stream.rs.
2. app.rs handles TuiEvent::Paste and forwards it through the chat widget / bottom pane into the composer.
3. ChatComposer::handle_paste(...) inserts the pasted text and clears the current PasteBurst state.
4. On Windows, Ctrl+V can also emit a rapid raw KeyCode::Char / KeyCode::Enter stream for the same clipboard payload.
5. Those raw key events can then be detected by PasteBurst, flushed as FlushResult::Paste(...), and routed back through the paste insertion path, producing duplicate text.

I tested a small local patch that avoids changing keybindings and keeps raw-only PasteBurst behavior intact. The approach:

• Add an explicit terminal paste path separate from internal PasteBurst paste flushes.
• After an explicit terminal paste, record a short-lived expected raw echo payload.
• Before plain KeyCode::Char / KeyCode::Enter reaches PasteBurst, consume only exact matching echo characters.
• Treat raw Enter as \n.
• Clear the guard on mismatch, timeout, modified/non-char input, or once fully consumed.
• Preserve raw-only PasteBurst behavior for terminals that do not emit explicit paste events.

Local verification:

• just fmt
• cargo check -p codex-tui
• git diff --check
• cargo test -p codex-tui explicit_paste_suppresses_matching_fast_raw_char_echo -j 1 -- --nocapture
• cargo test -p codex-tui multiline_explicit_paste_suppresses_matching_raw_enter_echo -j 1 -- --nocapture
• cargo test -p codex-tui raw_only_paste_burst_still_flushes_as_paste -j 1 -- --nocapture

I have the focused patch locally if maintainers think this approach aligns with the intended fix.

Related: #15047, #17140, #21729