Bug: File -> Save As doesn’t save current changes

[hablaba]

Prerequisites

• I am running the latest version of ComfyUI
• I have searched existing issues to make sure this isn't a duplicate
• I have tested with all custom nodes disabled (see how)

What happened?

You make some changes and want to save the workflow with a new name. File -> Save As and then enter the new workflow name. New tab opens with the new name but none of the changes. The changes remain on the original workflow unsaved. It’s incredibly frustrating because it basically forces you to either save as before you make any changes or to paradoxically save as the old workflow logic rather than the new. Save as should be equivalent to normal save but with a new name, like it used to work

Steps to Reproduce

See above

How is this affecting you?

Feature doesn't work as expected

ComfyUI Frontend Version

1.27.3

Browser

Chrome/Chromium

Console Errors

Logs

Additional Context

No response

┆Issue is synchronized with this Notion page by Unito

[dosubot]

Hi @hablaba! I'm Dosu and I’m helping the ComfyUI_frontend team.

This is a known issue in the ComfyUI frontend: when you use 'File → Save As' after making changes, the new workflow is created without your recent edits, and the original workflow remains unsaved. This behavior has been reported by other users and discussed in detail in GitHub issue #1505. The current implementation creates a new copy of the workflow but does not persist unsaved changes to the new file, which is different from the typical 'Save As' behavior found in most software.

The underlying cause appears to be that the persistence logic saves the current workflow state but does not explicitly handle copying or renaming workflows with unsaved changes during 'Save As'—so the new workflow tab opens with the last saved state, not your latest edits. This has led to confusion and frustration for users expecting 'Save As' to duplicate the current state under a new name, including all unsaved changes. There is no official workaround documented, and recent updates have not addressed this bug yet. You can follow the ongoing discussion and any future fixes in the linked issue.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[hablaba]

That issue really isn’t related

[dosubot]

Thanks for clarifying—the issue you reported is not tracked in the previously referenced thread. Based on the code and recent changes, the current 'Save As' logic does not save unsaved changes; it creates a new workflow using only the last saved state, not your latest edits. This is a gap in the persistence logic, and there are no existing tickets or documentation that specifically address this bug or offer a workaround. Recent UI updates have made 'Save As' easier to access, but haven't changed this behavior. If you need more technical details or want to discuss possible workarounds, let me know!
Relevant code details

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[Steudio]

Are you using subgraphs?
I’ve had problems with saving or switching workflows, where ComfyUI was resetting the workflow to its last saved state.
The cause was that ComfyUI unexpectedly downgraded and corrupted most of my subgraphs, which I then had to fix one by one.
After fixing the subgraphs, saving worked as expected.

[hablaba]

It happens both with and without subgraphs, so your experience doesn’t sound like what I’m describing. In particular since when I do have subgraphs they aren’t corrupt and my ComfyUI is fully upgraded. There isn’t an error - this is just incorrect UX behavior compared to how Save As used to work and how it works in all other software

[hablaba]

And to be clear this is a regression that started in the last couple weeks. It’s a new behavior

[Steudio]

The last thing I can think of is to check the browser console (F12), as that’s how I found something was wrong.

[hablaba]

No offense but I’m not asking for your help to debug, I am reporting an obvious bug. I am quite capable of debugging, upgrading, etc. This is just a bug that needed to be reported so it can be fixed.

[hablaba]

Reverting to non nightly frontend did fix this, so clearly it’s a regression introduced since last stable release