Download All missing models always shows 'Save As' dialog instead of auto-downloading to correct model directory

[baoyu0]

Description

When opening a built-in workflow template that references missing models, clicking the "Download All" button shows a native "Save As" directory picker dialog for each model, instead of automatically downloading to the correct model subdirectory.

Environment

• Desktop Version: 0.8.35+ (installed on D:\ drive)
• ComfyUI Version: 0.24.1
• Frontend Package: 1.44.19
• OS: Windows 10 64-bit
• Install path: D:\ComfyUI
• Model path: D:\ComfyUI\ComfyUI\models

Steps to Reproduce

1. Install ComfyUI Desktop on D: drive (non-C: drive)
2. Open a built-in workflow template (e.g. any template that requires models not yet downloaded)
3. Desktop detects missing models and shows "Download All" prompt
4. Click "Download All"
5. ⚠️ A native Windows "Save As" dialog pops up for each model, asking where to save instead of auto-downloading to the correct subdirectory under models/

Expected Behavior

Models should automatically download to the correct subdirectory based on model type, e.g.:

• Checkpoints → models/checkpoints/
• Diffusion models → models/diffusion_models/
• LoRAs → models/loras/
• VAEs → models/vae/

This worked correctly when ComfyUI Desktop was installed on C:\ drive. After reinstalling on D:, the "Save As" dialog appears.

Investigation Findings

Backend is correctly configured

• folder_paths.models_dir points to D:\ComfyUI\ComfyUI\models ✅
• extra_model_paths.yaml is properly loaded with download_model_base: D:\ComfyUI\models ✅
• get_model_dir() returns valid paths for all model types ✅
• Model directories exist and are writable ✅

Relevant startup log from logs/comfyui.log:

[INFO] Adding extra search path download_model_base D:\ComfyUI\models
[INFO] Adding extra search path checkpoints D:\ComfyUI\ComfyUI\models\checkpoints
...

Root Cause Analysis

1. This is related to the "Missing Models Downloads" regression reported in ComfyUI#12961 — the "Download All" button was introduced in a frontend update but fails to properly route downloads through the Manager backend API.

2. The Desktop's DownloadManager validates download paths against {installPath}/models. When the save path doesn't match (string comparison), it falls back to dialog.showSaveDialog(). Even with a junction or download_model_base pointing to the correct path, the dialog still appears, suggesting the frontend may not be passing the savePath to DownloadManager.startDownload() at all.

3. Workaround: Using ComfyUI Manager → Model Manager to download individual models works correctly because it uses the backend API (/v2/manager/queue/install_model) directly, bypassing the frontend download handler.

Related Issues

• [Bug]: Setting Alternate Download Model Path #1699 - Setting Alternate Download Model Path (related but about path validation)
• Missing-Models-Downloads ComfyUI#12961 - Missing Models Downloads (the frontend regression)
• Draft PRs: Frontend #12317, Backend #13961 (proposed fixes)

Logs

Full logs/comfyui.log shows all model paths are correctly registered. The user/comfyui.log confirms ComfyUI starts without errors.

[dosubot]

Hi @baoyu0! I'm Dosu and I'm helping the Comfy Org team.

This is a confirmed limitation in how the DownloadManager validates download paths. Looking at the code, the core issue is in the ensureDownloadTargetDirectory() and isPathInModelsDirectory() methods [1] — they resolve real paths via fs.realpathSync.native() and check containment against the single modelsDirectory that the DownloadManager was initialized with. If the frontend passes a directoryPath that resolves outside that directory, the download is rejected with a "Save path is not in models directory" error [2].

One clarification on the symptom you're describing: The DownloadManager itself does not fall back to dialog.showSaveDialog(). It either downloads automatically or reports an error back to the frontend [3]. If you're seeing a native "Save As" dialog, that likely originates from the frontend/renderer layer when it receives the download error and attempts a fallback, or from Electron's default will-download handler for download URLs that aren't intercepted by the DownloadManager (i.e., Electron shows a save dialog by default for unhandled downloads).

This matches issue #1699 exactly — when download_model_base points to a different path than the DownloadManager's modelsDirectory, the containment check fails. The DownloadManager is initialized with a hardcoded {basePath}/models and doesn't consult extra_models_config.yaml or download_model_base settings for validation.

Workarounds [4]:

1. Ensure your install base path is D:\ComfyUI so the DownloadManager's modelsDirectory matches your actual models location
2. Use ComfyUI Manager's Model Manager to download individually (as you noted, this bypasses the desktop DownloadManager entirely)

Several related PRs have been merged to improve path handling — PR #1657 (honor absolute missing model download paths) and PR #1685 (auto-create missing model subdirectories) — but the fundamental issue of the DownloadManager not respecting alternate download_model_base configurations remains open per #1699.

Could you check your main.log for the specific error message? If you see "Save path ... is not in models directory ...", that confirms the path validation failure. If not, the "Save As" dialog may be triggered by a different code path worth investigating further.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[baoyu0]

Thanks @dosu! I checked but cannot find a main.log in any of the expected locations (AppData/Roaming/Comfy Desktop/, AppData/Local/, D:\ComfyUI\logs, etc.). The DownloadManager errors may not be persisted to a file in this installation.

However, I can confirm:

1. The download_model_base is registered at D:\ComfyUI\models in folder_paths.folder_names_and_paths (verified via logs/comfyui.log: [INFO] Adding extra search path download_model_base D:\ComfyUI\models)

2. The install base path (from installations.json) is D:\ComfyUI, so the DownloadManager's modelsDirectory should resolve to D:\ComfyUI\models — which matches the download_model_base path above.

3. A junction was also created at D:\ComfyUI\models → D:\ComfyUI\ComfyUI\models to ensure the filesystem path resolves correctly regardless of which path the validation uses.

4. Despite all this, clicking "Download All" on the missing-models dialog still shows a native "Save As" dialog. This suggests the dialog may NOT be coming from the DownloadManager containment check (since the paths should match), but rather from the frontend/renderer layer, possibly triggered by the browser's default download handler for URLs that aren't intercepted by the DownloadManager.

Could the issue be that the frontend's "Missing Models Download All" flow doesn't call DownloadManager.startDownload() at all, and instead triggers a plain browser download (window.open / download link)? This would explain the native "Save As" dialog even when backend paths are correctly configured.

I saw ComfyUI#12961 which mentions the "Download All" button was introduced in a frontend update and may be bypassing the Manager API. Could this be the same root cause for Desktop?

[dosubot]

Your hypothesis is very likely correct. Looking at the desktop app's architecture, here's what's happening:

The DownloadManager's will-download handler checks if the download URL is already registered in its internal downloads Map. If the URL is not found, the handler returns early without taking action [1], which means Electron's default download behavior kicks in — showing the native "Save As" dialog.

session.defaultSession.on('will-download', (event, item) => {
  const url = item.getURLChain()[0];
  const download = this.downloads.get(url);
  if (!download) return; // ← Falls through to Electron default (save dialog)
  // ...
});

The only way to properly download through the DownloadManager is via the IPC channel: the frontend must call window.api.DownloadManager.startDownload(url, path, filename) [2], which registers the URL in the Map before calling session.defaultSession.downloadURL(url) [3].

The "Download All" button lives in the ComfyUI frontend package (not the desktop repo itself), and based on your observations + ComfyUI#12961, it appears to be triggering downloads via a browser-level mechanism (direct URL navigation, anchor click, etc.) that never calls the desktop IPC channel. This causes Electron to intercept the download via the will-download event, find no matching entry in the Map, and fall through to the native save dialog.

So to summarize: the paths being correctly configured is irrelevant here because DownloadManager.startDownload() is never called in the first place. The fix needs to happen in the ComfyUI frontend — the "Download All" flow needs to route through electronAPI.DownloadManager.startDownload() instead of triggering plain browser downloads.

This is essentially the same root cause as ComfyUI#12961. If you want to help confirm, you could open DevTools (Ctrl+Shift+I) when clicking "Download All" and check the Network/Console tabs — you'd likely see direct HTTP requests or navigation events rather than IPC calls.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.