Pasting multi-line text in Codex CIL only keeps first line and auto-submits on Windows

Please prioritise this issue if you can, it keeps being a major problem for me.

Would be a big QOL.

This is the most pressing usabiltiy quirk I'm finding after the 0.22.0 update

+1, major issue.

This is the most pressing usabiltiy quirk I'm finding after the 0.22.0 update @Zamaroht

Would scaling back to a previous version resolve this?

> This is the most pressing usabiltiy quirk I'm finding after the 0.22.0 update @Zamaroht Would scaling back to a previous version resolve this?

There is no previous version - this issue exists since the first official Windows build.

I figure out a temporry fix for this - paste into chatgpt.com or desktop app but not the cli- "keep all context & condense it into a dense LLM readable ( does not have to be human readable form) in 1 line without line break" followed by the text - doesn't matter how long it is, the output might ben 100s of words, but without the line break, it still gets pasted on codex cli. Hopethis helps until they bring us an update soon.

PUMP!

Please prioritize this as I have stopped using codex because of this annoying issue. Its more than QoL issue, codex is a no go till this is fixed.

codex is miles behind claude!

codex is miles behind claude!

I disagree. I compare them from time to time - Codex's model response quality is by far better, so I prefer it for the type of large codebases that I work with. And patiently waiting for the UI shortcomings to be all eventually resolved one by one. Now, the Windows build is very solid, I stopped running it in WSL.

Should be fixed on the latest version

Should be fixed on the latest version应该在最新版本上修复

not at all. same problem in version 0.34

OpenAI is truly run by a bunch of idiots; they never fix such important issues.

Using zsh bracketed-paste as a solution

Any news?

Any news?

The latest version doesn't have this issue anymore and is working perfectly for me on Windows Terminal.

Should be fixed on the latest version

not at all. same problem in version 0.39.0

i use Windows Terminal with Powershell 7

has been two months and no fix at all. this is such a simple feature not sure what their developer is doing

非常简单的问题，为何难以修复

This was marked fixed and the issue closed back in early September. It sounds like some of you are still hitting this issue — or a similar one, so I'm going to reopen.

Can someone who is still experiencing the issue confirm whether the behavior you're seeing matches the original bug report? Any other repro details or insights are appreciated.

Here's the results of my multiline paste test in Windows.

Version: Codex 0.49.0
No WSL.

The test:

Return the highest number in this multiline string:

Line 1
Line 2
Line 3
Line 4
Line 5
Line 6
Line 7
Line 8
Line 9
Line 10
Line 11
Line 12
Line 13
Line 14
Line 15
Line 16
Line 17
Line 18
Line 19
Line 20
Line 21
Line 22
Line 23
Line 24
Line 25
Line 26
Line 27
Line 28
Line 29
Line 30
Line 31
Line 32
Line 33
Line 34
Line 35
Line 36
Line 37
Line 38
Line 39
Line 40
Line 41
Line 42
Line 43
Line 44
Line 45
Line 46
Line 47
Line 48
Line 49
Line 50

Test 1 - VS Code Powershell (only 1 paste done):

PS C:\Users\User\Documents> codex ╭─────────────────────────────────────────────────╮ │ >_ OpenAI Codex (v0.49.0) │ │ │ │ model: gpt-5-codex high /model to change │ │ directory: ~\Documents │ ╰─────────────────────────────────────────────────╯ To get started, describe a task or try one of these commands: /init - create an AGENTS.md file with instructions for Codex /status - show current session configuration /approvals - choose what Codex can do without approval /model - choose what model and reasoning effort to use /review - review any changes and find issues › Return the highest number in this multiline string: Line 1 Line 2 Line 3 Line 4 Line 5 Line 6 Line 7 Line 8 Line 9 Line 10 Line 11 Line 12 Line 13 Line 14 Line 15 Line 16 Line 17 Line 18 Line 19 • Called └ sequentialthinking.sequentialthinking({"thought":"Understand task: user provides multiline string with numbers? lines text 'Line n'. They ask highest number in string. Need parse; highest is 19. Check sequential approach maybe 3 thoughts. No need plan tool maybe not? but instructions require sequentialthinking. Step 1 identify numbers, step 2 evaluate max. Done.","thoughtNumber":1,"totalThoughts":3,"nextThoughtNeeded":false}) {"thoughtNumber": 1, "totalThoughts": 3, "nextThoughtNeeded": false, "branches": [], "thoughtHistoryLength": 1} ─ Worked for 12s ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── • Requirement Clarification - User provides a fixed multiline string and wants the largest integer appearing in it. Core Solution Design Implementation Details - Lines are sequentially numbered 1 through 19; the largest observed value is 19. Key Design Decisions - Treated the task as a direct comparison of listed integers, assuming no hidden formatting or additional input. Validation Results - Confirmed that 19 is the highest number in the provided string. What I used & why: sequentialthinking — enforced structured reasoning per protocol. › Line 20 Line 21 Line 22 Line 23 Line 24 Line 25 Line 26 Line 27 Line 28 Line 29 Line 30 Line 31 Line 32 Line 33 Line 34 Line 35 Line 36 Line 37 Line 38 Line 39 Line 40 Line 41 Line 42 Line 43 Line 44 • Called └ sequentialthinking.sequentialthinking({"thought":"New string lines 20-44. Need max number 44. Simple reasoning.","thoughtNumber":1,"totalThoughts":3,"nextThoughtNeeded":false}) {"thoughtNumber": 1, "totalThoughts": 3, "nextThoughtNeeded": false, "branches": [], "thoughtHistoryLength": 2} ─ Worked for 5s ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── • Requirement Clarification - Determine the largest integer in the newly provided multiline string. Core Solution Design - Examine each line, note the trailing integers, and identify the maximum. Implementation Details - Lines progress from 20 to 44; the greatest numeric suffix is 44. Key Design Decisions - Direct comparison of the listed integers; no additional assumptions required. Validation Results - Verified that 44 is the highest number present. What I used & why: sequentialthinking — maintained the mandated structured reasoning workflow.`

Result:
After only 1 paste, VS Code Powershell Codex CLI proceeded to process two prompts without the user doing anything after 1 paste. Codex did not get the entire pasted string.

Test 2 - Windows Powershell (not inside VS Code):

› Return the highest number in this multiline string: Line 1 Line 2 Line 3 Line 4 Line 5 Line 6 Line 7 Line 8 Line 9 Line 10 Line 11 Line 12 Line 13 Line 14 Line 15 Line 16 Line 17 Line 18 Line 19 Line 20 Line 21 Line 22 Line 23 Line 24 Line 25 Line 26 Line 27 Line 28 Line 29 Line 30 Line 31 Line 32 Line 33 Line 34 Line 35 Line 36 Line 37 Line 38 Line 39 Line 40 Line 41 Line 42 Line 43 Line 44 Line 45 Line 46 Line 47 Line 48 Line 49 Line 50 • Called └ sequentialthinking.sequentialthinking({"thought":"Need to extract the highest numeric value mentioned in the provided multiline string listing lines 1..50. Straightforward: numbers are consecutive from 1 to 50; highest is 50. No additional constraints.","thoughtNumber":1,"totalThoughts":2,"nextThoughtNeeded":false}) {"thoughtNumber": 1, "totalThoughts": 2, "nextThoughtNeeded": false, "branches": [], "thoughtHistoryLength": 1} ─ Worked for 16s ─────────────────────────────────────────────────────────────────────────────────────────────────────── • a. Requirement Clarification The task is to identify the largest numeric value present in the provided multiline string enumerating lines 1 through 50. b. Core Solution Design Interpret the list as sequential numbers and determine the maximum by inspection; no computation beyond recognition is required. c. Implementation Details No code execution was necessary—the sequence runs consecutively, so the final line number directly yields the answer. d. Key Design Decisions Opted for mental inspection since the list is short, ordered, and explicitly runs to 50, avoiding unnecessary tooling. e. Validation Results Confirmed the sequence ends at “Line 50,” establishing 50 as the highest number. What I used & why: sequentialthinking – enforced initial planning per protocol.

Result:
After only 1 paste, Powershell Codex CLI proceeded to process the entire multiline string without the user doing anything after 1 paste. Codex processed the entire pasted string.

Significantly affects usability

Hasn't this problem been solved yet, how terrible...Several months have passed and the problem still hasn't been solved, which is really terrible...

Hey @aibrahim-oai - the issue is still being reported as of v0.80.0 (see recent comments above).

After deep investigation, I found that previous fixes (like PR #9124 and #8774) addressed related issues but didn't fix this specific scenario:

The core problem: PASTE_BURST_CHAR_INTERVAL is 8ms on all platforms, but VS Code's terminal emulation on Windows delivers characters ~10-15ms apart. This means:

1. Burst detection never triggers (chars too slow to count as "burst")
2. Enter key submits instead of inserting newline
3. Only first portion of paste is captured

PR #9348 fixes this by using 30ms on Windows (following the existing pattern for PASTE_BURST_ACTIVE_IDLE_TIMEOUT which is already platform-specific).

Would appreciate a review when you get a chance - this has been affecting Windows users since Aug 2025.

for windows in general, an overall setting that lets us mark CRLF as default newline would be great; and handling across the entire application

@kalineh That's a good suggestion for a separate feature request. The CRLF handling is a broader scope than this paste timing fix.

This issue (#2137) is specifically about multi-line paste being truncated on Windows due to burst detection timing. PR #9348 addresses that by adjusting PASTE_BURST_CHAR_INTERVAL to 30ms on Windows.

For the CRLF newline handling, I'd suggest opening a new issue so it can be tracked and discussed separately.

Constantly hitting this – it is disrupting, distracting and annoying. I use mintty 3.81 (Cygwin-x86_64). Hopefully https://github.com/openai/codex/pull/9348 is going to fix this. 🙏

我用codex写了一个程序，直接用快捷键就可以完美粘贴多行文本

不需要修改codex源码

下载，配置环境变量即可使用

还有更多配置，可以精确粘贴，净化掉首尾空行等，快来体验啊啊啊啊
github/codex-cli-multiline-paster

I wrote a program using Codex that allows me to perfectly paste multiple lines of text using shortcut keys

##No need to modify the codex source code

##Download and configure environment variables to use

There are more configurations available, such as precise pasting and purification of leading and trailing lines. Come and experience them now

saw this older change: https://github.com/openai/codex/pull/9348

// ----
Use Windows-specific timing (30ms) for PASTE_BURST_CHAR_INTERVAL, following the same pattern already used for PASTE_BURST_ACTIVE_IDLE_TIMEOUT (60ms on Windows vs 8ms on Unix).
30ms is still fast enough to distinguish paste from typing (humans type ~200ms between keystrokes).
// ----

okay yeah i see the issue here; this paste mechanism is just never going to be reliable; its going to fail on one side or the other

assuming all human keystrokes is > 30ms is not good too, thats certainly plausible with one hand typing and one hand pressing enter. also the performance is very bad so a single frame is probably significantly more than 30ms - depending how you are checking timing (not sure why text render is >1ms but thats for another day)

我用codex写了一个程序，直接用快捷键就可以完美粘贴多行文本 ## 不需要修改codex源码 ## 下载，配置环境变量即可使用 还有更多配置，可以精确粘贴，净化掉首尾空行等，快来体验啊啊啊啊 github/codex-cli-multiline-paster I wrote a program using Codex that allows me to perfectly paste multiple lines of text using shortcut keys ##No need to modify the codex source code ##Download and configure environment variables to use There are more configurations available, such as precise pasting and purification of leading and trailing lines. Come and experience them now

Thanks, it works like a charm. 非常感谢，效果很好。

I'm trying to switch from Claude Code to Codex, and while Claude never has an issue with line breaks, Codex (and also OpenCode) do. I'm on codex-cli 0.121.0, and pasting just a bit of text with linebreaks will already submit the text. Would be great if this could be resolved.

PS: Note sure why this issue is closed, but it's not resolved, https://github.com/openai/codex/pull/9348 does not solve this.

It's so cool we have this issue in May 2026, let's go guys!

Problem still exists as of codex-cli 0.142.2

Yes, I don't think OpenAI folks are using Codex to develop software. I find that especially when the copied text starts with an empty line it breaks things. It's not the only cause, but I think there's a very high chance it will break.