Prompt List

A text box that queues once per line

Most prompt nodes hand downstream one string. This one hands downstream a list of strings, and that changes the shape of the run: one entry per line of the text box, with the graph below it executing once for each. Paste twenty lines, get twenty images, twenty saves, twenty filenames - from one queue press.

It is the least glamorous way to batch, and for iterating on a prompt idea it's usually the right one. You are not sampling variants of a seed; you are running twenty different prompts through the same pipeline and comparing the results side by side.

How it works

Five widgets, per the schema:

• multiline_text - the prompts, one per line. This is the box you live in.
• prepend_text / append_text - a string glued to the front and back of every line, so shared scaffolding (a style clause, a quality tail, a trigger word) is typed once.
• start_index and max_rows - a window over the lines. max_rows defaults to a generous 1000, so on a short list you'll leave it alone; set start_index to skip the first N lines when you're re-running just the tail of a long list.

Three outputs, and the names are honest about which is which:

• prompt - the wrapped line, prepend and append included. This is the one you wire to your CLIP text encode.
• body_text - the bare line, no wrapping. Handy when you want the prompt itself as a filename or a folder name.
• show_help - a fixed string of usage text. It is not a prompt, and it is the one output that isn't a list. If you wire it somewhere expecting useful data, you'll get a sentence.

The first two are declared OUTPUT_IS_LIST, which is the mechanism behind the whole thing: ComfyUI treats a list output as "run everything downstream once per element". The third is a plain string and passes straight through.

Wiring it up

Wire prompt into the text input of a CLIP Text Encode - if the socket isn't there, right-click the widget and convert it to an input. That's it.

What happens next is the part people don't expect: because the list propagates, the whole downstream branch runs per line, including your sampler and the save node. Seeds advance between lines (whatever your sampler's control_after_generate is set to will do its thing twenty times), and a counter-based save like BC_SaveImage numbers them in order. If you want an A/B where only the prompt moves, this is a clean way to get it - but understand that every randomness source in the branch also moves, so two lines that differ by one word can look very different for reasons that have nothing to do with the word.

For a batch where only the prompt should change, set the sampler seed to a fixed value before you queue. Nothing in this node controls that for you.

Install

Manager: search ComfyUI-BCNodes and install, then restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/0xBeycan/ComfyUI-BCNodes

No pip step needed for this node - the pack's requirements.txt only covers the PostFx and Caption Audit nodes, and this one is pure Python with no imports beyond the standard library. Search BCNodes in the node library to see the whole pack; Prompt List sits under BCNodes/text.

Where people get burned

A blank line is a real entry. The node splits on newlines and doesn't filter empties, so a stray line break at the end of your text produces one more run with an empty prompt. With a trailing newline, ComfyUI will happily generate your model's idea of nothing. Trim the box.

It does not read files. There's no path input - the text goes in the widget. If you have a .txt of prompts on disk you'll be pasting it in, or using a different node. And there are no wildcard substitutions here either; each line is taken literally, which some people find liberating and others find limiting.

Downstream execution multiplies. Twenty lines means twenty samplers, twenty VAE decodes, twenty save operations. On a heavy video graph that is a real cost, and it's easy to set up a 40-line list on a workflow that takes two minutes a run and then wonder why the queue looks frozen. Start with two or three lines.

start_index can't error you out. It's clamped to the last line of the text, so a start_index past the end gives you a one-line list rather than a crash or empty output. Nice, but it means a typo in that field fails quietly instead of loudly.