UX: self-update, ambiguous "Update All", and missing ComfyUI/frontend version status

First, credit where credit is due: I really appreciate the recent UI redesign.

The new window/modal approach feels considerably more "native" and integrated with ComfyUI than the older Manager UI did, and I think this is definitely a step in the right direction.

That said, after temporarily switching back to the Legacy Manager, I ran into a few very basic questions that I still cannot answer from the UI itself.

## 1. How is ComfyUI-Manager itself supposed to be updated?

The Manager clearly shows its own version in the title bar:

**ComfyUI Manager V4.2.2**

However, if I open **Custom Nodes Manager** and look at my installed extensions, ComfyUI-Manager itself does not appear there.

So how exactly is the Manager itself supposed to be updated?

Does `Update All` also update the Manager?

Is there some special self-update mechanism?

Does the user have to update it externally?

The slightly ironic situation here is that the extension whose job is to manage extensions seems to manage everything except itself — or at least the UI gives no indication of how it manages itself.

If self-update is already implemented, I think it should simply be exposed explicitly:

> ComfyUI Manager
> Installed: 4.2.2
> Latest: 4.x.x
> Status: Up to date / Update available
> [Update]

No guessing required.

---

## 2. What exactly does "Update All" mean?

There is a standalone button called:

**Update All**

But "all" is an extremely ambiguous word in the context of ComfyUI.

Does it mean:

- all custom nodes?
- all custom nodes + ComfyUI-Manager?
- ComfyUI itself?
- ComfyUI Frontend?
- Python dependencies?
- everything managed by Manager?

I assume it probably means **all installed custom nodes**, especially since there is a separate `Update ComfyUI` button.

But the user should not have to reverse-engineer the meaning of the word "All" from the surrounding buttons.

This is made worse by the layout: the button is floating in what is essentially a soup of unrelated buttons, with no frame, group heading, section title, description, or other visual hierarchy telling the user what it belongs to.

If the operation means "update all custom nodes", why not simply call it:

**Update All Custom Nodes**

That immediately removes the ambiguity.

Alternatively, group related operations visually:

> **Custom Nodes**
>
> Custom Nodes Manager
> Install Missing Custom Nodes
> Update All Custom Nodes

> **ComfyUI**
>
> Update ComfyUI
> Switch ComfyUI

> **Manager**
>
> Check Manager Update
> Update Manager

The current window has plenty of empty space, so I don't think clarity needs to be sacrificed for compactness.

---

## 3. Can we finally get installed/latest version information for ComfyUI, ComfyUI Frontend and Manager?

This is the one that surprises me the most.

As of **August 2026**, I still cannot find a simple place in Manager that tells me, at a glance:

> ComfyUI: installed version / latest version / status
> ComfyUI Frontend: installed version / latest version / status
> ComfyUI-Manager: latest version / status

Manager has buttons for updating and switching ComfyUI, but that is not the same thing as clearly answering the most basic question an update manager should answer:

**"Am I currently up to date?"**

So I have to ask, with some degree of disbelief: when will the glorious day finally arrive when ComfyUI-Manager can provide this extremely futuristic functionality known as... displaying three version numbers and comparing them with the latest available versions? :)

Joking aside, I genuinely think this is basic and essential information for a software/update manager.

A simple status panel would solve it:

| Component | Installed | Latest | Status |
|---|---:|---:|---|
| ComfyUI | 0.x.x | 0.x.x | ✅ Up to date |
| ComfyUI Frontend | 1.x.x | 1.x.x | ⬆ Update available |
| ComfyUI-Manager | 4.2.2 | 4.x.x | ✅ Up to date |

Optionally each row could have its own **Check / Update** button.

---

## Example from my own ComfyUI plugins

This is not just a theoretical suggestion. I already use a very simple version of this approach in my own plugins, including **OpenPose Studio** and **Styler Pipeline**.

In their modal interfaces, the user can see the installed plugin version from the **About** tab.

There is also a **Check for Updates** mechanism which compares the version declared in the local `pyproject.toml` against the current version published remotely on GitHub.

More recently I also added an automatic update check when the plugin modal is opened, rate-limited to **one remote check every 12 hours** so it does not continuously hit GitHub.

When a newer version is detected, an **Update Available · vX.X.X** badge appears in the title bar.

Clicking that badge opens the appropriate manager depending on the user's installation: the new Extensions Manager when available, or the Legacy Manager otherwise.

The implementation is deliberately simple. The plugin does not need to actually perform its own update; it just needs to answer:

1. What version do I have?
2. What is the latest version?
3. Am I up to date?
4. If not, where do I click to update?

I think ComfyUI-Manager itself would benefit enormously from applying the same concept to:

- **ComfyUI-Manager**
- **ComfyUI**
- **ComfyUI Frontend**

with a cached automatic check every few hours and an explicit manual **Check for Updates** option.

---

To summarize, I think the recent visual redesign is a very welcome improvement, but these three areas still make the Legacy Manager unnecessarily difficult to understand:

1. Make Manager self-update explicit and visible.
2. Rename or visually contextualize the ambiguous `Update All` button.
3. Show installed/latest/update status for Manager, ComfyUI and ComfyUI Frontend.

These are small UI additions, but in my opinion they would make the Manager substantially more intuitive and would eliminate a surprising amount of uncertainty for users.

Start by locating the Legacy Manager entry points for Custom Nodes Manager, Update All, Update ComfyUI, and the Manager title bar; the issue names no files or tests. Define the update scope and version sources for ComfyUI, ComfyUI Frontend, and ComfyUI-Manager, then verify that the UI clearly shows installed/latest versions, status, and the intended update actions.

Written by the indexing model from the issue text.