[Bug][Claude Code] Bracketed paste commands fail

[rbitar]

When injecting a bracketed paste command interpreted by CLI tools like Claude Code it fails without any console log error. This bracketed paste commands are used when referencing files which are possibly binary files such [Image #1].

The temporary workaround is to instruct claude to simply read the full file path instead of using bracketed paste, which does work.

[alexp-sssup]

Hi, thanks for reporting this issue, could you provide a concrete example on how to reproduce this?

Pasting images currently do not work, that is expected. This feature can be supported, but it would require an ad-hoc solution to bridge the browser clipboard with the clipboard utilities used internally.

[rbitar]

Thanks @alexp-sssup this is not related to the navigator clipboard, but if you write into the pod with xterm:

xterm.input(`\x1b[200~${text}\x1b[201~`)

Claude Code will recognize this as a bracketed paste command and render to the screen the brackets around the injected text [...], but will freeze when referencing a binary file (such as an image or pdf, etc). However, claude can successfully read the binary if you instruct it to Read the filepath, so there is a workaround at the moment.

[alexp-sssup]

I think I might have reproduced the issue, or one very similar, with the following input

var text = "\x89PNG\r\n\x1A\n"
xterm.input(`\x1b[200~${text}\x1b[201~`)

The issue here is that some non-ASCII chars, in this case 0x1b are interpreted as control chars, in this case "Ctrl+Z". Claude Code is using the terminal in raw mode (as far as I can see) and internally interpret 0x1b as "suspend the process".

Unless I am missing something, this is not a problem that can worked around at the BrowserPod level, any 0x1b in the input stream (and other codes as well) will be interpreted directly by Claude Code as control code.