ComfyUI-to-Python-Extension: your workflow graph comes back as a script with a fixed queue of ten

The only runtime dependency is a code formatter

The package manifest declares version 2.1.0, a requirement of Python 3.12 or newer, MIT, and a dependency list with exactly one entry: `black`. The separate `requirements.txt` at the repository root says the same thing.

That is worth pausing on. This extension turns a ComfyUI graph into a Python file and does not itself import torch, a model runtime or any ComfyUI code. Its entire contribution at run time is generating source text and handing it to a formatter, which is why the generated script comes out indented the way a Python programmer would have written it rather than the way a template produced it.

The manifest also carries a Comfy registry block: `PublisherId` set to `pydn`, `DisplayName` set to ComfyUI-to-Python-Extension, and an empty `Icon` field, with a comment noting it is used by the Comfy registry. Everything else in the file is project metadata, so a reader looking for behaviour has to go to the README rather than the manifest.

The two export paths produce differently shaped scripts

There are two ways out, and the difference between them is not documented as a difference.

From the Web UI, `File -> Save As Script` downloads a generated `.py` file using the fixed default name `workflow_api.py`. The stated reason for the fixed name is that it works in ComfyUI Desktop without relying on `prompt()`. Those scripts also embed the frontend workflow metadata needed for drag-and-drop reimport, so images saved by the script can be dropped back into ComfyUI and reopened with the original workflow attached.

From the command line, you enable the dev mode options, save the workflow with `File -> Export (API)`, and run the exporter module. Nothing in that path mentions workflow metadata, so the reimport round trip is a property of the UI export.

A third detail sits with the menu itself: placement can differ between frontend versions, so where `Save As Script` appears is a function of which ComfyUI frontend you are running rather than of this extension.

The virtual environment inside the extension is not the one ComfyUI uses

Running `uv sync` inside the extension directory creates its own `.venv`, and ComfyUI does not import dependencies from it. ComfyUI loads custom nodes with whatever Python interpreter launched it. That single sentence explains most of the troubleshooting section, including the entry about a failed Web UI import after `uv sync`.

The fix is always the same shape: install the extension into the interpreter that launches ComfyUI. Three recipes are given for that. For a source checkout driven by uv:

cd /path/to/ComfyUI
uv pip install -e ./custom_nodes/ComfyUI-to-Python-Extension
uv run python main.py

For the Windows portable build, run the bundled interpreter by hand from the extension directory:

cd C:\path\to\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-to-Python-Extension
..\..\..\python_embeded\python.exe -m pip install -e .

Discovery is a separate problem from installation. The repository has to be reachable through ComfyUI's `custom_nodes` search paths, which means cloning it into that directory, symlinking it there, or adding an external `custom_nodes` path in `extra_model_paths.yaml`. Getting the packages installed while the directory stays invisible produces an extension ComfyUI never loads.

torch is not this project's job, and that is where the errors come from

The exporter and the scripts it generates both need ComfyUI's own runtime, and the project is explicit that it will not supply it. `COMFYUI_PATH` helps the exporter and generated scripts find the ComfyUI codebase, and it is checked first; when it is unset, the exporter falls back to searching parent directories for a folder named `ComfyUI`. What it never does is install anything.

The documented failure is `ModuleNotFoundError: No module named 'torch'`, and the file gives two ways out: run the command with the same Python environment that launches ComfyUI, or install ComfyUI's runtime dependencies into the environment you are using for the CLI. Generated scripts inherit the same requirement, stated as depending on a working ComfyUI runtime.

For the Windows portable case the exporter is invoked through the embedded interpreter rather than the system one:

..\..\..\python_embeded\python.exe -m comfyui_to_python --input_file ".\workflow_api.json" --output_file ".\workflow_api.py"

Note what is absent from every one of these paths: there is no flag for pointing the exporter at a ComfyUI install other than through the environment variable or the parent directory search.

Exported scripts run once and clean up on the way out

The lifecycle section is the most useful part of the documentation for anyone planning to run these files in a batch, and it is blunt about the limits. Exported scripts are single-shot workflow runners, not long-lived ComfyUI prompt servers. They do not implement Web UI prompt and result caching across repeated service calls.

Memory handling is deliberate. The exported `main()` performs best-effort ComfyUI model and cache cleanup in a `finally` block, so a failed run still releases what it loaded. If an embedded host or a repeated-call host should unload models aggressively after every run instead of preserving them for reuse, the way to ask is `COMFYUI_TOPYTHON_UNLOAD_MODELS=1` or a call to `main(unload_models=True)`. The default is therefore the opposite of what a service wants: keep the models warm between calls.

One capability does come through. Generated scripts reuse ComfyUI's runtime argument parser during bootstrap, so the memory flags `--highvram`, `--normalvram`, `--lowvram`, `--novram`, `--cpu` and `--disable-smart-memory` can be passed straight to the exported file.

Three flags, a default filename on both sides and a queue of ten

The command line surface is three options, and two of them have defaults that match the UI export:

- `--input_file`: the workflow JSON, default `workflow_api.json` - `--output_file`: the Python file, default `workflow_api.py` - `--queue_size`: the default execution count written into the generated script, default `10`

So the generated file is not a one-shot by construction. It runs the exported graph ten times unless you change the number, which makes `--queue_size` the first flag most people edit.

The invocation has two forms, and both are still supported. The module form is `uv run python -m comfyui_to_python`, and a legacy wrapper file still works for anyone who prefers `uv run python comfyui_to_python.py`. The repository layout explains why both exist: there is a `comfyui_to_python.py` at the root and a `comfyui_to_python/` package beside it, alongside `comfyui_to_python_utils.py`, a root `__init__.py` that makes the directory a ComfyUI custom node, an `install.py`, a `js/` directory holding the frontend side of the menu item, `tests/`, `images/` and a `uv.lock`.

The prerequisite for the CLI path is easy to miss: the workflow must be saved in API format through `File -> Export (API)`, which needs the dev mode options enabled in ComfyUI.

Version 2.0 was a readability rewrite three days before 2.1

The release list shows three releases inside three days: v1.3.2 on 2026-03-28, v2.0.0 on 2026-03-29 with the title Readability Refactor, and v2.1.0 on 2026-03-30. The last commit to the default branch is dated 2026-05-10.

A major version bump named after readability, followed the next day by a patch, is a short and specific kind of release history: something about how the output is written changed enough to break callers, and then something small changed again. If you have a generated script from before March 2026, the file you are reading may not match what the current exporter emits, and the project keeps no compatibility note about it in the documentation.

The other thing the layout says is that this is a package with two front doors. The root `__init__.py` and the `js/` directory exist for ComfyUI to load it as a custom node with a menu entry, while the `comfyui_to_python/` package and its module entry point exist to be run from a shell. Both front doors read the same workflow JSON, and only one of them carries the workflow metadata that ComfyUI uses to reopen an image with its graph.

Editorial conclusion

This extension earns its place if your goal is repeatable generation rather than one-off pictures: you build a graph once, export it, and then edit the script instead of the canvas. Read four things before you rely on it. The exported file is a workflow export, not a parameterised tool, because workflow inputs are not turned into command line arguments, so scripting it means editing the file. It is a single-shot runner with no prompt or result caching across repeated calls, which is the right shape for a batch job and the wrong shape for a service. The UI export and the CLI export are not equivalent, since only the one from Save As Script carries the frontend workflow metadata that makes images draggable back into ComfyUI. And install it into the interpreter that launches ComfyUI rather than into the extension's own `.venv`, because that mismatch is the documented cause of both the failed import and the missing torch error. ComfyUI Desktop is the path of least resistance because the fixed default filename exists for it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pydn/ComfyUI-to-Python-Extension on GitHub
4. README
5. Releases