I’ve been experimenting with ComfyUI-OpenClaw, a project that takes ideas from the upstream openclaw/openclaw ecosystem but repackages them in a way that fits ComfyUI workflows much better.
If you know the upstream OpenClaw repo: it’s closer to a general-purpose personal AI assistant platform (multi-channel chat, skills registry, gateway/control plane, tool execution, etc.). That’s cool, but if your “production surface” is ComfyUI, you probably care about a different set of problems.
What this is (in ComfyUI terms)
ComfyUI-OpenClaw is essentially:
A Custom Node pack (LLM-assisted nodes)
A small extension UI panel
A secure-by-default HTTP API for automation (webhooks / triggers / schedules / approvals / presets)
So instead of “chat assistant first, ComfyUI as one tool,” it’s more like “ComfyUI pipeline first, LLM used where it helps.”
Why it’s nicer for ComfyUI workflows (vs. the upstream platform approach)
1) ComfyUI-native automation: templates → render → queue
A lot of automation attempts end up bolting a chat agent onto ComfyUI. This goes the other direction:
treat workflows as templates/presets
let the system render parameters reliably
submit to the ComfyUI queue
observe results / callbacks without turning your setup into an open network endpoint
If you’re building repeatable pipelines, this is closer to how you actually work.
2) LLM usage is scoped to the parts you actually want
Instead of “LLM can do anything,” the focus is on practical ComfyUI tasks:
Prompt planning
Prompt refining
Image → prompt (vision)
Batch variants generation
That’s the stuff most people end up scripting anyway.
3) “Secure-by-default” design (important if you ever automate remotely)
ComfyUI is powerful, but most folks don’t want to expose it publicly. This project leans hard into:
strict localhost by default
clear separation between “read/observe” vs “admin/write” actions (tokens)
SSRF/allowlist thinking for outbound callbacks and LLM base URLs
execution budgets / rate limits to avoid runaway workloads
optional approval gates for sensitive triggers
It’s basically acknowledging: “automation + image generation rigs” are exactly where people accidentally create unsafe exposures.
4) Built for operability (not just demos)
Things like:
dry-run validation (catch issues before burning GPU time)
logs/trace visibility
failover patterns for LLM backends
payload budgets / redaction
…sound boring until you run workflows all day or hook this into other systems.
How I think about the difference vs. upstream OpenClaw
Upstream (openclaw/openclaw): a broad assistant platform with skills, channels, gateway control plane, etc.
ComfyUI-OpenClaw: a ComfyUI-first automation layer that uses LLMs as helpers, with an API surface designed to be safe and manageable.
If you want a “personal assistant OS,” upstream makes a lot of sense.
If you want “ComfyUI as a reliable automation target,” this ComfyUI-focused approach feels more direct.
If anyone here is already doing webhook/cron-based ComfyUI automation, I’d love to hear what pain points you hit (security, queue management, parameter templating, result callbacks, etc.).
https://github.com/rookiestar28/ComfyUI-OpenClaw
If anyone here is already doing webhook/cron-based ComfyUI automation, I’d love to hear what pain points you hit (security, queue management, parameter templating, result callbacks, etc.).