Concat Lists

Concat Lists is the original JavaScript-semantics concatenation node in this pack's list toolbox: list_a followed by list_b, exactly like Array.prototype.concat. It's non-mutating, it tolerates a blank list_b (you just get a shallow copy of list_a), and if list_a is blank you get a copy of list_b. It only concatenates two lists - to chain more, connect several of them in a row, which the node's own description calls out explicitly.

One honest piece of pack archaeology first: in the current source, this class is marked deprecated, and the pack's maintainers point you at the newer ConcatListsOvum (in the ovum/lists/python group) and the batch variants. Deprecated here doesn't mean broken - it means there are shinier siblings with the same semantics. If this is the version you already have in a saved workflow, it keeps working; if you're starting fresh, the ovum/lists/python or ovum/lists/comfy variants are the supported path.

The inputs

• list_a (*) - first list.
• list_b (*) - optional second list; blank is treated as empty.

Output is a single list (*) - the concatenation, non-mutating (neither input is modified).

How it behaves

• list_a = ["a","b"], list_b = ["c"] → ["a","b","c"].
• list_b blank → a shallow copy of list_a (a fresh list, so mutating the result won't touch the source).
• list_a blank → a shallow copy of list_b.

The "shallow copy when one side is empty" behavior is the useful subtlety: it gives you a safe copy as a side effect, which matters in a graph that caches and re-runs.

When you'd reach for it

Building prompt lists, seed lists, or path lists from multiple sources, where "merge these two collections" is a recurring step and you want JS-style leniency about empty sides rather than an error.

Installing it

Part of comfy-ovum:

cd ComfyUI/custom_nodes
git clone https://github.com/sfinktah/comfy-ovum

Restart, or ComfyUI Manager → search "comfy-ovum". No models, no extra dependencies.

Gotchas

Two things. First, "deprecated" - if you're building a new workflow, prefer the pack's ConcatListsOvum or the batch variants so you're not depending on a node that might get pruned in a future version. Second, the "shallow copy" behavior is a copy of the list, not a deep copy of the items - if your items are themselves mutable objects, both lists still share them. For plain strings and numbers, that never matters.