How to fix ComfyUI’s failed to save workflow draft error
Seeing ComfyUI fail to save workflow drafts on every edit? Learn what the error means, why Firefox shows up, and the fastest fixes.
When ComfyUI starts flashing “Failed to save workflow draft” every time you drag a node, paste a group, or tweak a setting, the obvious assumption is that saving is broken. For a lot of users, that diagnosis sends them in the wrong direction.
The evidence points somewhere else. In the current frontend, this message usually means ComfyUI failed to write a background recovery snapshot into browser storage. It usually does not mean the app failed to write your workflow JSON to disk. That difference matters, because the best fix for a broken browser-side draft system is very different from the best fix for a filesystem permissions problem.
That distinction also explains one of the strangest parts of this bug. Many users report constant red toast notifications with no matching terminal error, which is exactly what you would expect if the failure is happening in the frontend rather than in the backend. In GitHub issue #12942, the reporter says Firefox throws “The quota has been exceeded” when copying large groups of nodes, then starts showing the draft-save error during ordinary workflow edits. A newer report in GitHub issue #13131 describes the same kind of spam where almost every operation triggers the toast and the terminal stays quiet.
More on ComfyUI
Why this error is so easy to misread
The wording makes the problem sound like a normal save failure. If you see the word “save,” you think about the file on disk, the workflow folder, antivirus interference, or missing write permission. Plenty of users did exactly that, including people in a Reddit thread on the exact error.
The problem is that ComfyUI now has more than one kind of saving in play. There is the manual save you trigger when you want a real workflow file. There is Auto Save in the settings. There is also a separate recovery system that tries to preserve workflow state so the page can restore it after a refresh or restart. Those systems feel related when you are using the app, but they do not behave the same way and they do not fail in the same place.
The ComfyUI settings docs make that separation explicit. “Persist workflow state and restore on page (re)load” is enabled by default, while Auto Save is off by default. That means a user can honestly say “I turned off Auto Save” and still keep hitting a background draft persistence failure, because the workflow persistence system is a different switch entirely. That same split also showed up in practice. A February 2026 frontend report, issue #8778, described workflow changes persisting in Firefox even when people expected closing without saving to discard them.
What ComfyUI is actually doing in the background
The clearest clue lives in the frontend source. In the workflow persistence composable, ComfyUI listens for graph changes, serializes the current graph into JSON, and pushes that data through saveDraft(...). The same file shows that persistence is debounced, with a 512 ms delay before the write happens. The draft type constants expose that debounce value directly as PERSIST_DEBOUNCE_MS = 512.
That is why the toast tends to feel relentless. You are not seeing one failed save at the moment you hit Ctrl+S. You are seeing a recovery system try to write over and over as you keep editing the graph. In ordinary use, every drag, paste, group change, or parameter tweak can create another attempt to serialize the workflow and store it.
The same persistence code also shows exactly where the toast comes from. If saveDraft(...) returns false, the UI raises the failed-to-save-draft error. In other words, the message is wired to the browser-side persistence path. It is not strong evidence that your manual Save As failed, and it is not strong evidence that your workflow directory is unwritable.
The storage implementation points in the same direction. The draft store source file uses per-draft keys, keeps an index, writes JSON payloads, and tries to recover from quota problems by evicting older drafts and retrying the write. The draft types file also shows that the system keeps up to 32 drafts per workspace. Once that quota-handling path stops succeeding, the store can mark storage as unavailable for the session. That helps explain why the first failure often turns into an endless stream of follow-on failures.
Why Firefox keeps showing up in reports
Firefox is not the only browser in the world, but it shows up too often here to ignore. The strongest public clue is still issue #12942, where the reporter says Firefox shows “The quota has been exceeded” during large copy operations and then starts throwing the draft-save toast during routine editing, while Edge does not reproduce the same behavior.
The browser storage model makes that report believable. MDN’s storage quota documentation says Web Storage is typically limited to 10 MiB total per origin, usually split into 5 MiB of localStorage and 5 MiB of sessionStorage. Once that cap is reached, browsers throw QuotaExceededError. Since ComfyUI’s persistence layer is serializing graph JSON into browser-managed storage, a large workflow, a burst of copy-paste activity, or a pile of old drafts can push the browser closer to that wall than most users realize.
That does not prove Firefox is always at fault, and it does not prove Chromium browsers are immune. It does show a plausible mechanism. When a user duplicates or pastes a very large node group, the serialized graph can balloon quickly. If the browser already has stale draft payloads for the same origin, the next write can trip a quota limit and the persistence system can start failing on every subsequent graph change.
It also explains why the bug feels inconsistent across machines. Browser storage behavior is one of those layers users rarely think about until it breaks. Different browsers, private modes, site data history, existing drafts, and extension conflicts can change how close a given setup already is to the edge.
Why recent builds feel shakier than older ones
There is also good reason to think this is not just user confusion. The persistence subsystem has been moving, and a moving persistence subsystem is where ugly state bugs tend to surface.
A March 1, 2026 frontend ticket, issue #9317, describes a case where refreshing the page can load the wrong workflow from draft storage. The issue says two bugs inside useWorkflowPersistenceV2.ts were interacting: draft cleanup could remove the active workflow’s draft, and tab restoration could fail to reactivate the correct workflow. That is exactly the kind of subtle state interaction that makes people lose trust in background recovery systems.
The follow-up ticket, issue #9319, is revealing for a different reason. It proposes property-based finite state machine testing because #9317 exposed a class of bugs where two individually reasonable changes combined to cause workflow loss. Projects do not reach for state-machine testing unless they know the interaction surface has become tricky.
The frontend releases page tells the same story from another angle. The v1.43.4 notes include fixes like restoring workflow tabs on browser restart and migrating V1 tab state pointers during the V1-to-V2 draft migration. That does not mean every current build is broken. It does mean the team has been actively patching exactly the area this error touches.
That is why older-version workarounds gained traction so quickly in community threads. In the same Reddit discussion, users recommend pinning the frontend to 1.39.19 while later builds settle down. That is a workaround, not a cure, but it fits the broader picture of a persistence system that changed fast and picked up regressions along the way.
What to do before you lose work
The first rule is simple. Do not trust the background draft system once it starts screaming at you.
If the UI still lets you save or export the workflow manually, do that first. The whole point of the persistence layer is to act as a safety net. Once it starts failing, you should assume the safety net is unreliable and move your important work into an explicit file you control.
After that, go straight to the setting that actually matches the behavior. In the ComfyUI settings documentation, the control you care about is “Persist workflow state and restore on page (re)load.” Turn that off. Turning off Auto Save alone can leave the persistence system running, which is why so many users say they disabled saving and still got the toast.
A restart is worth doing immediately after you disable persistence. The store code in the draft persistence implementation is designed to give up cleanly when storage becomes unavailable. That is reasonable defensive code, but it also means a session that has already tripped into storage failure is not the session you want to keep nursing along.
The fix that usually works fastest
Once your workflow is safely exported, the most practical recovery step is to clear site data for your ComfyUI origin. If you access ComfyUI through something like
http://127.0.0.1:8188
or
http://localhost:8188
, that origin can hold the stale browser-side data that keeps tripping the persistence system. Since ComfyUI stores its recovery state in browser storage, clearing site data is one of the cleanest ways to wipe out bad draft state and start fresh.
Firefox users can follow Mozilla’s guide for clearing cookies and site data for a site. That does come with a tradeoff. You lose browser-stored drafts and restored tabs for that origin, which is why the export step comes first. Still, if the persistence layer is already failing constantly, those browser-side drafts are not something you should be leaning on anyway.
If you are using Firefox, it is also smart to run one simple diagnostic test. Open the same workflow in Edge or another Chromium browser and see whether the problem vanishes. This is not about browser fandom. It is about narrowing the fault line quickly. When issue #12942 says Firefox reproduces the quota message and Edge does not, that is a useful troubleshooting split.
When pinning the frontend makes sense
ComfyUI’s own repository docs support pinning the frontend to a specific version. The main ComfyUI repository explains the --front-end-version flag and shows how to launch with a chosen frontend build. That matters because it gives you an official way to stop riding the newest frontend if the newest frontend is where your workflow broke.
The syntax looks like this:
python main.py --front-end-version Comfy-Org/ComfyUI_frontend@1.39.19
That exact version number came up repeatedly in the community workaround thread on Reddit. It should be treated as a practical rollback target, not as a permanent recommendation for everyone. Still, when a bug is tied to the frontend persistence layer and recent persistence fixes are still landing in the frontend release stream, version pinning is a completely reasonable short-term move.
Portable Windows users will need to adapt that command to their usual launcher or batch file. The idea stays the same. Pick a known-good frontend, use it consistently, and stop updating blindly until the current bug path settles down.
Why disabling custom nodes is still worth one test run
Custom nodes are not the first thing to blame here, but they can still muddy the picture. ComfyUI’s official troubleshooting guide for custom node issues recommends disabling all custom nodes when you are trying to isolate frontend breakage, because some custom nodes also ship frontend extensions.
The standard command is:
python main.py --disable-all-custom-nodes
For the portable Windows build, the docs show:
.\python_embeded\python.exe -s ComfyUI\main.py --disable-all-custom-nodes
This is a diagnostic move, not a magic bullet. One reason the draft-save bug feels so frustrating is that reports like issue #13131 say the problem can persist even after custom nodes are disabled. Even so, one clean test run with custom nodes off is still useful, because it separates a core frontend persistence failure from an extension-induced frontend failure.
What probably will not fix it
The least reliable fix is changing the wrong setting. If you only toggle Auto Save, you may leave the actual persistence path untouched. That is why the settings page matters so much here. Auto Save and workflow persistence sound similar in plain English, but they are distinct controls in the product.
Ordinary filesystem troubleshooting is also often a distraction. When users report no terminal error, when the frontend code path for the toast points to saveDraft(...), and when browser choice changes the outcome, the evidence leans toward browser-side state rather than disk permissions. That does not mean file permission problems are impossible. It means they are often the wrong first suspect for this specific message.
Tweaking browser cache size is another maybe-sometimes workaround that misses the center of the problem. The persistence system described in the workflow persistence source and the draft store implementation is about serialized workflow state in browser storage, not about ordinary page-asset caching. That is why clearing site data is more targeted than fiddling with general cache settings.
The bigger lesson for ComfyUI power users
This error exposes a design tension that matters beyond one bad toast message. Recovery systems feel invisible when they work and dangerous when they fail. ComfyUI’s current approach tries to keep your work safe by serializing graph state into browser storage behind the scenes. That is convenient right up until quotas, stale state, migration bugs, tab restoration bugs, or browser differences turn the safety feature into the source of risk.
The evidence across issue #9317, issue #9319, issue #8778, and the recent frontend release history suggests the team is aware of that risk and actively improving the persistence system. That is encouraging. It also explains why cautious users have started treating browser-stored workflow recovery as helpful when it works, but not as something they want to trust blindly with important graphs.
A more robust long-term design would make recovery snapshots feel more explicit and auditable. Users should be able to see what is stored, purge it cleanly, and understand the limit they are working under. Browser storage can be fine for preferences and lightweight state. It is a more fragile foundation for large graph recovery, especially when the graph can grow fast and the failure mode is a vague toast that looks like an ordinary save problem.
The plain-English bottom line
If you are staring at “Failed to save workflow draft” in ComfyUI, the most useful mental model is this one: the frontend is usually failing to update its browser-stored recovery snapshot. Your actual workflow file on disk may still be perfectly saveable.
That is why the fastest recovery path is usually very direct. Save or export the workflow manually. Turn off workflow persistence in the settings. Restart. Clear site data for your ComfyUI origin. Test in another browser if you are on Firefox. If the current frontend still misbehaves, pin it to an older version until the latest persistence fixes settle.
For readers who want to track the problem more closely, the most relevant threads are the Firefox quota report in issue #12942, the every-operation error report in issue #13131, and the ongoing user workaround discussion on Reddit. Together with the settings docs, the ComfyUI launch options in the main repo, and the custom node troubleshooting guide, they give you the clearest map of what this bug really is and how to get back to work.
Explore more from Popular AI:
Start here | Local AI | Fixes & guides | Builds & gear | AI briefing