The same attack text, ten terminals.

Every escape trick on this page fires just by being displayed - viewing an attacker's log or diff is enough, no execution needed. The board below is one safe, display-only file shown in a normal terminal and in secure-terminal, side by side: the normal terminal interprets the escapes; secure-terminal reduces the identical bytes to inert, marked ASCII. Switch the compared terminal and the secure-terminal view with the controls above.

One safe, display-only board (the corpus tui-showcase PoC) carrying every display-class at once - a hijacked title, a DEC frame, a homoglyph example.com, a bidi report cod.exe, zero-width and invisible bytes, an SGR-hidden SECRET, an OSC 8 link and the alternate-screen switch. Click any shot for full size. Reproduce it.

Each neutralised non-ASCII byte is an inert box coloured by its risk class, never by the program:  bidi controls,  homoglyphs,  zero-width/invisible,  control bytes,  other non-ASCII (honest foreign text).

A normal terminal treats program output as commands: move the cursor, erase and repaint lines, hide or fake text. secure-terminal parses none of it apart from safe colour and four line-local edits (CSI C/D/G/K) clamped to the line being written, so any stray control byte shows as an inert box and nothing a program prints can repaint the screen or reach a line already scrolled past. See the compatibility page for exactly which sequences are neutralised.

secure-terminal's colour is not colourless. Safe ANSI colour is on by default (turn it off with the Colors toggle or NO_COLOR). The difference is the contrast guard: it forces any colour to stay readable against the background, so a crafted log's stuck red-on-red - designed to hide text - is shown as legible text instead. Colour that can never conceal, and a palette a program cannot repaint.

An OSC 0/2 escape in output renames your window or tab to anything - a fake "production" label, a spoofed context. On seven of the ten emulators the attacker-controlled title reads back in the title bar. Two are partial: konsole parses and stores it but the default tab format omits the program-set title (not shown by default); kitty honours it, but its default shell integration resets the title to the cwd at the next prompt, so the hijack shows until then. secure-terminal never sets the OS window title from output. In CLI mode the title escape is neutralised (a banner notes it); in TUI mode the program-set title is shown, but quarantined on a separate, visibly-untrusted tab line (plain ASCII, never reported back) so it can never pose as the trusted, app-set label.

kitty (like iTerm2) implements OSC 9, so program output can raise a real desktop notification with attacker-chosen text, outside the terminal window entirely. The others in this set do not implement it, so the class does not apply to them. secure-terminal's CLI mode strips the escape - no popup, inert text, a banner flags it. The payload is the corpus notification-spoof-kitty-2022 class.

The OSC 52 clipboard write is the one class a screenshot cannot show - its effect is on your system clipboard, not the screen. So we measured it directly: for each terminal we seeded the X clipboard with a sentinel, cat'd the corpus osc52-clipboard-write payload, and read the real clipboard back (via PyQt6). If the token landed, output overwrote your clipboard. Tested 2026-08-12 on shipped defaults, window focused.

Three of the ten let untrusted output silently overwrite your clipboard on their defaults. This is a real per-terminal verdict: clipboard-verdict.sh reads the real clipboard back after each terminal views the payload. Note the twist: konsole does not surface a hijacked title, yet does honour the clipboard write.

A terminal and the program it runs share one two-way channel (the pseudo-terminal). When output contains a query escape - say ESC[c ("what terminal are you?") - a normal terminal answers by writing the reply back onto that same channel, and the input side of that channel is the program's keyboard. So a query hidden in attacker output makes the terminal inject bytes as if you had typed them - no keypress needed. That reflection is how a remote program reads your clipboard back through an OSC 52 read query, and how a title or answerback report becomes spoofed input.

David Leadbeater's 2023 review catalogued the class across current terminals. The CVEs it collects are on other emulators - CVE-2022-45872 (iTerm2), CVE-2022-47583 / CVE-2023-39726 (mintty), CVE-2022-23465 (SwiftTerm) - so they prove the class, not these ten. For the compared set we measured it directly: the fingerprintability table fires each query at every terminal and records the reply - a typical emulator answers device-attributes, cursor-position, answerback and colour queries; secure-terminal stays silent. secure-terminal answers no query by default - an automated test asserts zero bytes are ever written back. The one exception is clipboard read, opt-in and human-gated once per tab.

A terminal and the program it runs share one two-way channel: a reply the terminal writes back to a query escape arrives on the same wire as your keystrokes, so a query hidden in attacker output can make bytes appear as if you typed them - no keypress needed. That is how a reflected report, answerback or clipboard-read reply turns into injected input. What actually lands depends on which queries each terminal answers (our fingerprint measurement records the reply per class of terminal) and whether it reaches the shell mid-line. Modern defaults mitigate turning a reflected reply into a run command - bracketed paste, empty or one-shot answerback, no auto-execute of replies (the same default mitigation the cat-execution row notes) - but the bytes still arrive as input. secure-terminal answers no query by default and an automated test asserts zero bytes are ever written back, so nothing from output can arrive as input.

Reproduce it (safe): the query-report class is stored read-safe in the corpus - see answerback-injection and device-status-reflection-rxvt-2021. Decode each with the stock base64 -d poc/<id>/payload.b64; each PoC carries a canary token, never a live command.

Historically, escape sequences could be chained toward command execution - an answerback string set from output and then auto-replayed, or a report reflected into the shell as a runnable line. This is the class behind the old "a log file can run code" warnings. Modern terminals mitigate it by default (empty/one-shot answerback, no auto-execute of replies, bracketed paste), so plain cat of a hostile file is not a live remote-code-execution path on a current, default-configured emulator - we do not claim it is (the full CVE trail - iTerm2, xterm, Windows Terminal, and the 2024 Ghostty / iTerm2 recurrence with a public proof of concept - and a safe demo are on output lies: merely viewing a file can run commands). It is shown here because the mechanism (output reflected onto the input wire) is the same one the reflection and input-injection rows measure. secure-terminal parses no escape sequences at all, so the class cannot arise: there is nothing to reflect and nothing to auto-run.

Reproduce it (safe): view the display-only-safe board (below) - it changes only the display and runs nothing - and the reflected-report PoCs in the corpus, all canary-token, never a live command.

Zero-width and other invisible characters draw nothing, so a command or a paste can carry hidden bytes you never see - the heart of the pastejacking demo. secure-terminal names each inline as <U+XXXX NAME> by default, or shows an inert risk-coloured box.

Non-ASCII characters identical in shape to ASCII (a Cyrillic a, a Greek o) make a fake command or URL read as legitimate - a clean example.com that is not. Universal across terminals. secure-terminal flags the look-alike byte as a coloured box, or names its exact codepoint in Detail mode.

Bidirectional control characters reorder how a line renders, so report cod.exe displays as report exe.doc. The four bidi-aware terminals here (the three VTE apps and konsole) actually reorder it; the rest leave the bytes present but in logical order - weaker, but the invisible controls are still there and unmarked. secure-terminal neutralises the bidi controls entirely. Proof: corpus trojan-source-bidi-2021.

head -c 1200 /dev/random at a prompt: every normal terminal is garbled, most with stuck reverse-video or replacement glyphs, and the visible mess clears only with reset. secure-terminal shows every non-ASCII byte as inert, risk-coloured ASCII with the prompt returning clean.

A command copied from a web page can carry a whole second command chained on with && and an invisible byte at the seam - it draws nothing, so a normal terminal shows no sign it is there. Modern shells enable bracketed paste by default now (bash 5.1+, zsh, fish), so a multi-line paste is held for review, but a one-line && trick still slips through and older or minimal readers (bash < 5.1, dash, busybox ash, a raw REPL, an old SSH host) do not hold it at all. And the terminal-side guard is not uniform either: measured across emulators (harness below), xterm sanitises an embedded forged bracketed-paste end marker (guard-held) while suckless st passes it through, so pasted bytes escape the guard (bypass). secure-terminal sanitises a paste to ASCII so a forged marker cannot survive (guard-held): it catches any invisible, control or bidi character in a paste, names what is hidden, and lets you drop it to ASCII or cancel. See the live pastejacking demo and the full still-applicable list on the attacks page.

Running full-screen programs is a capability, not a vulnerability - every terminal does it. secure-terminal's opt-in TUI mode grants the layout, but every cell is still character-filtered: look-alikes stay boxed and the title stays off. TUI mode grants layout, never an unfiltered cell. Only run programs you trust - in TUI mode a program can still draw a misleading interface within its own screen.

The code that parses untrusted bytes is where a memory-safety bug bites, so this row is scoped to the escape-sequence parser. Nine of the ten emulators parse in C or C++ (xterm, urxvt, st, VTE for gnome/xfce4/mate-terminal, konsole, qterminal, kitty's in-tree vt-parser.c); only alacritty (Rust) and secure-terminal (Python) parse in a memory-safe language. Each badge links to the exact parser source.

Honest caveat: the claim is scoped to the parser. secure-terminal's runtime embeds CPython (C) and PyQt6/Qt (C++) like any Python GUI app; what is memory-safe is the parsing and sanitizing code itself, which is pure Python with no C extension in the parse path. Read this as "fewer places for a bug to hide", not a proof there are none - see what does not apply, and what still might.

No terminal protects you from a harmful command itself. Deciding that curl x | sh (curl bash pipe) or a subtly wrong rm is dangerous is a judgment call, not a parsing rule, so no terminal can catch it by design. secure-terminal keeps that judgment out of the terminal; it ships no AI and no policy of its own.

GUI and CLI. secure-terminal is a graphical application; secure-terminal-cli is the same safe core as a command-line wrapper - it runs a shell or command in a pseudo-terminal and sanitizes the output before it reaches your existing terminal, so a plain console or an SSH session gets safe display without the GUI. It sanitizes what a program displays; it does not gate keystrokes or judge commands.