Donut Prompt Receiver (HTTP)

You already have a way to drive ComfyUI over HTTP: the built-in /prompt API. What you don't have is a way to re-run the workflow sitting open on your canvas with a new prompt in one POST, without exporting API-format JSON and juggling node IDs by hand. That's the gap this node fills. Drop Donut Prompt Receiver into a workflow, run it once, and your desktop ComfyUI grows a tiny loopback HTTP server that accepts {"prompt": "a cat"} and queues the current workflow with that text wired into your sampler.

The name is honest about the audience: a local companion app - a Discord bot, a home-automation script, a bridge to a local LLM - living on the same machine as your ComfyUI. The receiver binds only to 127.0.0.1 and only ever talks to ComfyUI's own local API at 127.0.0.1:8188, which the pack's tests explicitly enforce. Don't put it on a hosted or multi-tenant install; it's desktop-only by design.

How it works

The first time you run the workflow, the node quietly registers a copy of the resolved workflow plus its own node ID and starts the HTTP server on your chosen port (default 8001). From then on, POST to http://localhost:8001/prompt with:

{"prompt": "a cat", "face_prompt": "", "negative_prompt": "ugly"}

Behind the scenes it deep-copies the registered workflow, randomizes every seed/noise_seed it finds, stamps the prompt text into its own _api_prompt input with a __API__: magic prefix, generates a fresh prompt ID, and submits the whole thing to ComfyUI's local /prompt endpoint. When that queued run executes, the receiver node runs again, sees the magic prefix, strips it, and finally emits your text on the prompt output - which is why you wire that output into your CLIP Text Encode or a wildcard processor. A clean little loop: one POST in, one freshly-seeded generation out.

The inputs that matter

Most of the node is plumbing you'll never touch. The _api_prompt, _api_face_prompt, _api_negative_prompt and _api_prompt_id inputs are how the receiver passes data to its own re-runs - the bundled frontend extension hides them. The ones you actually set:

• port - where the listener lives (default 8001). Change it if something else owns that port.
• user_prompt, meta_prompt, num_prompts - these only matter for the "Send to Claude" loop mode below.
• loop_enabled - the loop-mode switch, off by default.

The four outputs are all strings: prompt (the text to feed your encoder), face_prompt and negative_prompt (optional companions), and api_info - a handy cheat-sheet string describing the endpoints, which is how the node documents itself.

The loop mode (skip it unless you want it)

The node's other trick is a feedback loop. The extension adds a Send to Claude button that posts your user_prompt plus meta_prompt to a local Claude bridge (outgoing_host/outgoing_port/outgoing_protocol, default http://localhost:5728/prompt) asking it to generate prompt variations and queue them through the API above. If loop_enabled is on, a monitor thread watches ComfyUI's queue and re-triggers that bridge every time the queue drains. It's clever, but it assumes you actually run a companion bridge on port 5728 and want it to keep re-prompting indefinitely. Most people leave it off - the plain POST interface is the genuinely useful half.

Install

Install the pack via ComfyUI Manager (search "ComfyUI-DonutLocalAutomation"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/DonutsDelivery/ComfyUI-DonutLocalAutomation

Then restart ComfyUI. The only dependency is requests, which ComfyUI already ships - no model downloads, no heavy install. This is an extracted slice of the author's bigger ComfyUI-DonutNodes package; if you update that pack too, the README suggests installing this one alongside it to keep existing node IDs stable.

Common issues

• "Workflow not registered. Run the workflow once first." - the server only learns your workflow when the node actually executes, so you must run the workflow once after wiring it up before any POST will work. This is the #1 beginner stumble.
• "Address already in use" - something else owns your port; change it and re-run.
• It won't answer from another machine - by design. The receiver is loopback-only and the pack hard-refuses non-loopback outgoing_host values too. If you need remote access, you're building a different thing.
• The loop never fires - check loop_enabled is on and that a local bridge is actually listening on the outgoing port. The queue monitor silently swallows its own errors.

It's a niche node from a workflow-focused author, so don't expect a big support community - but for local automation it's the cleanest way to hand ComfyUI a prompt over HTTP and have your own workflow answer.