Not yet human-audited. Here is the trade-off.

A traditional terminal emulator is not a neutral, safe baseline. It interprets whatever bytes a program prints, and that has well-documented consequences:

• A simple cat /dev/random is enough to garble the screen and, on many terminals, silently rewrite the window title - we measured this against ten terminal emulators.
• Program output alone can rename your window or tab and, in several terminals, read or overwrite your clipboard - the title/answerback and clipboard reflection classes, still open by default across much of the field (detailed on the comparison page).
• Any command you copy from a website, a Stack Exchange answer, or an AI chat interface can carry hidden Unicode or control characters that read differently from what runs - the Trojan-Source class - and paste straight into your shell without you noticing.
• The code that parses those hostile bytes is usually written in a memory-unsafe language (C), with a long history of memory-corruption bugs in exactly that path.

The documented workaround for the paste problem - copy to a text file, scan it, then copy to the terminal - is real, but so cumbersome that almost nobody does it every time. And crucially, these traditional-terminal weaknesses are, to our knowledge, not even being worked on: they are considered out of scope, a different threat model. secure-terminal removes the whole class by design. So the choice is between a known-vulnerable terminal and an AI-authored one that closes those attacks but has not yet had a human security audit.

Inapplicable by construction. The published CVEs and the "out of scope, different threat model" issues that afflict traditional terminals are not attacks secure-terminal defends against; they are attacks it has no machinery to suffer. There is no OSC 52 parser to have an OSC 52 bug, no answerback string to reflect, no alternate screen to hijack, no C parser of hostile bytes to overflow. A feature that does not exist cannot be exploited - that, and only that, is what the comparison shows.

What that does not buy. secure-terminal may well have unknown vulnerabilities of its own, including ones no other terminal has, precisely because no other terminal has this code: the sanitiser, the four display modes, the paste and copy review, the restricted TUI screen model are all new, none of it human-audited, none of it with years of field exposure behind it. A short CVE list here is the absence of a search, not the result of one.

So state it plainly: a narrower attack surface, not a proven-safe one. Fewer places for a defect to hide is a real and deliberate property; "therefore there are none" does not follow, and nothing on these pages should be read as claiming it. If you want the stronger claim, that is what levels 2 and 3 above are for - and neither is done yet.

There are real, documented problems with AI, which is exactly why Kicksecure has a policy on artificial intelligence and has itself received - and rejected - nonsensical AI-generated contributions. AI driven by a non-programmer will most likely generate nonsensical code.

The distinction that matters is who drives it. Used by an experienced developer who reviews, tests and constrains it - not by a "fire everyone, the AI does it all" fantasy - AI is a tool that can produce working software, and the output can be held to a bar most human-written code never is. That is the entire point of the AI Review: this project is not "trust the AI," it is "here are the adversarial tests, the fuzzers, the scanners and the cross-model reviews the code has to survive, all published for you to inspect."

secure-terminal is roughly 6,300 lines of code today, and a terminal emulator is a notoriously fiddly thing to get right: escape-sequence parsing, a screen model, input handling, and every edge case programs rely on. Established emulators are typically maintained by a single person or a small team and have been developed and hardened over years, not weeks. For a project like Kicksecure, writing a secure terminal from scratch - and then giving it a full, independent security audit - cannot realistically be a side project done overnight - which is exactly why this page exists rather than an implied clean bill of health.

For scale, here is roughly how much code each terminal we compared against carries, counted with cloc over the primary source (approximate; AI-checked; secure-terminal re-counted 2026-08-12):

Except for the deliberately minimal st, these are far larger than secure-terminal and - apart from alacritty's Rust - written in memory-unsafe C or C++, developed and hardened over years. Small does not mean safe on its own, but it does mean the whole thing is far more reviewable.

So the plan is staged: ship it with the automated safety net in place, complete the human non-malicious review next (removing the backdoor question), and pursue a deeper audit over time. Meanwhile you get to make an informed choice instead of an implied-perfect one.

Because even with the audit still outstanding, the concrete, known attacks that a traditional terminal is exposed to - screen and title hijacking, reflection-to-command-injection, hidden-character paste, memory-corruption in the parser - are mitigated by design here, and demonstrably so. And once the human non-malicious review is complete, you also get confidence that there is no backdoor. That is a different, and for many people better, risk profile than the status quo - offered without overstating it: it is a narrower attack surface, not a proven-safe one.