fix(clipboard): correct UTF-8 for terminal copy/paste (OSC 52)#44
Open
egertaia wants to merge 1 commit into
Open
fix(clipboard): correct UTF-8 for terminal copy/paste (OSC 52)#44egertaia wants to merge 1 commit into
egertaia wants to merge 1 commit into
Conversation
Copying text from a TUI app (Claude Code, tmux with set-clipboard on) routes through the OSC 52 clipboard-write escape sequence, whose payload is base64 UTF-8. The handler decoded it with atob(), which yields a binary/Latin-1 string (one code point per byte), so multi-byte characters were mangled — an em dash (E2 80 94) became "â€" (U+00E2 U+0080 U+0094). Decode the base64 bytes as UTF-8 via TextDecoder instead. (Plain xterm selection copy was unaffected, which is why copying from the terminal worked but copying from Claude didn't.) Also harden the paste side to match: - Read the clipboard through Electron's clipboard.readText() (more reliable than navigator.clipboard, which needs focus/permission). - Route the Ctrl+Shift+V paste action through the terminal so it honors bracketed-paste mode (multi-line paste no longer submits on the first \n). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Copying text containing multi-byte UTF-8 characters from a TUI app (Claude Code, or tmux with
set-clipboard on) and pasting it back produced mojibake — e.g. an em dash—becameâ€".Root cause: these apps copy via the OSC 52 clipboard escape sequence, whose payload is base64-encoded UTF-8. The handler decoded it with
atob(), which returns a binary/Latin-1 string (one code point per byte), so the em dash bytesE2 80 94turned into code pointsU+00E2 U+0080 U+0094.Plain xterm text-selection copy goes through
navigator.clipboard.writeText()and was unaffected — which is exactly why "copy from the terminal works, copy from Claude doesn't."Fix
TextDecoderover the raw bytes) instead ofatob()'s Latin-1 string. (the actual bug)clipboard.readText()instead ofnavigator.clipboard.readText()(no focus/permission requirement).Ctrl+Shift+Vpaste action through the terminal so it honors bracketed-paste mode — multi-line paste no longer submits on the first newline (e.g. pasting into Claude Code).Verification
Reproduced with an instrumented build logging clipboard reads/writes:
foo — barfrom a TUI loggedU+00E2 U+0080 U+0094.U+2014, and the paste round-trips asfoo — bar.🤖 Generated with Claude Code