CLI-Anything: generated command-line interfaces for Blender, GIMP, LibreOffice and other desktop apps

The problem CLI-Anything targets: desktop software has no agent-facing API

Most desktop applications expose their functionality through a GUI, a plugin SDK, or a scripting language that differs per product. Blender has Python, GIMP has Script-Fu and Python, LibreOffice has UNO and headless conversion flags, Audacity has macros. An agent that wants to edit a 3D scene, retouch an image, or convert a document has to learn a different interface for each one, and several of those interfaces are not designed to be called in a loop.

CLI-Anything's answer is to put a command-line layer in front of each application. The README frames the project as making software agent-native, and the repository layout reflects that: blender/, gimp/, inkscape/, audacity/, libreoffice/, kdenlive/, krita/, freecad/, godot/ and many more directories sit at the top level, each holding a harness for one product. The intended user is someone wiring an agent such as Cursor, Claude Code, Pi or OpenClaw into a real desktop tool and needing something more structured than clicking coordinates.

The scope claim is broad. The README says "Making ALL Software Agent-Native" and describes the project as bridging the gap between AI agents and the world's software. Treat the breadth as a direction rather than a finished guarantee: the registry mixes recently merged harnesses with proposals, and the news entries distinguish between CLIs that were proposed and CLIs that were merged.

How a harness works: per-application CLIs plus a skill file for the agent

The repository is not a single binary that introspects arbitrary applications. It is a collection of per-application harnesses, each written in Python, plus shared packaging and documentation layers. A harness directory contains the command implementation for one product, and the news entries describe what each one covers: the QGIS entry is described as a full GIS and map authoring harness, the Calibre entry lists library, search, metadata, conversion and export workflows, the Rekordbox entry mentions guarded SQLCipher write paths and backup-required forced writes.

Alongside the code sits a skill file. The 2026-04-18 news entry states that all SKILL.md files are being unified under a top-level skills/ directory, so a skill can be installed from one canonical source with npx skills add. That file is what tells an agent which commands exist and how to call them. The agent does not discover the interface by reading source; it reads the skill description and issues commands.

Two supporting pieces sit around the harnesses. cli-hub/ is the registry and installer frontend, published as cli-anything-hub on PyPI, and cli-hub-meta-skill/ plus cli-hub-matrix/ hold the generated meta-skill and coverage data. The registry also carries public CLIs that are not part of the repository itself: the v0.2.0 notes describe support for install sources including pip, npm, brew, and bundled or system tools, backed by a public_registry.json. So the install path for a given name can be a third-party package rather than code in this repository.

Installing CLI-Anything and running a first command

The README gives the hub as the entry point. The package name is cli-anything-hub and the install command is pip install cli-anything-hub. After that, cli-hub install <name> installs an individual CLI from the registry, where <name> is a registry entry rather than an arbitrary application name.

pip install cli-anything-hub
cli-hub install <name>

According to the README, the hub covers browsing, installing and managing community-built CLIs, so the same tool is used for updates and removal. The v0.2.0 release notes mention that live end-to-end checks cover real install, update and uninstall flows across pip and npm packages, which tells you those three operations are the intended lifecycle.

Skills are installed separately. The 2026-04-18 news entry gives this command, with -g for a global install and -y to skip the prompt:

npx skills add HKUDS/CLI-Anything --skill <skill-name> -g -y

Replace <skill-name> with the skill for the application you installed. The entry says the skills are unified under the top-level skills/ directory, so the name should match a directory there. What you should see after both steps is a command on your PATH that drives the target application, and a skill file your agent tool can load. If the CLI you installed comes from the public registry rather than this repository, the underlying package is whatever that registry entry points at, and the repository's own tests do not cover it.

Where the per-application model breaks down

The main limitation is uneven depth. Because each harness is a separate contribution, quality is not uniform across the registry. The news entries themselves show the spread: some CLIs are described with test counts and end-to-end evidence, others are listed as proposed, and others received compatibility fixes after release, such as the Kdenlive entry for Gen 5 project output and invalid project generation, or the LibreOffice entry for headless conversion on macOS. A fix entry is normal maintenance, but it also means the initial version did not handle that case.

Security posture also varies by target. The 2026-05-19 entry notes that XML, SVG, ODF, MLT, MusicXML and CSL parsing now routes untrusted input through defusedxml, and the Sketch CLI entry describes hardening token-file handling against path traversal and symlink escapes. Those are fixes applied after the fact, which suggests that harnesses written against document or media formats should be reviewed for how they parse input before you point them at untrusted files.

There is also a category error to avoid. CLI-Anything is the wrong tool if you want one stable API surface that behaves identically across applications. It is a set of adapters, and each adapter inherits the quirks of the program underneath it. If your workflow only touches one application, a direct script against that application's own scripting interface is usually less machinery. The project earns its place when you need several applications behind a consistent command shape.

CLI-Anything compared with MCP servers

The obvious alternative for agent-driven tool use is an MCP server per application, and the repository sits close to that space rather than far from it. The news entries mention an Unreal Editor MCP self-extension workbench and a safari-mcp based Safari CLI, so MCP appears in the registry as a transport for some targets.

The difference is where the interface lives. An MCP server exposes tools over a protocol to an MCP-capable client, and the tool schema is the contract. CLI-Anything exposes commands on the command line, and the SKILL.md file is the contract. A command-line interface can be invoked from a shell, from a script, or from an agent that has no MCP support, and its output can be piped into other Unix tools. An MCP server cannot be piped, but it gives a client structured schemas and often a persistent connection to the application.

That makes the two complementary rather than strictly competing. If your agent already speaks MCP and the application has a maintained MCP server, adding a CLI layer is extra surface. If your agent works through a shell and the application has no MCP server, the generated CLI is the shorter path. The registry's willingness to include MCP-backed entries suggests the maintainers do not treat the two as mutually exclusive.

Licence, maintenance and what an upgrade costs you

The repository is licensed Apache-2.0, with the LICENSE file at the top level. Apache-2.0 includes an explicit patent grant and requires that modifications carry notices, which matters if you fork a harness and redistribute it inside a product. Individual CLIs pulled from the public registry are separate packages and may carry different licences; the repository does not state that the registry normalises them, so check the package you actually install. None of this is legal advice.

The last push to the default branch was on 2026-06-25, which is also the date of the v0.4.0 release. Releases have come roughly every one to two months across v0.2.0, v0.3.0 and v0.4.0, and the news log shows a high rate of merges and proposals through May 2026. The repository is not archived.

Upgrade cost is the real question, and it depends on which layer you depend on. The hub is a PyPI package with its own version, so upgrading it changes registry behaviour, including which install source a name resolves to. The harnesses are directories in the repository, so upgrading one means pulling new code for that application and re-checking that your agent's skill file still matches the commands. The 2026-04-18 reorganisation of SKILL.md files under a single skills/ directory is exactly the kind of change that breaks a pinned skill path, so pin the skill you install rather than tracking main.

Editorial conclusion

Adopt CLI-Anything if you already drive desktop tools from an agent and want a structured command layer instead of screen-level automation, and start with a harness that has merged tests rather than the whole registry. Skip it if you need one stable, versioned API across every application, because each harness is a separate contribution with its own maturity. Before committing, read the harness directory for your target app, check whether its SKILL.md is synced under the top-level skills/ path, and confirm which install source cli-hub resolves for that name.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes