Enable ComfyUI-Manager by default in the Windows portable build

[alexisrolland]

PR Created by the Glary-Bot Agent

---

Proposal + implementation for the second half of a #dev-core-engine thread: Portable users must install a pip package and hand-edit a .bat file before the custom node manager appears. Desktop already enables it (DEFAULT_LAUNCH_ARGS = '--enable-manager'), Portable does not.

Companion PR (UI rename) in Comfy-Org/ComfyUI_frontend.

Adding the flag alone would have shipped a broken UI

Worth stating up front, because it is the non-obvious part and it drove the shape of this PR.

The portable bundle never installed manager_requirements.txt — stable-release.yml only installed grep comfy requirements.txt. So --enable-manager on its own is not merely a no-op:

1. main.py hits handle_comfyui_manager_unavailable(), logs a warning, and sets args.enable_manager = False.
2. But the frontend gate reads raw sys.argv, not the parsed args, so it still sees --enable-manager.
3. Core advertises extension.manager.supports_v4: true unconditionally (it is hardcoded in _CORE_FEATURE_FLAGS), while supports_csrf_post is published only by the manager package at runtime.
4. useManagerState.ts therefore resolves serverSupportsV4 === true && supportsCsrfPost !== true → INCOMPATIBLE → it hides the button and toasts "Please upgrade ComfyUI-Manager to version 4.2.1 or higher" — about a package the user never installed.

Verified locally against a real backend:

# no package, flag passed
argv includes --enable-manager ? True
/features -> extension.manager.supports_v4: true      (no supports_csrf_post)
/api/manager/* -> 404

# package installed, flag passed
/features -> supports_v4: true, supports_csrf_post: true
[START] ComfyUI-Manager

So the package install and the flag have to land together. That is why this is one PR rather than a one-line .bat change.

Changes

Bundle the pinned package (manager_requirements.txt stays the single source of the version) in all three workflows that build a portable:

• stable-release.yml (nvidia / amd / intel, via release-stable-all.yml)
• windows_release_package.yml
• windows_release_nightly_pytorch.yml

The latter two copy the nvidia base files, so they picked up the flag from the launchers and would have shipped exactly the broken state described above.

Keep it in sync on update, so a bumped pin is not ignored:

• .ci/update_windows/update.py — the existing single-file requirements sync becomes a loop over requirements.txt + manager_requirements.txt. This is the path update_comfyui.bat uses.
• The generated update_comfyui_and_python_dependencies.bat in windows_release_dependencies.yml, windows_release_dependencies_manual.yml and the nightly.

Pass the flag from all 8 .ci/windows_*_base_files/**/*.bat launchers that invoke main.py. CRLF preserved.

Make CI able to catch a regression. --quick-test-for-ci --enable-manager exits 0 even with the package missing, so the smoke tests now also grep -q "\[START\] ComfyUI-Manager" on the startup log. Verified both directions against real captured logs: passes when the manager loaded, fails when it was absent.

comfy/cli_args.py is untouched — the flag default stays False; only the shipped launchers opt in.

Verification

• ruff check . → clean (repo-wide, as CI runs it); all five edited workflow YAMLs parse
• --quick-test-for-ci --cpu --enable-manager with the package installed → exit 0, [START] ComfyUI-Manager, and the registry fetch degrades gracefully to a warning when offline (so the new CI assertion will not flake on registry downtime)
• update.py's new loop exercised against the real source block across five scenarios: fresh portable (installs both), no-op re-run, manager pin bumped (installs manager only), core requirements changed (installs core only), and downgrade to a ComfyUI without manager_requirements.txt (skips cleanly)
• Launcher coverage audited: 8/8 carry the flag, none missed, CRLF unchanged on every one

Decisions for the team — please weigh in before this leaves draft

1. Default network posture. This is the real question, and it is a product/security call, not a code one. ComfyUI-Manager contacts the custom-node registry at startup, not only when the dialog is opened (network_mode: public, observed fetching custom-node-list.json during startup tasks). Core's own guidance forbids adding outbound requests to ComfyUI; this does not add any to core, but it does change what a stock Portable does out of the box. If that is not acceptable, say so and I will close this.

2. Download size. comfyui_manager==4.2.2 pulls GitPython, PyGithub, cryptography, PyNaCl, chardet, toml and uv. Measured uncompressed: ~78 MB (48 MB of that is the uv binary, ~15 MB cryptography, 5 MB the manager itself). transformers/huggingface-hub are already core deps. That is material for an archive whose build step deletes torch .lib files with the comment "I need the space". Someone should approve the budget, and the .7z delta should be measured on a real build.

3. Existing installs get the dependency but not the flag. update.py will install the manager package on the next update_comfyui.bat, but it never rewrites run_*.bat (those live outside the checkout). So existing users pay the download and still launch with the manager off until they download a fresh archive. I left it that way deliberately — rewriting user-editable launchers on update seems worse — but flagging it since it means "on by default" is true for new downloads only.

4. advanced/run_nvidia_gpu_disable_api_nodes.bat got the flag too. --disable-api-nodes restricts Comfy's own API nodes and has nothing to do with the manager, so excluding it would ship the package unusable with no explanation. If that launcher is meant to be the reduced-network variant, tell me and I will drop the flag there.

5. Cache key not bumped. update_comfyui_and_python_dependencies.bat is stored in an immutable actions/cache entry keyed on ${{ runner.os }}-build-cu<cu>-<python_minor>, so existing keys will keep serving the old script. This does not affect the shipped portable (the manager is installed at package time, uncached) — only that one helper script. I did not bump the keys unilaterally because it forces a full torch wheel rebuild for every cuda variant; that is release-engineering's call.

6. Version skew ownership. The frontend hides the UI and nags when the Manager backend is older than 4.2.1, so the pin in manager_requirements.txt now needs a named owner who bumps it with Manager releases.