All GUI apps are different, each being unhappy in its own way. Moated fiefdoms they are, scattered within the boundaries of their operating system. CLI is a common ground, an integration plaza where the peers meet, streams flow and signals are exchanged. No commitment needs to be made to enter this information bazaar. The closest analog in the GUI world is Smalltalk, but again - you need to pledge your allegiance bef…
We have systems for highly interoperable and compostable GUI applications - think NextSTEP or, modern day, dbus, to a lesser extent. Really, GUIs can be formed of a public API with graphics slapped on top. They usually aren't, but they can be.
I'd say ROS (Robot Operating System) is the closest to this ideal.
Just because a popular new tool runs in the terminal, doesn't make it a shining example for the "Unix philosophy" lol. the comparison makes no sense if you think about it for more than 5 seconds and is hacker news clickbait you and i fell for :(
The top three comments I saw also all sound like they were written by an LLM that was told to advertise itself.
I do really like the Unix approach Claude Code takes, because it makes it really easy to create other Unix-like tools and have Claude use them with basically no integration overhead. Just give it the man page for your tool and it'll use it adeptly with no MCP or custom tool definition nonsense. I built a tool that lets Claude use the browser and Claude never has an issue using it.
How does Claude Code use the browser in your script/tool? I've always wanted to control my existing Safari session windows rather than a Chrome or a separate/new Chrome instance.
Most browsers these days expose a control API (like ChromeDevtools Protocol MCP [1]) that open up a socket API and can take in json instructions for bidirectional communication. Chrome is the gold standard here but both Safari and Firefox have their own driver.
For you existing browser session you'd have to start it already with open socket connection as by default that's not enabled but once you do the server should able to find an open local socket and connect to it and execute controls.
worth nothing that this "control browser" hype is quite deceiving and it doesn't really work well imo because LLMs still suck at understanding the DOM so you need various tricks to optimize for that so I would take OP's claims with a giant bag of salt.
Also these automations are really easy to identify and block as they are not organic inputs so the actual use is very limited.
You know how people used to say the CLI is dead? Now, due to tools like claude code, CLI is actually clearly the superior interface. (At least for now) It's not supposed to be an us vs them flamewar, of course. But it's fun to see a reversal like this from time to time!
I don't remember any advanced computer user, including developers saying that the CLI is dead. The CLI has been dead for end-users since computers became powerful enough for GUIs, but the CLI has always been there behind the scenes. The closest we have been to the "CLI is dead" mentality was maybe in the late 90s, with pre-OSX MacOS and Windows, but then OSX gave us a proper Unix shell, Windows gave us PowerShell, an…
There was a period in the early-mid 2000s where CLIs were considered passe and an emblem of the past. Some developers relied solely on graphical IDEs on GUI-oriented operating systems, and the transition to Linux everywhere broke that trend. Some people didn't take Linux seriously because it was CLI oriented.
How is codex now compared to Claude code? Especially with gpt 5 high for planning and codex for the coding part.
Codex CLI had some huge upgrades in the past few months. Before the GPT-5 release it was a poor imitation IMO - in the macOS terminal it somehow even disabled copy and paste! Codex today is almost unrecognizable in comparison to that version. It's really good. I use both it and Claude Code almost interchangeably at the moment and I'm not really feeling that one is notably better than the other.
Between codex and Claude code, I am using both on two entirely different projects, so it's not a fair comparison, but the two things Claude has in my unscientific testing is a better plan mode (though having to use the magic password ultrathink belies needing to learn how to prompt it properly) resulting in a better and longer Todo.md (but again, the two projects between the two are very different, so don't consider it a scientific comparison). The other thing that Claude code has that codex does not is a more advanced ability to run things in the background, both as in "npm run dev"/other webserver in the background and being able to run curl/whatever against it, and gather logs from the webserver, error message or otherwise. The other thing is Claude code can be told to run things "in sub-agents" and work on multiple things simultaneously. If there is a way to get codex to do it, it won't tell me and says it can't do that. Not that I necessarily believe it. My experience with codex is that, despite instructions in agents.md, it'll forget and get its wires crossed. I'm using --model gpt-5-codex, and codex reports version 0.42.0.
That is a bit of a simplification, many users found value in wysiwyg, there was an aborted low-code visual programming movement. Microsoft drank early OOP koolaid and thus powershell suffered from problems that were well covered by the time etc… Ray Norda being pushed out after WordPerfect bought Novell with their own money and leveraged local religious politics in addition to typical corporate politics killed it. In…
This is kind of my "CLI bigotry" showing, but I think programming was always, quite naturally, a command-line occupation, but there was this brief period starting in the late 90s where a sizable number of practitioners were seduced by things like Visual Studio and Eclipse, and went over to the dark side. But nature is slowly restoring itself, and we're moving back to software development being text based tools inside…
Automation and scripting won. The GUI was useful for the end user and, yes, VB was everywhere, but for tedious tasks the CLI it's still far superior and the TUI responsiveness was unmatched against the most powerful GUI.
I do really like the Unix approach Claude Code takes, because it makes it really easy to create other Unix-like tools and have Claude use them with basically no integration overhead. Just give it the man page for your tool and it'll use it adeptly with no MCP or custom tool definition nonsense. I built a tool that lets Claude use the browser and Claude never has an issue using it.
I updated this thing that searches manpages better recently for the LLM era: