ComfyUI-OpenClaw：自动化图像工作流

Your own personal AIGC Factory. Any picture. Any reel. The Comfy way. ©️

ComfyUI-OpenClaw ComfyUI-OpenClaw is a security-first orchestration layer for ComfyUI that combines hardened automation APIs, embedded operator UX, and production deployment controls: LLM-assisted nodes (planner/refiner/vision/batch variants) A built-in extension UI (OpenClaw panel) A standalone Remote Admin Console (/openclaw/admin) for mobile/remote browser operations A secure-by-default HTTP API for automation (webhooks, triggers, schedules, approvals, presets, rewrite recipes, model manager) Public-ready control-plane split architecture (embedded UX + externalized high-risk control surfaces) Verification-first hardening lanes (staged coverage governance, test-debt governance, route drift, real-backend E2E, adversarial fuzz/mutation gates) Now supports 8 major messaging platforms, including Discord, Telegram, WhatsApp, LINE, WeChat, KakaoTalk, Slack, and Feishu/Lark. And more exciting features being added continuously Supported product boundary: Primary artifact: ComfyUI custom node pack First-class runtime identity: embedded operator platform Optional attached subsystem: connector-capable control surface via the sidecar runtime Decision record: ADR-0002 Product Boundary And Packaging Contract Connector packaging status: ADR-0003 Connector Extraction Feasibility And Split-Package Seams 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/* ├── Security/runtime modules (startup gate, RBAC, CSRF, HMAC, audit, SSRF controls) ├── Automation services (approvals, schedules, presets, webhook/assist flows) ├── State + secrets storage (openclaw_state/*) ├── Embedded frontend extension (OpenClaw sidebar tabs) + remote admin page (/openclaw/admin) └── ComfyUI nodes exported by this pack (planner/refiner/image-to-prompt/batch variants) Optional companion process (outside the ComfyUI process): └── Connector sidecar (Telegram/Discord/LINE/WhatsApp/WeChat/Kakao/Slack/Feishu) -> calls OpenClaw HTTP APIs This project is designed to make ComfyUI a reliable automation target with an explicit admin boundary and hardened defaults. Security stance (how this project differs from convenience-first automation packs) - Click to expand Public and hardened deployment postures are fail-closed by design: shared-surface acknowledgement, startup gates, route-plane governance, and control-plane split all aim to reduce accidental exposure. Admin writes, webhook ingress, and bridge worker paths are protected as explicit trust boundaries rather than convenience-only localhost helpers. Connector ingress keeps allowlist and policy checks as first-class controls, with degraded/public posture handled deliberately instead of silently widening access. Interactive connector actions are treated as a security boundary too: callback-capable platforms use signed envelopes, timestamp/replay guards, dedupe, and explicit policy mapping instead of trusting button actions as implicit admin intent. Connector reply visibility is policy-driven: silent, internal, tool-only, and no-mention text replies can be suppressed without bypassing allowlists, replay checks, approvals, or action-button delivery. 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. Secret handling stays server-side: browser storage is not used for secrets, local secret-manager integration is opt-in, and secrets-at-rest / token lifecycle controls are treated as operational boundaries. Multi-tenant mode is isolation-first: tenant mismatches fail closed across config, secret sources, connector installations, approvals, visibility, and execution budgets. Connector multi-workspace and multi-account bindings are secret-ref-only and fail-closed by design, so tenant/binding mismatches degrade to explicit rejection paths instead of silently reusing the wrong installation context. Operator-facing and audit payloads default to redaction for provider reasoning-like content and explicitly marked internal maintenance/helper prompt material, while diagnostics and runtime guardrails remain explicit and tamper-evident. Verification is part of the security model: route drift checks, supply-chain hardening checks, coverage governance, adversarial gates, and doctor/compatibility diagnostics are all wired into CI-parity workflows. Repository automation is hardened around deterministic dependency installs, restricted workflow permissions, pinned high-risk publish actions, and PR-time dependency review for dependency manifest changes. Deployment profiles and hardening references: Security Deployment Guide Security Key/Token Lifecycle SOP Security Checklist Runtime Hardening and Startup Threat Model Frontend Migration Decision Latest Updates - Click to expand Trigger callbacks and scheduled chat results are now delivered Trigger requests and approval-gated runs that name a callback now deliver their result to it. The callback was previously accepted and stored but never used. Its format is checked before anything runs and split deployments refuse it; the host allowlist (OPENCLAW_CALLBACK_ALLOW_HOSTS) and SSRF policy apply when the result is delivered. Responses report the callback status. Schedules with a Telegram, Discord, Slack, or Feishu/Lark delivery target now send each run's result through the connector. Every run records one durable delivery that the connector claims, waits on, answers with the result or a short failure or timeout notice, and acknowledges. Acknowledgement failures are retried, so a result is normally posted once; a connector that stops betwe