ComfyUI-OpenClaw: A Hardened Control Plane for ComfyUI Automation

The gap ComfyUI-OpenClaw fills between a prompt endpoint and a scheduled pipeline

Stock ComfyUI exposes routes such as /prompt, /history, /view, /upload and /ws, and those routes are owned by ComfyUI itself. They work well for a browser session. They are a poor fit when something other than a human at a keyboard needs to start a job: a webhook from a chat platform, a schedule, or an approval step where a second person signs off before the render runs. ComfyUI-OpenClaw registers its own routes into the same PromptServer application and adds the pieces that decision implies. The README lists approvals, schedules, presets, webhook and assist flows, a model manager, and rewrite recipes. The intended audience is an operator running ComfyUI as shared infrastructure, not a single user generating images on a laptop. The project description calls it a personal AIGC factory, but the architecture described in the README points at multi-tenant use: tenant mismatches are said to fail closed across config, secret sources, connector installations, approvals, visibility, and execution budgets.

One Python process, two route planes, and an optional sidecar

The architecture diagram in the README is the clearest part of the documentation. ComfyUI runs as a single Python process with a shared aiohttp app. The OpenClaw package loads from custom_nodes/comfyui-openclaw and registers three route groups into that same app: /openclaw/*, an /api/openclaw/* shim for browser and API callers, and legacy aliases under /moltbot/* and /api/moltbot/*. That alias set is worth noting if you are migrating from an earlier name, because the old paths still resolve. Alongside the routes, the package carries security and runtime modules (startup gate, RBAC, CSRF, HMAC, audit, SSRF controls), automation services, state and secrets under openclaw_state/*, the embedded frontend extension, and the exported nodes. The connector sidecar sits outside the ComfyUI process entirely and reaches OpenClaw over HTTP. That split is the design decision the README returns to most often: the operator UX is embedded, and the high-risk control surfaces are externalized. The practical consequence is that killing the sidecar stops chat-platform ingress without stopping ComfyUI itself, which is a cleaner failure mode than routing platform traffic through the render process.

Installing the node pack and reaching the admin console

The README gives the install location rather than a package command: the pack loads from custom_nodes/comfyui-openclaw, which is the standard ComfyUI custom node path. Beyond that path, the supplied material does not include a pip invocation, a requirements file listing, or a git clone line, so treat any install steps you see elsewhere as unverified against this repository. What the README does specify is the surface you reach afterwards. The embedded extension appears as OpenClaw sidebar tabs inside the ComfyUI interface, and the standalone Remote Admin Console is served at /openclaw/admin for mobile or remote browser use. Automation callers use /openclaw/* or the /api/openclaw/* shim. State and secrets are written under openclaw_state/*, which is the directory to include in backups and to keep out of version control. For deployment posture, the README points at docs/security_deployment_guide.md, docs/runtime_hardening_and_startup.md, docs/security_key_lifecycle_sop.md, docs/security_checklist.md, and docs/release/threat_model.md. Those files are named but not reproduced here, so the specific profile names and environment variables they define cannot be confirmed from this material.

Fail-closed defaults are the feature and the cost

The README is explicit that public and hardened postures are fail-closed by design, enforced through shared-surface acknowledgement, startup gates, route-plane governance, and the control-plane split. Read that as a warning about first-run experience. A fail-closed system does not degrade quietly into a working state. If a shared surface has not been acknowledged, or a tenant binding does not match, the documented behaviour is rejection rather than fallback. That is the right call for a host that other people can reach, and it is friction for a host that only you can reach. The same applies to outbound egress: callback delivery and custom LLM base URLs sit behind SSRF-safe validation, exact-host policy, a scoped private-network allowance, and what the README calls explicit insecure overrides. If your LLM endpoint lives on a private address, you will be configuring that allowance rather than discovering it. Secret handling follows the same pattern: browser storage is not used for secrets, local secret-manager integration is opt-in, and connector multi-workspace and multi-account bindings are secret-ref-only. The design assumes an operator who reads the deployment guide before the first render, not after.

Where ComfyUI-OpenClaw is the wrong tool

The clearest mismatch is a single-user ComfyUI instance bound to localhost. Every control the README describes (RBAC, CSRF, HMAC, audit, startup gates, tenant isolation) exists to constrain access that a localhost-only setup does not grant in the first place. You would carry the configuration surface without the threat it addresses. A second mismatch is a team that wants chat-platform ingress and nothing else. The connector sidecar is described as an optional attached subsystem, and ADR-0003 is titled around connector extraction feasibility and split-package seams, which suggests the maintainers have considered separating it. Until that split lands, chat ingress arrives bundled with the node pack, the admin console, and the security modules. The third and least obvious mismatch is operational. The README states that verification is part of the security model, with route drift checks, coverage governance, adversarial fuzz and mutation gates, and doctor and compatibility diagnostics wired into CI-parity workflows. Those gates protect you when you upgrade, and they also mean upgrades are not drop-in. The v1.0.0 to v1.1.0 interval ran roughly six weeks, and v0.9.5 to v1.0.0 ran about six weeks as well. A cadence in that range with hardening gates attached implies you should read release notes and run the doctor diagnostics before replacing a working install.

How it differs from a thin ComfyUI API wrapper

The common alternative is a small service that wraps ComfyUI's existing HTTP API: it posts to /prompt, polls /history, and fetches results from /view. That approach adds no code inside the ComfyUI process, which makes it easy to reason about and easy to redeploy. It also inherits ComfyUI's trust model unchanged, so whatever network position ComfyUI occupies becomes the wrapper's network position. ComfyUI-OpenClaw takes the opposite route. It registers routes inside the PromptServer app, so its admin boundary and its render engine share a process and a lifecycle. The trade is real in both directions. A wrapper cannot enforce an approval step, a tenant boundary, or a signed callback envelope, because it does not sit in the request path. ComfyUI-OpenClaw can, and it pays for that with a larger blast radius if the process is compromised and with an upgrade path that depends on ComfyUI internals staying stable. If your threat model is a shared host with untrusted callers, the wrapper is the weaker option. If your threat model is a laptop, the wrapper is the smaller one.

Licence, connector scope, and what to verify before committing

The repository is MIT-licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That covers the code. It does not cover the terms of the eight messaging platforms the connectors target (Discord, Telegram, WhatsApp, LINE, WeChat, KakaoTalk, Slack, and Feishu/Lark), each of which has its own developer agreement and rate policy. The README does not reproduce those terms, and nothing here should be read as legal advice. On scope, the README names ADR-0002 as the record for the product boundary and packaging contract, and ADR-0003 as the record for connector extraction feasibility. Both are worth reading before you plan a deployment, because they determine whether connectors are part of the node pack you install or a package you add separately. The last thing to verify is the alerting behaviour. The release notes describe a fix where dismissing a notification previously suppressed any identical alert for the life of that browser profile, and where producers now resolve conditions that have ended so genuine recurrences show again. If you run the admin console unattended, that distinction decides whether a connectivity failure stays visible or disappears after one dismissal.

Editorial conclusion

Adopt ComfyUI-OpenClaw if you already run ComfyUI on a host reachable by other people and you need webhook triggers, approvals, or chat-platform ingress with an explicit admin boundary. Do not adopt it if you only want a few convenience nodes on a localhost-only machine, because the startup gates, RBAC, HMAC and SSRF controls described in the README assume a deployment posture you would be paying for without using. Before installing, read docs/adr/ADR-0002-product-boundary-and-packaging-contract.md and docs/adr/ADR-0003-connector-extraction-feasibility-and-seams.md to confirm whether the connector sidecar is a separate package in your version, then open docs/security_deployment_guide.md and docs/security_checklist.md and verify that the fail-closed defaults match how your ComfyUI instance is exposed.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rookiestar28/ComfyUI-OpenClaw on GitHub