OSC52 parser assumes that len(%p1) is always 2 and breaks otherwise #28
Description
The problem line is here in tscreen.go. This assumes that the first parameter of the OSC52 reply will always be exactly one character long, and thus dropping the first two (%p1 and its delimiting ;) will get you the start of the payload. In practice, however, %p1 can be of any length; in tmux it's empty, and in some terminals, including xterm, it can be more than one character long.
This means that when used under these conditions, it either ends up including extra data at the start of the payload, or dropping the first character of the payload; in either case, base64 decoding fails and it can't receive the paste.