In his keynote talk at the first Perl conference, Larry Wall couldn’t get the Windows computer on the podium to behave. So he SSH’d into his own machine and said, with relief and joy: “Home sweet home”.
Three decades on, software developers still live in the terminal, now more than ever as coding agents dethrone the integrated environments that held sway for so long. IDEs recede as we do less writing and editing, more reading and reviewing. If you watch developers at work today, you are likely to see them in the terminal at a command prompt.
It’s not your grandfather’s command prompt, though, it’s a terminal-based agent like Claude Code or Codex. These agents are maestros of the underlying command shell; they wield its powers far more effectively than most of us can. If you care to, this is a great way to learn by doing. Don’t take a course or watch a video to learn about git, just watch how agents use it in all its glorious complexity.
But what if you don’t care about those commands? What if you’ve never opened a terminal? The genesis of Bram was my experience helping non-coders use Claude Code. I sat them in front of my computer with two windows side-by-side: the agent in a terminal on the left, the app it was building in a browser on the right. These folks were delighted to be able to ask the agent for features and see those features appear after a browser refresh. But they did not enjoy reading the terminal to try making sense of what Claude Code was doing and saying.
Bram started as a way to manage the side-by-side windows in a single self-contained app. As workflow emerged, the terminal remained the primary way to view and interact with the agent. What would it take to augment the terminal with a more readable display? That idea moved forward in fits and starts as I learned more about the layers involved: the session file, the pseudo-terminal (PTY), xterm.js, and agent hooks. It was hooks that finally unlocked instant and reliable recognition of the permission menus shown in the Claude Code and Codex TUIs (text user interfaces). But all the layers participate in making it possible, now, to operate Bram in full GUI mode with the terminal closed.
If you are a terminal jockey you may enjoy the more legible display of: agent messages, your messages, pasted screenshots, diffs, tool calls and results. But when I introduce non-coders to agent-assisted coding the first question is usually: “What is the terminal?” My answer: “It’s where the agent runs the commands needed to do what you want it to do.” For me, over the past few days, the list includes:
awk, bash, bc, cargo, cat, cd, chmod, claude, codex, cp, curl, cut, date, diff, echo, exit, find, gh, git, grep, head, jq, ls, nl, node, paste, perl, pgrep, php, printf, ps, pwd, python3, rg, rm, ruby, rustfmt, sed, seq, set, sh, shasum, sleep, sort, source, sqlite3, stat, sw_vers, sysctl, tail, test, touch, tr, true, uniq, uptime, wc, whoami, zsh
These humble commands — I love that perl makes the list! — always were the foundation of computing. That hasn’t changed. What has is that newcomers are running them, indirectly, as they talk with agents to summon software into existence. For many, the terminal is a foreign and hostile environment. Now it’s optional. If you know and love the terminal it’s there in the left pane. If you’d rather not look at it, Bram offers a friendlier way to work with Claude Code and Codex in a git/GitHub repository.
One thought on ““What is the terminal?””