The Revenge of the Text Interface and the Standard Interface

August 30, 2026 - 4 minutes read - 658 words

If you had told me five years ago that the most popular interface for the most powerful applications on earth would be the command line, I would have sighed and said, “I wish.” But that’s exactly what’s happened.

Applications like Claude Code:

and OpenAI’s Codex

Second-mover Codex CLI looks pretty similar to Claude Code

have made the terminal-only experience feel universal, elegant, and desirable to a generation that grew up on iPhones and fat Electron apps. What’s going on here? Above that, what’s going on with the standard user interface with File / Edit / … Help?

Resisting the non-CLI Life

We’ve done this before. A decade ago it was code editors: BBEdit, TextMate, Notepad++, and Sublime gave way to Electron — Atom, then VS Code, then every fork of VS Code.

The hardcore didn’t follow. We stayed principally on vim and emacs instead, trading a decade of usability gains for the steepest learning curve in software, because the alternative was worse. The standard menus offered oodles of features, sure, but something simpler and direct seemed preferable.

If “never leave vim” was extended to the OS, mouse-less experiences like DHH’s Omarchy or Hyprland (or my 2002 vintage RedHat Linux + ratpoison WM) doubled down in shooting the mouse-driven application design concept the double-deuce.

A Poisoned Carrot

Additionally, open source application developers on Linux seemed to delight in weird interfaces that ignored the Standard User Interface. The Register ran a well-researched piece on the rise and fall of the Standard User Interface, and its money quote is worth sitting with:

Menu bars, dialog box layouts, and standard keystrokes to operate software are not just some clunky old 1990s design to be casually thrown away. They were the result of millions of dollars and years of R&D into human-computer interfaces, a large-scale effort to get different types of computers and operating systems talking to one another and working smoothly together. It worked, and it brought harmony in place of the chaos of the 1970s and 1980s and the early days of personal computers. It was also a vast step forward in accessibility and inclusivity, opening computers up to millions more people.

Just letting it fade away due to ignorance and the odd traditions of one tiny subculture among computer users is one of the biggest mistakes in the history of computing.

The CLI didn’t rise because menus and dialog boxes failed the people who used them; it rose because a subculture of developers decided that speed and control mattered more than the decades of R&D that made computers legible to everyone else.

Interfaces are better the less thinking they require: whether the interface is a steering wheel or an online form, if you have to spend any amount of time figuring out how to use it, that’s bad. … If you learn that Command + C is the keyboard shortcut for copy, you want that to work everywhere.

— John Loeber, “Bring Back Idiomatic Design”

The terminal didn’t win an argument about design. It won by default, because it’s the one interface nobody has managed to make inconsistent with itself in thirty years.

Which is exactly the bet Claude Code and Codex are making. An AI agent doesn’t need a GUI to reason well, but it does need an interface that hasn’t changed shape in three decades and which readily integrates core Unix ideas: STDIN, STDOUT, a shell it can pipe through/read from. Ship it in any other app toolkit and you risk “creative” variance from the SUI and/or packaging woes. As Linus himself put it, memorably, on why desktop Linux sucks: you can’t just build an app for Linux, you have to build it for multiple distributions, and it sucks.

Counterwinds

The Craft of Text Editing has a wonderful introduction which talks about designing CLI-rooted (or rather, emacs-rooted experiences) to a wide population. It’s a rare breath of fresh air. I commend it.