Kirti Kumar Sahu · October 5, 2026 · 11:00 · 6 min read
Count the browser tabs you open in a normal engineering day that exist only to answer one small question. Has the DNS record propagated yet? Which container is eating the memory? Will this model even load on my laptop? Each of those is a context switch — out of the terminal, into a website, back again — and each one costs a little more focus than it should.
This list is a catalogue of tools that close those tabs. None of them is a framework or a platform. Most are small, single-purpose Rust binaries that start instantly and work just as well over SSH as they do locally. What's worth writing up isn't that they're clever — it's that each one sits at a specific, recurring moment in a working day, and that's the lens I've used for every entry below.
--once drops the TUI and prints a plain table for scripts.docker ps, copy an ID, and paste it into the next command for the fifth time in an hour.values.yaml or flipping a flag in a manifest, without a fragile sed that breaks the first time the indentation changes.dnsglobe example.com # check and keep watching
yq -i '.image.tag = "v2.4.1"' values.yaml # update config in place
git log into an animation: each commit is retyped on screen with cursor movement, deletions, syntax highlighting and file-tree changes. It sounds like a novelty until you join an unfamiliar codebase and want to watch how a module grew instead of reading forty diffs. It's also genuinely good for talks — filter by author or date range and loop a commit range on a second screen.vd and you get an interactive sheet: sort, filter, aggregate, build frequency tables, edit cells. It earns its place on remote servers, where there's no GUI and the file is far too large to make sense of with less.grex -c "regexes are awesome" "regexes are awful"
# ^regexes are aw(?:esome|ful)$
This is the section I find most interesting, because both tools exist because of how AI-assisted development has changed day-to-day engineering in the last year.
wt switch, wt list, wt merge — and that suddenly matters once you're running more than one coding agent at a time. Give Claude Code or Codex each its own worktree and they stop trampling each other's changes, and your main checkout stays clean. Project hooks can install dependencies or start a dev server per worktree, so each agent gets a working environment, not just a folder.wt switch -c feature-login # new branch + isolated worktree
wt merge # merge back and clean up
node_modules, target, build, .gradle — with their sizes, then asks before deleting anything. The flag that makes it safe to run on a whole ~/code folder is --older: only touch projects you haven't modified in, say, three months.Nine of the ten are in Homebrew core; dnsglobe ships from its own tap. Worktrunk needs a one-time shell integration so wt switch can change your directory.
brew install gitlogue visidata oxker llmfit croc grex kondo worktrunk yq
brew install 514-labs/tap/dnsglobe
wt config shell install
On Linux, most of them are also a cargo install <name> or a distro package away.
It's not a "replace your whole setup" post. None of these tools asks you to change how you work — each one slots into a moment that already exists in your day and removes a single context switch from it. That's also the honest filter for whether to install any of them: if you never wait on DNS, you don't need dnsglobe; if you run one agent at a time, worktrees are overhead, not help.
If I had to pick three to start with, it would be yq for anyone who touches CI, oxker for anyone who lives in Docker, and worktrunk for anyone running agents in parallel. The rest are the kind of tool you forget about until the exact moment you need it — and then it saves twenty minutes and a browser tab.
The best tool in a terminal is the one that removes a tab you didn't realise you kept opening.