BBOX List to Collection

There is a specific kind of ComfyUI frustration that only shows up once you have a working workflow: you built a per-box pipeline, everything runs beautifully, and now you want to hand all those boxes to one node that wants to see them together. Wire the list in and it runs once per box instead. Eleven nodes draw eleven debug images. A "all boxes on one canvas" node produces eleven one-box canvases.

This is the node that stops that. It takes a genuine Comfy list and collapses it into a single legacy-style collection value, so the receiving node executes exactly once.

List semantics, since that's the whole story

ComfyUI decides how many times to run a node based on whether its input socket is declared as a list input. A list input receives the entire container in one pass; a normal input receives one item, and the engine maps the node over the list, gathering each output back into a list of its own. Both are typed BBOX on the canvas, so nothing warns you. That is why dropping a list into a legacy node produces N executions instead of an error - and why, when you want one execution, you have to say so explicitly.

How it works

UtilitySuiteBBOXListToCollection declares its bboxes input as a list input, so the engine hands it the whole container rather than a single box. Its execute takes that container, checks it really is a list or tuple, and returns list(bboxes) as an ordinary - non-list - output.

It is deliberately an almost-empty node. It interprets nothing, validates nothing about the boxes themselves, and never touches coordinates. That is precisely what makes it safe to leave in a graph: if the shapes were wrong before, they are still wrong after, and you will not be chasing a bug that this node invented.

Inputs and outputs

bboxes in, bboxes out. That's it. The input arrives as the whole list; the output is one value that happens to contain everything.

Reach for it when the next node is a "draw them all" visualiser, a serialiser that writes coordinates into a prompt or a filename, an API node that wants a payload, or any older node that was written before ComfyUI had list inputs and behaves oddly when run ten times in a row. It is also the right way to freeze a list for logging: the collection is a plain value, so a show-text or save node gets one call with the whole set.

Once you are done with the group node, unpack it again with BBOX Collection to List if the rest of the workflow is per-box. The two nodes are mirrors, and graphs that alternate between group and per-box work are the normal case, not a code smell.

Install

Part of ComfyUI-Utility-Suite - ComfyUI Manager → search ComfyUI-Utility-Suite → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/tom-m-2020/ComfyUI-Utility-Suite

Restart ComfyUI afterwards. No models, no downloads, and the pack's only declared dependency (opencv-python-headless) is not used by the BBOX nodes. Note the node is written against the newer V3 API (comfy_api.latest), which means a recent ComfyUI and no NODE_CLASS_MAPPINGS if you go looking in the source.

Traps

You lose per-item execution, entirely. That is the feature, but it bites when you half-want both: a node that should be run once and a node downstream of it that should be run per box. Split the wire instead of trying to have both - take the list to your per-box consumer directly and take a copy through this node to the group consumer.

A collection is not a list, and nothing checks. If a box-per-item node downstream of this one behaves like it only saw one box, that is the engine doing exactly what the declaration says. Check which socket you are plugged into before you blame the node.

Nesting is possible and confusing. Feed this a wrapper that contains a single collection and you get a one-item list whose item is a collection. The node has no way to know the difference and does not pretend to, so track whether your upstream output was a list to begin with.