ComfyUI “Invalid workflow against zod schema”: Fix the Semantic Version Validation Error

You download a popular workflow from Civitai, drag the JSON file into ComfyUI, and immediately get a toast that reads something like Invalid workflow against zod schema with a wall of text about Invalid semantic version (x.y.z) at "nodes[8].properties.ver". Nothing actually breaks — the workflow still runs — but the warning reappears every time you switch pages or reload, and it is maddening enough that users have spent entire days searching for a way to silence it.

This error is real, it is well understood, and the fix is specific. It also happens to be a different problem from the better-known Prompt Outputs Failed Validation error, which is a server-side rejection when your API prompt does not match a node’s schema. This guide covers the frontend workflow-file validation instead: what Zod is doing, which fields trigger it, why it usually fires on nodes you did not write, and exactly how to make it go away without hiding a genuine problem.

What the Zod Schema Validation Error Actually Is

Zod is a TypeScript schema-validation library that ComfyUI’s frontend uses to check that a workflow file conforms to the expected structure before it is loaded into the graph editor. When you open a workflow, the frontend validates a set of rules: node types must be known, connections must reference real slots, and certain property fields must match a specific format. If a rule fails, Zod raises a collection of errors, and ComfyUI surfaces them all at once in the warning banner.

The two fields that cause the overwhelming majority of these warnings are ver and aux_id, both of which live under a node’s properties object. They are not fields most users ever edit by hand, which is exactly why the error feels so confusing: the file loads fine, the graph renders fine, and yet the validator keeps complaining about data you never knowingly changed.

The Two Fields That Trigger It

The Semantic Version Field (ver)

The ver property is meant to hold the version of the node pack that produced a given node. The validator expects it to be a valid semantic version string, matching a regex that is roughly:

/^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-([\da-z-]+(?:\.[\da-z-]+)*))?(?:\+([\da-z-]+(?:\.[\da-z-]+)*))?$/

This means a valid value looks like 1.2.3, 1.2.3-beta.1, or 1.2.3+metadata. Git commit hashes are also tolerated. The problem is that some custom node packs write a ver value that does not satisfy this pattern — a bare 1.0, a date string, a v1.2.3 with a leading v, or simply null. Any one of these makes Zod flag that specific node, and because the error is reported per-node, a single malformed value can produce a long list of Invalid semantic version entries, one for every node that inherited the bad value.

The Auxiliary ID Field (aux_id)

The aux_id property is expected to be a GitHub repository reference in the form owner/repo. The validator enforces the pattern github-user/repo-name. Some workflows ship node properties where aux_id is empty, is a bare username, or contains a full URL, and any of those triggers a separate set of Invalid format. Must be ‘github-user/repo-name’ errors.

Why This Happens on Workflows You Downloaded

The single most important thing to internalize is that these errors are almost never caused by anything you did. The offending values are baked into the node definitions by the custom-node authors when they export the workflow. A node pack that writes a non-semver ver string produces a workflow that loads fine inside that pack’s own authoring environment but trips the stricter validator in a newer ComfyUI frontend. In other words, the workflow was always slightly malformed; a recent frontend update simply started enforcing rules that were previously ignored.

This is corroborated by the official issue tracker. ComfyUI issue #7309 documents exactly this pattern, with users reporting that the error appears on workflows they downloaded and disappears entirely after they disable validation. The validation for the ver field was introduced in frontend PR #2751, and the maintainers later noted the over-eager matching had been relaxed in current versions.

Step by Step: Diagnose First, Then Decide

Before you toggle anything, read the message closely, because the fix depends on which field is failing.

1. Capture the full error text. Do not skim it. The warning lists the exact property path — for example nodes[8].properties.ver — which tells you both the node index and the offending field.
2. Confirm it is ver or aux_id. Semantic-version and aux_id failures are the two dominant cases. If the message points at a different field, your workflow has a different structural problem and disabling validation may hide something real.
3. Check whether execution is actually affected. In the vast majority of reports, the workflow runs normally despite the warning. If your graph queues and produces output, the validation is purely a frontend nuisance, not a blocker.
4. Open the workflow JSON. If you want to fix the data at the source, locate the node by index and inspect its properties.ver or properties.aux_id value. You will typically see a value that clearly fails the pattern described above.

How to Fix It

Option 1: Correct the Field in the Workflow File

The cleanest fix is to normalize the offending value in a text editor. Open the .json workflow, find the node, and change ver to a valid semantic version such as 1.0.0, or change aux_id to a proper owner/repo string. Save and reimport. This keeps validation enabled, which means any future structural problem will still be caught.

Option 2: Disable Workflow Validation

ComfyUI exposes a setting to turn off this validation entirely. In the Settings dialog, find the Workflow validation toggle and set it to disabled. This is the step users in issue #7309 confirmed removes the error immediately. The official troubleshooting guidance states it is acceptable to disable validation temporarily while you investigate. The caveat is the same as before: with validation off, genuinely broken workflows will no longer warn you, so treat this as a stopgap for workflows you trust rather than a permanent global default.

Option 3: Update ComfyUI and the Affected Node Packs

Because the overly strict matching was relaxed in later releases, simply being on a current frontend often clears the error. If a specific custom node is the source, update that pack from ComfyUI Manager so its exported workflows carry a compliant ver value going forward.

Common Pitfalls

• Confusing this with prompt_outputs_failed_validation. That is a server-side rejection of an API prompt with a valid execution record boundary, not a frontend file-import warning. The fixes do not overlap; see our guide on finding and fixing the invalid node in a failed prompt for that separate error.
• Editing the wrong file. You may have both workflow.json and workflow_api.json saved. The Zod validation applies to the graph file you import into the editor, not the API-format export.
• Assuming a leading v is fine. v1.2.3 fails the semver regex even though it looks reasonable to a human. Use 1.2.3.
• Disabling validation and forgetting. If you later open a workflow with a real missing-node problem, you will not get the warning, and you may misdiagnose the resulting red nodes as something else. Re-enable validation once you have moved past the noisy workflows.

Verification and Conclusion

After applying a fix, reload the workflow and watch the banner. A corrected ver/aux_id value should eliminate the warning for the nodes that previously triggered it while keeping validation enabled. If you chose to disable validation, confirm the error is gone and then deliberately re-enable it on a workflow you know is clean to verify you have not masked a real issue.

The Invalid workflow against zod schema error is, in the end, a data-hygiene signal rather than a runtime failure. The values that fail are usually inherited from custom-node exports, the validator was made stricter by a frontend change, and the practical fix is either a one-field edit in the JSON or a single settings toggle. Understanding the difference between this warning and the much more serious prompt-validation rejection is the key to not wasting a day on a problem that never affected your generation in the first place.

For full context on how ComfyUI recommends ruling out custom-node issues, consult the official ComfyUI troubleshooting documentation and the dedicated custom-node troubleshooting guide.