comfyui-mcp download_model stalls, action:status reports progress that never lands on disk
On comfyui-mcp 0.52 with Windows 11 and local ComfyUI 0.33.4, a large HuggingFace download_model call stalls silently. action:"status" reports progress (83%, 7.30/8.74 GB) that is not present on disk, while action:"cancel" shows only a 1.26 GB .partial, and later status shows only "still streaming" with no byte counts. No error is raised. How do you recover?
Originally asked on GitHub: https://github.com/artokun/comfyui-mcp/issues/2356
3 answers
Status: the issue was closed as COMPLETED in its header, but the maintainer reopened it on 2026-08-28 because the bug still reproduces on comfyui-mcp 0.52.145, now including the segmented download path. A maintainer comment says a fix is being driven on branch
fix/2356-seg-staging-progress; no fixed release is confirmed in this thread.The workaround used in the thread: when a multi-GB download appears stalled, issue
action:"cancel", then re-issue the sameaction:"download". In the original report, an 8.74 GBqwen_2.5_vl_7b_fp8_scaled.safetensorsdownload totext_encodersshowed 83% in status, but cancel reported a 1.26 GB.partialin~/.comfyui-mcp/cache/. Re-issuing resumed and reported 28%, which matched the on-disk size. On 0.52.145 the maintainer saw a 19.53 GB segmented download report "PROGRESS UNAVAILABLE" for 32 minutes while its.segstaging file grew; cancel left a 4.23 GB.partial, and re-issue resumed at 22%.The reporter's view is that status progress is not reconciled against the
.partialsize on disk, and that when progress is unavailable the row degrades to a bare "still streaming" with no explanation. The reporter suggested deriving progress from the.partialsize and adding a stall indicator; these are suggestions, not confirmed changes. General advice: for large downloads, do not rely on status percentages alone. If the on-disk file stops growing, cancel and re-issue, which the thread shows resumes the transfer.Did this work for you?What a GitHub user tried on GitHub (Didn't work)
Reporter ran action:"download" for an 8.74 GB Hugging Face file and polled action:"status" for about 1.5 hours. Status reached 83% and then lost its byte counts. action:"cancel" later reported only a 1.26 GB .partial on disk.
Source: https://github.com/artokun/comfyui-mcp/issues/2356 (opens external site)
Did this work for you?What @artokun tried on GitHub (Worked)
Reporter issued action:"cancel" and then re-issued the same action:"download". The download resumed and reported 28%, consistent with the 1.26 GB on-disk .partial.
Source: https://github.com/artokun/comfyui-mcp/issues/2356#issuecomment-5422823538 (opens external site)
Did this work for you?
Related questions
- Use comfyui-mcp with Hermes Agent or Openclaw instead of Claude Code?
- comfyui-mcp get_node_info: "No nodes found" for a node present in /object_info
- ComfyUI-MCP apply_manifest clones duplicate ComfyUI-Manager from Krea 2 pack
- ComfyUI MCP Codex callback commits render as [object Object] instead of streamed text
- comfy_cli_models errors "comfy-cli was not found" even with a connected ComfyUI workspace