Describe the bug
When copying a visually wrapped multi-line prompt and pasting it into GitHub Copilot CLI, the copied text contains unintended explicit newline / CRLF characters. These appear to be inserted at the visual wrap points, even though the original text does not contain explicit line breaks.
The pasted text includes explicit newline / CRLF characters at the visual wrap locations.
As a result, when the text is pasted into Copilot CLI, OR ANYWHERE ELSE the formatting is not as expected.
PERHAPS this is a just a default behaviour of block text highlighting/copying in Windows Terminal/Powershell
Affected version
GitHub Copilot CLI 1.0.48-1.
Steps to reproduce the behavior
1. Enter or display a long single-line prompt that auto-wraps visually in the UI.
2. Confirm that the text itself does not contain explicit LF or CRLF characters.
3. Use the mouse cursor to highlight/select the visually wrapped text.
4. Right-click and choose "Copy" / "Copy to clipboard".
5. Paste the copied text into a Copilot CLI prompt.
The screenshots below show :
- The original text auto-wrapped visually, with no explicit newline characters.
- The text selected using the mouse.
- The selected text pasted into Copilot CLI.
- The pasted result containing real line breaks where only visual wrapping existed before.
The issue seems related to copying selected auto-wrapped text from the UI and placing visual wrapping boundaries into the clipboard as actual CRLF/newline characters.
Expected behavior
The pasted text should preserve the original logical text content. Visual wrapping should not become semantic line breaks in clipboard text.
For example, if the source text is one logical line with no explicit newlines, the pasted text should also be one logical line.
PERHAPS this is a just a default behavior of block text highlighting/copying in Windows Terminal/Powershell... and otherwise not possible. So if thats the case it would be good it "CTRL+A"/"CTRL+C" worked when I was in the input/prompt box. To select all, and copy to clipboard (without the errant CRLF)
Additional context
I was am using Windows Terminal (in PowerShell - if that matters) - I don't know if behavior is different in bash or other console or terminal shell.
Describe the bug
When copying a visually wrapped multi-line prompt and pasting it into GitHub Copilot CLI, the copied text contains unintended explicit newline / CRLF characters. These appear to be inserted at the visual wrap points, even though the original text does not contain explicit line breaks.
The pasted text includes explicit newline / CRLF characters at the visual wrap locations.
As a result, when the text is pasted into Copilot CLI, OR ANYWHERE ELSE the formatting is not as expected.
PERHAPS this is a just a default behaviour of block text highlighting/copying in Windows Terminal/Powershell
Affected version
GitHub Copilot CLI 1.0.48-1.
Steps to reproduce the behavior
1. Enter or display a long single-line prompt that auto-wraps visually in the UI.
2. Confirm that the text itself does not contain explicit LF or CRLF characters.
3. Use the mouse cursor to highlight/select the visually wrapped text.
4. Right-click and choose "Copy" / "Copy to clipboard".
5. Paste the copied text into a Copilot CLI prompt.
The screenshots below show :
The issue seems related to copying selected auto-wrapped text from the UI and placing visual wrapping boundaries into the clipboard as actual CRLF/newline characters.
Expected behavior
The pasted text should preserve the original logical text content. Visual wrapping should not become semantic line breaks in clipboard text.
For example, if the source text is one logical line with no explicit newlines, the pasted text should also be one logical line.
PERHAPS this is a just a default behavior of block text highlighting/copying in Windows Terminal/Powershell... and otherwise not possible. So if thats the case it would be good it "CTRL+A"/"CTRL+C" worked when I was in the input/prompt box. To select all, and copy to clipboard (without the errant CRLF)
Additional context
I was am using Windows Terminal (in PowerShell - if that matters) - I don't know if behavior is different in bash or other console or terminal shell.