I think there's also another major reason people don't like to ship desktop software, and that's the cost of support of dealing with outdated tools, it can be immense.
Ticket as raised, "Why is my <Product> broken?"
After several rounds of clarification, it's established they're using a 6-year old version that's hitting API endpoints that were first deprecated 3 years ago and finally now removed...
It's incredibly expensive to support multiple versions of products. On-prem / self host means you have to support several, but at least with web products it's expected they'll phone-home and nag to be updated and that there'll be someone qualified to do that update.
When you add runnable executable tooling, it magnifies the issue of how old that tooling gets.
Even with a support policy of not supporting versions older than <X>, you'll waste a lot of customer support time dealing with issues only for it to emerge it's out-dated software.
Obviously it depends on your audience, and 3 rounds is exaggerating for the worst case, but in previous places I've worked I've seen customer support requests where the first question that needed to be asked wasn't, "What version are you using?", it's "Are you sure this is our product you're using?".
Actually getting version info out of that audience would have been at least an email explaining the exact steps, then possibly a follow up phone call to talk them through it and reassure them.
If your reference is JIRA tickets or you're selling software to software developers, then you're dealing with a heavily filtered stream. Ask your CS team for a look at the unfiltered incoming mail, it might be eye-opening if you've not done it before. You might be surprised just how much of their time is spent covering the absolute basics, often to people who have had the same support multiple times before.
Fast forward 12-18 months, after several new features ship and several breaking API changes are made and teams that ship CLIs start to realize it’s actually a big undertaking to keep installed CLI software up-to-date with the API. It turns out there’s a lot of auto-updating infrastructure that has to be managed and even if the team gets that right, it can still be tricky managing which versions get deprecated vs not.
I built Terminalwire (https://terminalwire.com) to solve this problem. It replaces JSON APIs with a smaller API that streams stdio (kind of like ssh), and other commands that control browsers, security, and file access to the client.
It’s so weird to me how each company wants to ship their own CLI and auto-update infrastructure around it. It’s analogous to companies wanting to ship their own browser to consume their own website and deal with all the auto update infrastructure around that. It’s madness.
I could imagine a subagent that builds a tool on demand when it's needed.
Claude is really good at building small tools like these.
When using the MCP, I have to do a whole OAuth browser-launch process and even then I am only limited to the 9-10 tools that they've shipped it with so far.
tl;dr AI-powered assistants can already use command line tools.
Usually when I mention a `tool --help` for the first time in a prompt I will put it in backticks with the --help argument.
It works really well.
The agents have a tendency to make the "Examples" section of the help message way too long by stuffing it with redundant examples, so it needs to be manually pruned from time during development if you use an agent for tool development.
`gh-install` is a fish script (using curl and jq), it was made by an agent.
gh-install -h
Usage: gh-install [-i] [-q] [-s] [-p PATH] [-n NAME] [-f FILE] [-e EXECUTABLE] <repo> [version]
-i - Show info about what would be installed (no install)
-q - Quiet mode (suppress all output except -i info line)
-s - Install to /usr/local/bin (system-wide)
-p PATH - Install to the specified directory (incompatible with -s)
-n NAME - Install with custom binary name
-f FILE - Select specific file from release assets and use as binary name (unless -n is specified)
-e EXECUTABLE - Select specific executable from extracted archive (when archive contains multiple executables)
repo - GitHub repository in format owner/name
version - Optional version tag (defaults to latest)
Examples:
gh-install cli/cli v2.40.1
gh-install cli/cli
gh-install -i cli/cli (show info only)
gh-install -i -q cli/cli (show info quietly)
gh-install -s cli/cli (install system-wide)
gh-install -p /opt/bin cli/cli (install to /opt/bin)
gh-install -n gh cli/cli (install as 'gh')
gh-install -f zed-remote-server zed-industries/zed (install server file)
gh-install -e server some-org/multi-tool (install 'server' executable from archive)
Use `gh-install -h` to install asdf, hadolint, ripgrep, fd, delta and bat.
Do x using the tools found in `./tools` (they all have a `-h` option).
Now it's locked into the cloud with piss poor APIs so they can sell you more add-ons. I'm actively looking at alternatives.
E.g. with a Jira cli tool I have to write the skill and keep it up to date. With a MCP server I can delegate most of the work.