# CLI-Anything lets a merged pull request become an agent's tool, instantly > An Apache-2.0 Python project that generates command-line interfaces for desktop applications so agents can drive tools like Blender, GIMP, Audacity and LibreOffice through structured commands. Its registry is a pull request away from installable, several shipped harnesses keep an encrypted database or persistent memory, and the news log reads as a security changelog covering path traversal, untrusted XML and a registry aliasing bug. **HKUDS/CLI-Anything** — CLI-Anything generates command-line interfaces for desktop applications so agents can operate tools such as Blender, GIMP, Inkscape, Audacity, and LibreOffice through structured commands. - Repository: https://github.com/HKUDS/CLI-Anything - Website: https://clianything.cc/ - Stars: 50,991 · Forks: 4,654 - Language: Python - License: Apache-2.0 - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/hkuds-cli-anything ## A merged pull request becomes an installable harness, and the readme says so The distribution model is the thing to understand first, and it is stated in a single line. There is a hub package you install from the package index, and then a command that installs a named harness from it. ```bash pip install cli-anything-hub ``` ```bash cli-hub install ``` You can browse, install and manage the community-built harnesses through it, and the invitation to contribute comes with the promise that the hub updates instantly once a pull request is merged. The consequence is a supply-chain shape that differs from a normal package registry. There is no release train and no staged rollout between a harness being written and an agent being able to install it. Review is the only gate, and review is a human process with a queue. If you are letting an agent install harnesses, that is the property to design around: pin what you have, and treat a new arrival as unreviewed until you have read its own changelog. ## Several harnesses keep state, which widens what an agent mistake can damage It is easy to read a command-line harness as a stateless wrapper, and the registry entries show that several are not. One proposed entry for a note-taking application is described as coming with persistent agent memory workflows, which means state survives between runs. Another, for a music application, merged with guarded write paths into an encrypted database and with forced writes that require a backup first. A third, for an office suite, runs headless conversion and had its macOS path described as made more robust. The consequence is that the blast radius of a wrong command is not always a failed process. A harness that keeps memory accumulates, so a mistake compounds across sessions, and a harness that writes to an encrypted database touches the user's actual library rather than a scratch file. Before you let an agent loop against one of these, find out whether it keeps state, and if it does, whether you would rather run it against a copy. ## The news log is mostly a security and correctness changelog Read the dated news entries as a description of the risk surface, because that is what they mostly are. A token file in a vector graphics harness was hardened against path traversal and symlink escapes. Parsing of XML, SVG, ODF, MLT, MusicXML and CSL was rerouted through a hardened XML parser specifically because the input is untrusted. The hub's own registry handling was fixed so entries are copied before they are tagged, which stopped cached or mocked registry data being mutated in place. There is a fix for a crash in an interactive start-up banner, a fix for package extraction in skill generation, and a fix for a render duration in a video editor. The consequence is a useful one: the interesting engineering in this project is defending other people's file formats against an agent that will try anything. It also means the fixes matter. Running a harness from before these entries means running the version where a crafted file could escape a token directory. ## The last tag is from June, and the fixes since then are on the branch The release history has three entries and stops. Version 0.2.0 in late March, version 0.3.0 in late April, version 0.4.0 in late June, and then nothing, while the last push to the main branch was in September. So the newest tag is roughly three months behind the tip, and the news entries that matter for security are dated May, which is after the last release. The consequence is that pinning the latest release gives you a tree without the registry aliasing fix, without the hardened XML routing and without the path traversal fix. The project is also pre-1.0, so the minor bumps can carry behaviour changes rather than only additions. For an evaluation this is fine, because you are reading the branch anyway. For a deployment it is the decision point: take the branch, record the commit, and understand that you are running something newer than anything the project has labelled. ## Skills moved under one directory in April, which retires older install commands One news entry is a migration rather than a fix, and it invalidates anything you saved before it. It records that all of the skill description files are being unified under a single top-level directory, so that every skill can be installed from one canonical source, and it gives the command for that, installing a named skill globally and non-interactively. The same entry mentions new validation in continuous integration for the root skill, refreshed contribution documentation, and a hub frontend rebuilt around the new flow. Two more entries a day earlier and the day after clean up the contribution paths and the skill generator's handling of empty files. The consequence is that install instructions from before April point at the old layout and will quietly fail or install the wrong thing, and that the project is mid-migration on a path that affects every harness rather than one. If you are following a tutorial written against an earlier layout, that is the first thing to check. ## The same project ships four plugin manifests for different agent harnesses Look at the top level and the integration surface is as varied as the registry. There are plugin manifests for three named harnesses, plus separate top-level directories for a plugin, a cursor plugin, a codex skill, a meta-skill for the hub itself, and a matrix of hub state. Alongside those sits a machine-readable registry file, and a long tail of per-application directories, one each for the tools being bridged, including the 3D, vector, audio, office, geographic information system, molecular modelling, game engine and note-taking applications named in the entries. The consequence is that the readme's claim of one command line for many harnesses is thinner than it sounds. A harness is a directory, a skill file and a manifest, and the shape differs by target, so before you plan an integration you need to establish which of these shapes your own tooling expects, because there is more than one and the project supports all of them. ## A generated CLI still needs the application, and often a headless path through it The premise is that a graphical application becomes agent-operable by putting a command-line interface in front of it, and that premise carries an obvious cost the demos do not show. The host application has to be installed, licensed where relevant, and reachable from whatever account the agent runs as. Several entries make the second half explicit. A molecular modelling harness and a geospatial authoring harness imply large domain-specific installs, and an office suite harness has to drive conversion through a headless path that the project has had to repair on more than one operating system. A workbench for a game engine pairs a self-extension surface with a command-line proxy, and a mapping entry pairs a scripting API with workflows described as live. The consequence is that a harness is a bridge rather than a replacement. It lowers the cost of driving the software; it does not remove the software, and the application's own quirks still surface through the bridge. ## Conclusion Adopt CLI-Anything when you have a desktop application an agent genuinely needs to operate and nobody has published a command-line interface for it, because building the bridge yourself against a scripting interface is the expensive part and this automates it. Do not adopt it as a way to obtain trusted tooling, because the registry is community-built and the readme says the hub updates instantly on merge, so what your agent can install is decided by a review rather than a release. Two things to weigh before you wire a harness into an agent loop. Some of them are not stateless: one ships persistent agent memory and another writes to an encrypted database with backup-gated writes, so an agent mistake has somewhere to land. And the changelog is full of file-format hardening, which means the earlier versions of those paths were reachable and you should take the current branch rather than the last tag. ## FAQ ### What is CLI-Anything? It is an Apache-2.0 Python project that generates command-line interfaces for desktop applications, so agents can operate tools such as Blender, GIMP, Inkscape, Audacity and LibreOffice through structured commands. The aim stated in the readme is making software agent-native, with demos covering CAD builds, 3D scenes, diagrams, gameplay and subtitles. ### How do I install CLI-Anything? For the community hub, install the hub package and then install a named harness from it. Individual skills are installed from a single canonical source under a top-level skills directory, using the skills command with the project, a skill name, and flags to install globally and skip confirmation. Both layouts changed in April 2026. ### What does CLI-Anything actually do? It builds a command-line bridge to an application that only offers a graphical interface, so an agent can drive it. Harnesses exist for a long tail of applications, and they are contributed by the community through a pull request, after which the readme says the hub updates instantly. ### How does CLI-Anything compare with MCP? The documentation does not set up a comparison. What is visible is that both appear together in some registry entries: a mapping entry is described as a command-line tool with live scripting workflows, and a game engine workbench is described as a self-extension surface paired with a command-line proxy. So for some applications the project ships the two side by side rather than choosing between them. ## Sources - [Official documentation](https://clianything.cc/) - [Official README](https://github.com/HKUDS/CLI-Anything#readme) - [Project repository](https://github.com/HKUDS/CLI-Anything) - [Release notes](https://github.com/HKUDS/CLI-Anything/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hkuds-cli-anything