Cast List To Any

Here's the annoying ComfyUI situation this node solves: you've got a LIST - from a list node, a loop accumulator, a batch editor - and the thing you want to feed it to has a generic * input that would happily accept it, but the graph builder won't let a LIST socket connect to a * socket because they're "different types." The data is fine. The type system is being pedantic. Cast List To Any is the bridge: it takes a LIST, passes it through untouched, and exposes it as a generic * output that will connect to anything.

It's the mirror image of CastAnyToList in the same pack (which types a generic value as LIST). Between the two, you can move data across almost any socket mismatch in either direction, which is exactly what you want when you're mixing nodes from several packs whose list conventions don't agree.

The inputs and output

• py_list (LIST) - the list to pass through.
• Output is a single * socket, flagged as list-capable (is_list: true), so the graph engine knows the result is still a collection even though it's typed as "any."

Non-mutating: the list isn't copied or altered, it's just re-typed for the connection. Same data, friendlier type.

When you'd reach for it

• Feeding a list into a node whose * input is happy with collections but rejects the LIST type label.
• Bridging between a list-producing pack and a generic-consumer pack.
• Threading a list through a utility node (like a passthrough or a saver) that's typed generically.

The honest caveat is the same as its sibling: casting changes the type label, not the data. If you connect a list to a node that genuinely expects a scalar and treats whatever it receives as one, you'll get a downstream error that looks unrelated - the cast succeeded, the semantics didn't. Use it when the target is collection-aware but type-pedantic, not when the target fundamentally can't handle a list.

Installing it

Part of comfy-ovum:

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

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

Gotchas

The one real trap: if the list output flows into something that iterates it while another consumer expects a scalar, you can get silent "it got a list but treated it as one thing" behavior. Keep the cast close to where it's consumed, and when in doubt, run once and check what the downstream node actually received.