The command you copy is not the command you run.

Live demo: pastejacking

Here is a command a site might offer you. It reads echo "test". Copy it, then reveal what actually landed on your clipboard - here, or by pasting it into output-lies' x-ray tool. It is perfectly safe to run: every part is just echo.

You saw echo "test". Your clipboard held a whole second command chained on with && - echo "you did not expect this additional echo: unexpected code execution" - kept to a single line on purpose. Paste multiple lines and several terminals warn you: we tested it, and xfce4-terminal pops a "Warning: Potentially Unsafe Paste" dialog (its default, triggered by a newline in the paste), while qterminal offers a multiline-paste confirmation that is off by default. One line joined by && trips neither - it slips in silently and runs the moment you press Enter on a line you thought said only echo "test" (go ahead and run it - both halves are just echo). The page only ever shows echo "test"; the Copy button's JavaScript quietly writes the longer command to your clipboard instead, and slips a zero-width character in right at the && seam - it draws nothing, so a normal terminal shows no sign it is there. Real classes, not hypotheticals: this is pastejacking, and the same paste channel carries bracketed-paste bypass and Trojan Source tricks. The same channel is behind the in-the-wild ClickFix campaigns and the newline auto-run mechanism.

secure-terminal strips the smuggling. A paste carrying any invisible, control or bidi character is caught before it reaches your shell: secure-terminal names exactly what is hidden in it ("1 invisible character") and lets you drop it to plain ASCII or cancel - so nothing rides along unseen and the text you are about to run is fully visible to read first. It cannot judge a visible command for you - no terminal can, and a plain ASCII paste still submits - but it guarantees there is nothing hidden inside the paste. The corpus's adversarial harness feeds every one of these payloads to secure-terminal and asserts it neutralises each one.

And what still bites your terminal today

The paste above is one vector. These deception and clipboard classes still work on a stock, up-to-date terminal today - each links a proof in the corpus, an output-lies explainer, and the comparison matrix for the per-terminal verdict, with the "how secure-terminal handles it" answer in its own column.

secure-terminal closes these classes by design: non-ASCII becomes an inert, risk-coloured box (or a revealed <U+XXXX>), no escape sequence is parsed, the clipboard is never written from output, and the title is never touched - proven against each payload by the corpus's adversarial harness. The one it cannot close is the pure-ASCII look-alike (rn = m): no byte tool can, so read carefully.

The historical one: "a log file can run code"

For 20 years, some escape sequences asked the terminal a question - report the title, a DECRQSS status, the cursor - and the terminal answered by writing the reply into your shell's input. Chained with a newline, merely cat-ing a poisoned file could inject keystrokes and run a command. This is not a live threat on a current, default terminal: modern emulators mitigate it (empty or one-shot answerback, no auto-execute of replies, bracketed paste). We do not claim otherwise - the full CVE trail and a safe demo are on output lies (iTerm2, xterm, Windows Terminal, and the 2024 Ghostty / iTerm2 recurrence). It is worth naming only because the mechanism - output reflected onto the input wire - is the same one the reflection and input-injection rows measure.

How secure-terminal handles it: it parses no escape sequences at all, so the class cannot arise - there is nothing to reflect and nothing to auto-run (comparison). Proofs in the terminal-poc-corpus are canary-token only, never a live command.

The same lie, one layer over: code review

A terminal is not the only place untrusted bytes get rendered as something you trust. When you review a diff, the bidi, homoglyph, zero-width and control-byte tricks above ride in filenames, identifiers and branch names - and git adds its own: a submodule pointer bump, a retargeted symlink, an executable-bit flip, a .gitattributes that hides a file, a NUL that flips a source file to "binary". output-lies collects them as browsable, safe git branches: git diffs lie.

What secure-terminal does and does not do here. Viewing a hostile diff in secure-terminal neutralizes the display-layer bytes - a bidi filename, a homoglyph identifier, a zero-width split or a spoofed ref name arrives marked, not rendered. But the git-semantic traps (a mode bit, a submodule pointer, a .gitattributes) are not a display problem a terminal can judge - those need the safe git review drivers from Kicksecure's helper-scripts, which neutralize, surface, and fail closed. Same principle, different tool.

Test yourself, and test your own tools

Every class above is caught the same way: surface the raw bytes instead of trusting what they render to. Paste any URL, filename or command into output-lies' x-ray tool to see every hidden codepoint named, build a trap and fire it at the tools you already trust, or take the spot-the-lie quiz. secure-terminal is the same defense made the default for a whole session: paste in, read out, every invisible, bidi or look-alike byte arrives marked.