[Windows] Pasting selected text into Codex removes line breaks and appends two trailing spaces

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

26.820.71523

What subscription do you have?

ChatGPT Prolite

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When text selected from rendered content is copied and pasted into the Codex editor/input box on Windows, Codex modifies the pasted text.

I have observed two forms of text corruption:

1. Existing line breaks can be removed, causing text from adjacent lines to be concatenated.
2. Two ASCII spaces (U+0020 U+0020) are appended to the end of the pasted content.

For example, the clipboard contains:

BBB CCC
DDD EEE

The clipboard was inspected before pasting and contains exactly:

BBB CCC<LF>DDD EEE

There is no trailing whitespace on either line.

After pasting the same clipboard content into the Codex editor, the resulting content becomes:

BBB CCCDDD EEE··

where ·· represents two ASCII spaces.

Copying the content back out of the Codex editor and inspecting it confirms:

BBB CCCDDD EEE<U+0020><U+0020>

The original LF has been removed and two spaces have been appended.

The same clipboard content does not exhibit this behavior when pasted into Notepad++, which suggests that the clipboard itself contains the correct text and that the modification occurs while Codex processes the paste.

I first noticed this behavior after a recent Codex App update.

What steps can reproduce the bug?

1. In rendered text, select and copy text spanning multiple lines. For example:

BBB CCC
DDD EEE

1. Verify the clipboard contents before pasting.

In my test, PowerShell reports:

BBB CCC
DDD EEE

Character-level inspection confirms the boundary is:

BBB CCC<LF>DDD EEE

and neither line has trailing whitespace.

1. Paste the copied content into the Codex editor/input box.

1. Select the newly pasted content in the Codex editor and copy it again.

1. Inspect the clipboard contents.

The result is:

BBB CCCDDD EEE<U+0020><U+0020>

The original LF has been removed, concatenating CCC and DDD, and two ASCII spaces have been appended to the end.

I can also reproduce the trailing-space behavior with single-line selections.

For example, pasting:

BBB

into the Codex editor and copying it back out produces:

BBB<U+0020><U+0020>

Similarly:

AAA BBB CCC

becomes:

AAA BBB CCC<U+0020><U+0020>

Pasting the same source clipboard content into Notepad++ does not add the spaces or otherwise modify the text.

What is the expected behavior?

Codex should preserve the plain-text contents of the clipboard when pasting text into the editor.

If the clipboard contains:

BBB CCC
DDD EEE

the Codex editor should contain exactly:

BBB CCC
DDD EEE

The existing line break should be preserved, and Codex should not append additional whitespace that was not present in the clipboard.

In particular, Codex should not transform:

BBB CCC<LF>DDD EEE

into:

BBB CCCDDD EEE<U+0020><U+0020>

Additional information

I performed character-level clipboard inspection before and after pasting into Codex to determine whether the text modification originates from the source clipboard or occurs during paste processing inside the Codex editor.

Before pasting into Codex

The source clipboard contains:

BBB CCC
DDD EEE

Character-level inspection confirms that the boundary between the two lines is a single LF (U+000A):

B B B <SPACE> C C C <LF> D D D <SPACE> E E E

The line-ending analysis reports:

Line 1: "BBB·CCC"  [Trailing whitespace: 0]
Line 2: "DDD·EEE"  [Trailing whitespace: 0]

Therefore, before pasting:

• The LF (U+000A) is present.
• Neither line contains trailing whitespace.
• There are no unexpected invisible Unicode characters around the line boundary.

After pasting into Codex

I pasted the same clipboard content into the Codex editor, selected the pasted content, copied it back out, and inspected the clipboard again.

The resulting text is:

BBB CCCDDD EEE··

where ·· represents two ASCII spaces.

Character-level inspection shows:

B B B <SPACE> C C C D D D <SPACE> E E E <SPACE> <SPACE>

The line-ending analysis reports:

Line 1: "BBB·CCCDDD·EEE··"  [Trailing whitespace: 2]

The original LF (U+000A) is no longer present. CCC and DDD have been concatenated directly, and two ASCII spaces (U+0020 U+0020) have been appended to the end of the pasted content.

In other words, the transformation is:

Before:
BBB CCC<LF>DDD EEE

After:
BBB CCCDDD EEE<U+0020><U+0020>

Single-line reproduction

The trailing-space behavior is not limited to multiline selections.

For example, a source selection containing exactly:

BBB

becomes:

BBB<U+0020><U+0020>

after being pasted into the Codex editor and copied back out.

Similarly:

AAA BBB CCC

becomes:

AAA BBB CCC<U+0020><U+0020>

The two appended characters are ordinary ASCII spaces (U+0020), not zero-width characters, bidirectional control characters, or other invisible Unicode characters.

Clipboard format inspection

The source clipboard exposes the following formats:

HTML Format
System.String
UnicodeText
Text
Chromium internal source RFH token
Chromium internal source URL
Locale
OEMText

I also inspected the clipboard representations of a simple affected selection.

For a source selection containing:

trailing spaces

the UnicodeText representation is exactly:

trailing spaces

The HTML clipboard fragment is also exactly:

<!--StartFragment-->trailing spaces<!--EndFragment-->

There are no trailing spaces and no <br>, <p>, or <div> elements in that fragment that would explain the two appended ASCII spaces.

The same source clipboard content also pastes normally into Notepad++ without adding trailing spaces or otherwise modifying the text.

These tests suggest that the text modification occurs while the Codex editor processes the paste rather than during the original copy operation.

Comparison with #35232

I also checked #35232 ("Windows app collapses blank lines pasted from CRLF text"), which appears related because it involves Windows paste/newline handling, but the behavior here is materially different.

In #35232, the underlying CRLF CRLF sequence remains present after the content is pasted and copied back out of Codex. The reported problem is that the preserved blank line is not rendered correctly, so the issue is primarily visual/rendering-related rather than data loss.

In this reproduction, the source clipboard contains a real LF (U+000A) rather than CRLF, and character-level inspection confirms that it exists before pasting:

BBB CCC<LF>DDD EEE

After pasting into Codex and copying the content back out, that LF is no longer present. The underlying text has actually changed to:

BBB CCCDDD EEE<U+0020><U+0020>

Therefore, unlike #35232, this issue involves actual mutation of the pasted text: an existing newline is removed and two previously nonexistent ASCII spaces are appended.

For that reason, although #35232 may involve a related part of the Windows editor/newline handling path, this does not appear to be the same bug.