Copy command breaks Unicode string on WSL

[qwaz]

Describe the bug

Copy command does not correctly copy unicode characters.

Affected version

GitHub Copilot CLI 1.0.2 on WSL2

Steps to reproduce the behavior

Ask the model to write any answer that contains Unocide. Then, paste it to VSCode editor to see the corruption.

Example conversation:

❯ I'm testing your unicode output. Create a single sentence that contains unicode.
● Here you go: The café served crème brûlée while a naïve piñata swung beneath the château's façade — truly magnifique! 🎉

Then, use /copy command to copy the last output.

I get the following sentence:

Here you go: The café served crème brûlée while a naïve piñata swung beneath the château's façade — truly magnifique! 🎉

Expected behavior

Unicode characters are preserved when I copy the text.

Additional context

No response

[qwaz]

● This is a classic double-encoding bug: your UTF-8 bytes are being interpreted as CP437 (Code Page 437) and then re-encoded
  back to UTF-8.

  For example, é (UTF-8: c3 a9) → each byte read as CP437 → ├ (c3=U+251C) + ⌐ (a9=U+2310) → re-encoded as e2 94 9c e2 8c 90,
  which is exactly what your hexdump shows. The same pattern holds for every non-ASCII character, including the 🎉 emoji (f0
  9f 8e 89 → ≡ƒÄë).

  Likely cause: Your terminal or clipboard pipeline is using CP437 (the legacy IBM PC code page) instead of UTF-8. Common on
  Windows with cmd.exe or older PowerShell. Fix it with:

   - cmd.exe: chcp 65001
   - PowerShell: [Console]::OutputEncoding = [System.Text.Encoding]::UTF8
   - Windows Terminal: Should default to UTF-8 — check Settings → Profile → "Use legacy console" is off
   - Linux/macOS: Verify locale shows UTF-8 (e.g., LANG=en_US.UTF-8)

microsoft/WSL#11047

printf 'café 日本語 🚀\n' | clip.exe also resulted in corrupted characters.

[qwaz]

As a workaround, I enabled "Beta: Use Unicode UTF-8 for worldwide language support". It would be great if Copilot can detect the error and do the conversion in-between.