cm-cli REST API

First, the name is a lie - and the good kind. cm-cli REST doesn't call any external API and it doesn't need a key. It's the reverse: it wraps two command-line tools that manage your ComfyUI install - cm-cli (the CLI that ships inside ComfyUI-Manager) and comfy-cli (Comfy Org's own CLI) - and exposes them as HTTP endpoints on ComfyUI's built-in server. Install it, restart, and curl http://localhost:8188/cm-cli-rest/health answers back on the same port you already use. No separate process, no token, no cloud.

Why you'd reach for it

The pitch is scripting. If you've ever wanted to update all your nodes from a cron job, install a pack without touching the Manager UI, or point a home-assistant-style dashboard at your ComfyUI box, this gives you a clean HTTP surface for it. The README leans hard on the two CLIs it wraps: cm-cli covers node management (install, uninstall, update-all, enable/disable, fix dependencies, snapshots), and comfy-cli adds model download and listing. Long operations run asynchronously with a job id, so you fire off an install and poll /cm-cli-rest/jobs/<id> until it's done.

Real talk: most people will never use this. If you only ever manage nodes from the Manager UI in your browser, this pack solves a problem you don't have. It earns its keep the moment you want ComfyUI to manage itself from outside - automation, remote management, or a workflow that kicks off an update and then waits for it.

The honest catch: the node is a stub

Here's the part the README buries. The CMCLIRest node you drag onto the canvas isn't what does the work. It's a thin trigger with three hardcoded endpoint choices, and its execute doesn't make a real HTTP call - flip trigger on and it returns the string "Use REST API at /cm-cli-rest/<endpoint>" with success = true. That's it. It's a bookmark that reminds you which endpoint to curl, not a functional client.

That's worth knowing before you build a workflow around it. The real feature is the REST API mounted on ComfyUI's server (PromptServer.instance.app), and the code paths that matter - the async subprocess executors in cm_cli/ and comfy_cli/ - live outside the node entirely. Treat the node as a nice-to-have and the API as the product.

The inputs and outputs

The node itself is simple, and the only field you'll touch is endpoint, an enum with exactly three choices:

• health - ping the service, returns a status payload
• list_nodes - the cm-cli equivalent of "what's installed"
• update_all - kick off the update-everything job

trigger is a BOOLEAN (default false) - set it to true to fire the call when the workflow runs. There's also an optional node_name STRING for naming a specific node, though the current shipped code doesn't actually use it in execute, so don't rely on it doing anything yet.

Outputs: response (STRING) carries the message, and success (BOOLEAN) is false until a trigger fires. You can wire response into a text display node if you want the message on your canvas; mostly you'll ignore both.

Installing it

Two roads, same destination. In ComfyUI Manager, search for cm-cli-rest and install. Or the manual way:

cd ComfyUI/custom_nodes
git clone https://github.com/fno2010/cm-cli-rest

Then restart ComfyUI. No model files, no heavy downloads - the requirements.txt is essentially empty because everything it needs is already in ComfyUI. The real prerequisites are ComfyUI 0.15+ and ComfyUI-Manager 4.0+ (that's what provides cm-cli). Model management via comfy-cli is optional:

pip install comfy-cli

If you skip it, the /cm-cli-rest/* endpoints still work; only the /comfy-cli/* model routes fail.

Troubleshooting

The failure modes are all "the CLI isn't there" problems. CM_CLI_NOT_FOUND means Manager isn't installed or its version predates cm-cli - install or update it. COMFY_CLI_ERROR means you forgot pip install comfy-cli. Port issues don't exist: it rides ComfyUI's own port, so no firewall rules beyond what you already have.

One more thing worth saying, because it's the standard warning around anything that wraps Manager: this pack shells out to CLIs that install and update arbitrary node packs. It's only as trustworthy as the pack itself and the packs you point it at - on an exposed instance, set an api_key in config/config.json before you let it listen on anything but localhost. And remember, a node pack is arbitrary Python running as you, so read the repo before you hand it control of your installs.

It's a niche tool, and honestly that's fine. But if you've ever wanted to script your node hygiene, this is the cleanest way to do it - just don't expect the canvas node to be the whole story.