Unwrap from List (XJ)

Every output in ComfyUI is secretly a list, and most of the time the secret is harmless: nodes that consume a value just auto-unwrap the single-element list for you. But the moment you involve a node that receives lists as lists - anything declaring INPUT_IS_LIST - that wrapping becomes visible, and suddenly you're holding [value] when the next node wants plain value. Unwrap from List (XJ) is the tool for that moment: it takes a one-element list and hands you the value inside it.

It's the mirror image of the same pack's Wrap as List (XJ). Wrap turns a single value into [value]; this turns [value] back into the value. You'll typically reach for it at the exit of a loop or a list-manipulating segment, right before the data goes back into ordinary nodes - the ones that can't take a list and would error on it.

The weird part it's actually solving

Here's what makes this node interesting rather than trivial: ComfyUI's auto-unwrapping and the list-handling flags can interact in ways that look like bugs. The pack's own loop-system docs walk through it in detail - a node output normally gets wrapped as [value], an INPUT_IS_LIST consumer receives that wrapped form directly instead of the auto-unwrapped value, and if your actual data is a list, you end up double-wrapped as [[value]]. So this node doesn't just unwrap once; the code checks whether the result is still a one-element list and unwraps again if needed. Feed it the mess and it figures out the depth.

It's also strict in a way that's genuinely helpful: if you hand it a list with zero items, or more than one, it raises a clear error - "Expected exactly 1 item in list, got N items" - instead of silently dropping data. That's the difference between a debugging headache and a red flag you can act on.

The whole interface

One input, one output, both a wildcard type (*) that accepts anything:

• value - the list to unwrap. Must have exactly one element.
• value - the element itself, as a plain (non-list) value.

There are no knobs to set. If you're getting the error above, the fix isn't a parameter - it's checking upstream that the list really does have a single element. The classic mistake is pointing this at a genuinely multi-item list (say, the full text_list from a loader) expecting it to pick one entry; it won't. It's not a "first item" selector, it's an unwrapper, and it only accepts lists of length one.

Installing it

Same pack as always - ComfyUI-XJNodes by alexjx. ComfyUI Manager, search "XJNodes", or:

cd ComfyUI/custom_nodes/
git clone https://github.com/alexjx/ComfyUI-XJNodes.git

Then restart ComfyUI. There's nothing heavy to install: the pack's requirements.txt is empty and this node is a few lines of pure Python built on ComfyUI's own type system. No models, no extra pip packages.

When you actually need it

Honest answer: not often, until suddenly very often. If you use the XJNodes loop system or any INPUT_IS_LIST-style list machinery, unwrap is your exit door back to the normal world. If you mostly build simple prompt-to-image graphs, you can skip it entirely - the auto-unwrapping never bites you. This is a fixer-upper node for the days when a workflow loads, something deep in the graph is passing a list where a value belongs, and you need one clean node to make the mismatch go away. It solves that exact problem and nothing else, which after a day of fighting list semantics feels like exactly the right amount of ambition. Given the pack is a small personal project ("primarily for personal use," per its README), the code being short and readable is a plus - you can see in a minute exactly what it does.