C2C Vault — Sealed (runs without password)

The sibling C2C Vault - Locked node is the right tool when you want someone to need your password to run a workflow at all. But most handoffs aren't that hostile - you've built a pipeline a client will run every day, and the last thing you want is to text them a password on every queue. C2C Vault - Sealed is the version for that: you hand over a workflow that runs instantly, no password, no prompt - but the graph inside stays an opaque blob that nobody can open, read, or paste into their own canvas without the password.

So the password's job changes completely. It's not a gate on running; it's the key to editing. On a sealed vault node the button reads "Open for editing…", not "Unlock…" - deliberately, because offering "unlock to run" would imply the thing was blocked when it isn't.

How it works

The creation flow is the same as the Locked vault: select the nodes, right-click the canvas, pick C2C: Seal selection into a Vault (runs without password). The difference is in the crypto, and it's worth seeing.

Installation is the standard pack dance: ComfyUI Manager → search CustomNodePacks, or cd ComfyUI/custom_nodes && git clone https://github.com/Code2Collapse/ComfyUI-CustomNodePacks.git, then restart. The vault node registers even without cryptography installed - it just can't open or seal anything until you add it.

Sealing uses envelope encryption with two "recipients." A random data key encrypts the subgraph, then that data key is wrapped twice: once under a key derived from your password (the open/edit path), and once under a key derived from a constant that ships in the pack source (the auto-run path). At runtime the node unwraps with the pack constant and executes - no password, no session, no unlock step. When you want to edit, you type the password and unwrap the other copy.

That second wrap is the entire story, stated plainly in the code: because a sealed vault must run unattended, the unwrapping secret is on the recipient's machine. The constant is deliberately not a secret - anyone who reads the pack's source can unseal any sealed payload. Sealing is obfuscation, and the author says so instead of pretending otherwise. What it deters is the casual stuff: opening your .json or the PNG you shared and reading the wiring, or dragging your nodes into another graph. Nothing that must run unaided can stop a determined extractor.

There's a genuinely nice side effect of the double wrap, though: the author's password wrap means you can re-open a sealed vault for editing on any machine, even one where it was never sealed. Lose your original graph file and the vault itself is still yours.

Inputs and outputs

Same shape as its locked sibling: vault_id (the plaintext session label, filled in for you), vault_payload (the base64 ciphertext, saved with the workflow, not hand-edited), up to three input_0/input_1/input_2 boundary inputs, and a single wildcard output. Because the vault collapses to one node, think of it as a compact component: a handful of wires in, one result out, internals sealed.

Locked or Sealed - pick by who runs it

• C2C_VaultLocked - the recipient must know your password even to execute. Use it when you don't want the workflow run without your say-so, or when the person shouldn't be able to use it if you cut them off.
• C2C_VaultSealed - they run it freely; they just can't read or remix it. Use it for client delivery and "here, use this" sharing where the recipe is your edge.

Common issues

• "no payload. Seal a selection first" - you've queued a fresh node with nothing in it. Seal a real selection (see the Locked article for the flow and the delete-the-originals reminder).
• Expecting sealing to protect real secrets. It won't - the unwrap key ships with the pack. Treat it as copy-deterrence. If the contents genuinely must stay hidden from someone technical, sealing is the wrong tool and so is everything else that must execute on their machine.
• The password gates editing, not running. If a recipient reports "it just runs," that's correct behavior, not a bug.
• Five failed open attempts earns a lockout, and a wrong password versus a tampered payload report the same error - deliberately, so neither gives an attacker a hint.
• cryptography missing - the node still registers so sealed workflows load, but open-for-editing errors with the pip hint until you install it.

Sealing won't stop a forensic attacker, and it isn't trying to. What it does - and does well - is let you share a working, unreadable, un-remixable pipeline with someone who just needs to press Queue.