ComfyUI-OpenClaw: a ComfyUI node pack that registers its own routes into the host server and treats every callback as untrusted

It mounts its routes into ComfyUI's own server, in one Python process

The packaging decision explains most of the security design. ComfyUI-OpenClaw is a custom node pack loaded from custom_nodes/comfyui-openclaw, and it does not run its own web server. It registers OpenClaw-managed routes into the same PromptServer aiohttp application that ComfyUI core already runs, in a single Python process with a shared aiohttp app. The shape of that arrangement:

ComfyUI Process (single Python process + shared aiohttp app)
│
├── ComfyUI Core (owned by ComfyUI)
│   ├── Native routes: /prompt, /history, /view, /upload, /ws, ...
│   └── Execution engine + model runtime
│
└── OpenClaw package (loaded from custom_nodes/comfyui-openclaw)
    ├── Registers OpenClaw-managed routes into the same PromptServer app:
    │   ├── /openclaw/*
    │   ├── /api/openclaw/* (browser/API shim)
    │   └── Legacy aliases: /moltbot/* and /api/moltbot/*

Because ComfyUI core owns the process, OpenClaw sits beside it rather than in front of it, which is what lets a web extension panel, a remote admin console at /openclaw/admin and an automation API all share one port and one lifecycle. The product boundary is written down rather than implied: the primary artifact is a ComfyUI custom node pack, the first-class runtime identity is an embedded operator platform, and the optional attached subsystem is a connector-capable control surface reached through a sidecar runtime. Two decision records cover that split, one on the product boundary and packaging contract and one on connector extraction feasibility.

Three namespaces answer on the same port, and one of them is a legacy alias

Look at the route list again and there are three namespaces, not one. The first is /openclaw/*, the managed surface itself. The second is /api/openclaw/*, described as a browser and API shim, which exists so the frontend and external callers get JSON without being handed the privileged plane. The third is the one worth pausing on: legacy aliases at /moltbot/* and /api/moltbot/*. A previous name is still being served, in both the privileged and the shim shape, which means a deployment that exposed /moltbot before the rename has not lost that surface just by upgrading the pack. Nothing in the written material says whether the aliases can be turned off, and for a project whose stated posture is fail-closed by design, an unremovable second name on the privileged plane is the kind of detail you want confirmed rather than assumed. Route-plane governance is listed as one of the controls that reduce accidental exposure, and route drift checks are wired into CI-parity workflows, so the plane is treated as something that can silently widen.

Tenant mismatches fail closed across config, secrets, approvals and budgets

Multi-tenancy is where the fail-closed stance is most concrete, because it is the place where a quiet fallback would be most expensive. The stated rule is that multi-tenant mode is isolation-first, and that tenant mismatches fail closed across seven surfaces: configuration, secret sources, connector installations, approvals, visibility, and execution budgets. The same posture extends to bindings, where multi-workspace and multi-account connections are secret-ref-only and fail closed by design, so a tenant or binding mismatch degrades to an explicit rejection path instead of silently reusing the wrong installation context. That last phrase is the whole design in six words: the failure mode being avoided is not an error, it is a success returned from the wrong account. The same reasoning shows up on the connector side, where ingress keeps allowlist and policy checks as first-class controls and a degraded or public posture is handled deliberately rather than by quietly widening access. Admin writes, webhook ingress and bridge worker paths are called out as explicit trust boundaries rather than convenience-only localhost helpers, which is the distinction that matters when the same code runs on a laptop and on a public host.

A chat button is admin intent, so callbacks are signed and replay-guarded

Interactive connector actions are treated as a security boundary rather than as a feature, and the mechanism is stated plainly. Callback-capable platforms use signed envelopes, timestamp and replay guards, dedupe, and explicit policy mapping, instead of trusting a button press as implicit admin intent. That is a correct read of the problem: an approval button in a messaging app is an unauthenticated request from the outside, and the person who presses it is not the person who deployed the server. The second half of the design is quieter and just as important. Connector reply visibility is policy-driven, so silent, internal, tool-only and no-mention replies can be suppressed, and that suppression does not bypass allowlists, replay checks, approvals or action-button delivery. In other words, hiding a message is a presentation decision layered on top of the authorization decision, never a way to skip it. That distinction is the one to check for in any system that lets you manage infrastructure from a chat app, and it is stated here rather than left for you to infer from the behaviour.

Secrets never enter browser storage, and two dependencies justify themselves inline

Secret handling is server-side by construction, and the stated reasons are worth repeating because they are the kind of thing that erodes. Browser storage is not used for secrets, local secret-manager integration is opt-in rather than assumed, and secrets-at-rest and token lifecycle controls are treated as operational boundaries, with a dedicated security key and token lifecycle standard sitting in the documentation alongside the deployment guide, the checklist, the runtime hardening notes and the threat model. The dependency list is unusually small for what the project does, and the packaging file explains each entry in a comment. cryptography at 41.0 or newer is required for Fernet AEAD secrets-at-rest encryption, tagged S57 in the source. defusedxml at 0.7.1 or newer is required for scanner-recognised fail-closed WeChat XML parsing, tagged S85. A third package, pycryptodomex at 3.20 or newer, sits in an optional group for WeChat AES encrypted ingress and is lazy-imported, needed only when the encrypt type is AES. That is the entire declared runtime surface, and the standalone requirements file exists only to mirror it, with a comment instructing that the two stay aligned.

Your own LLM base URL sits behind SSRF validation, which is the setting you will fight

One control has an operational cost worth planning for. Outbound egress is constrained: callback delivery and custom LLM base URLs stay behind SSRF-safe validation, exact-host policy, scoped private-network allowance and explicit insecure overrides. Read that as a list of gates rather than a list of protections. If you point ComfyUI-OpenClaw at a model server on your own machine or inside your own network, you are asking for a private-network allowance, and if you want validation switched off you are asking for an insecure override that someone has to make on purpose. Both of those are the correct design for a package that will end up on a public host, and both of them will look like friction the first time you configure it. The same reasoning governs reply suppression and egress independently, which is worth keeping straight: a reply you suppress is a message the user never sees, whereas an egress restriction is a request the process never makes. Diagnostics and runtime guardrails are kept explicit and tamper-evident even where operator-facing payloads default to redaction, so the audit trail survives the redaction policy.

A dismissed alert used to silence connectivity errors for the life of the profile

The tracked changes section is where the real behaviour shows, and one entry is worth quoting in detail because it describes a genuine design bug rather than a missing feature. Previously, dismissing a notification left a permanent record that suppressed any identical alert for the life of that browser profile, so dismissing a connectivity error silently disabled connectivity errors for good. The fix is that producers now resolve a condition that has ended, which clears the record so a genuine repeat can surface. Read as an architecture lesson, the failure was a dismissal treated as a state change on the client rather than as a view of a condition owned by the producer, which meant the user interface had become the memory of the system. The same release notes show the same instinct applied elsewhere. A saved 3D output exposed through both a 3d key and a legacy result key now appears once in history parsing and the Jobs view while distinct outputs stay separate. Host timeouts report as timeouts without retrying the request, caller cancellation stays distinct, and ordinary eligible GET failures keep bounded retries. The prose cuts off mid-sentence in the middle of this entry.

Manifest 1.2.3 against a v1.1.0 tag, with Node 18 running the browser tests

The version story is worth pinning down before you install anything. Three releases are published: v0.9.5 on 2026-05-31, v1.0.0 on 2026-07-10 and v1.1.0 on 2026-08-19. The packaging metadata declares version 1.2.3, so the source tree is ahead of the newest tag, which is normal for a project whose default branch carries unreleased work but means the version in the repository and the version you install from a tag are different things. The repository also carries a ComfyUI publisher identity block, which is how ComfyUI itself discovers custom node packs, and that is separate from the release tags again. On the tooling side, the JavaScript package is marked private, which is why there is nothing to install from npm, and it exists for the browser tests. Node 18 or newer is required, with Playwright, jsdom and Vitest as the three dev dependencies, and the test scripts split into a Playwright runner, a stress variant and a unit run. There are two Playwright configuration files, a normal one and a real-host one, and the tracked changes confirm the distinction: the refreshed ComfyUI core was exercised against its bundled frontend and a verified standalone release, while the later frontend source checkout and both Desktop surfaces are explicitly recorded as separate and unexecuted.

Editorial conclusion

ComfyUI-OpenClaw is worth evaluating if you intend to drive image and video generation from somewhere other than the ComfyUI canvas, because it treats every remote path as a trust boundary and the documentation is specific about how. A chat button on Telegram that can approve a generation job is an admin action with a user interface, and this project signs those callbacks, replays guards them, and refuses to let a suppressed reply bypass an approval. The costs are real and they are design costs, not bugs. Your own LLM base URL sits behind SSRF-safe validation with exact-host policy, so pointing it at a local endpoint is an explicit override rather than a default. Secrets never enter browser storage, which is correct and means the admin console is useless without the daemon behind it. Before you install, check three things: that your ComfyUI version and its bundled frontend are ones the project has actually exercised, since the tracked changes name specific frontend releases as verified, that the two runtime dependencies sit comfortably next to whatever your ComfyUI environment already pins, and that the version you install matches the version you read about, because the manifest sits ahead of the newest tag.

Frequently asked questions

Official sources

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