It seems to have a hand-written ad hoc parser, handling untrusted input. A very rich source of exploits. (Luckily it's at least using a memory safe language so what you can do is likely limited to DoSing yourself or using up all memory as in this case.)

I know this sounds sarcastic, but I don't mean it that way. Are there virtual terminals which are not hand-written ad hoc parsers?

They seem to be using this library for some sort of remote shell session snooping. At the very least this sort of negligence lets an attacker smuggle commands through the system unnoticed.

An assumption made by many virtual terminals is that the input and output stream are trusted. For instance `cat file.txt` in a terminal result in your terminal being sent escape sequences that will change how your terminal functions well after you quit cat.

I've always wanted a virtual terminal that had a terminal state stack, when you run a command or open a program, all the changes to the terminal are pushed on the top of terminal stack. When I quit the program or the command stops, the state is popped. It seems like it would be very difficult to implement such a thing in the current terminal framework because as far as I can tell, they do not understand when a command starts or stops. Then again the effectiveness of virtual terminals over the last 5 or so decades is likely because of this simplicity and its corresponding flexibility.

A few terminals (e.g. iTerm2) try to track the current command, presumably by looking at the children of the shell they spawn. This isn't much use when your current command is `ssh`.

You could probably have a push/pop escape sequence requiring a matching unique token that intermediate output can't guess.

    OSC 57473 ; 1 ; <token> ST
    ⋮
    OSC 57473 ; 0 ; <token> ST

Can bash do this? I wonder what issue I have yet to think of prevents pop/pushing escape sequences from being default behavior.

I think with most current shells you could do this in prompt strings. Actually, you'd probably want a combo that restores the top-of-stack state and leaves it there; then you'd push the state during shell initialization and restore it in the prompt.