UX: distinguish hub model changes that are saved, synced, and active on each client #4209

Area

Multiple areas

What are you trying to accomplish?

Change model visibility or ordering on a central hub and know whether the change is saved on the hub, fetched by a particular client, and visible in an already-running Codex instance.

What prevents this today?

The Models page's main description says changes apply on the next Codex turn and do not need a restart, while the picker-order explanation on the same page says the old catalog may remain until the client is reopened. Visibility and ordering may legitimately have different refresh semantics, but the user is not told which completion state applies to the action just taken, particularly when the dashboard is on a different machine from Codex.

The connection CLI already exposes catalog synchronization timestamps, yet those machine-specific facts are not the clear completion story of the model-editing flow. Operators have to compare terminals, browser pages, and the actual picker to work out which step remains.

What should OpenCodex do?

• Identify the scope of the edit: hub catalog versus a local client setting.
• After a save, distinguish “Saved on hub,” “Fetched by this client,” and “Running client state unknown/reopen needed” when applicable. Do not claim active adoption from a successful write alone.
• State the behavior for the specific action, such as visibility versus ordering, rather than presenting an unconditional no-restart promise above all controls.
• Surface the last client catalog sync time and the one applicable next action. Keep diagnostic paths/ports in an expandable detail view.
• If active-runtime acknowledgement is unavailable, say “not verified” rather than adding a green completed state.
• Never automatically restart a running client or interrupt work to make the status look complete.

Example usage or interface

Model visibility saved on Hub A.
This computer last fetched the catalog 8 minutes ago.
[Sync this computer]

After sync:
Catalog fetched. This running client may still show its previous list.
[Show application-specific refresh instructions]

For actions known to apply live, show their verified live semantics instead; this is not a proposal to require restarts everywhere.

Alternatives or workarounds

Manually compare ocx connect status --json, the hub configuration, and the client model picker. This exposes the raw facts but leaves the operator to infer their relationship.

Additional context

Observed in the Korean Models screen served by dev 2.51.0, commit 6d3ad12e3fbfd8423f1515a467db4d3349732886.

• gui/src/i18n/ko.ts:529: next-turn/no-restart description.
• gui/src/i18n/ko.ts:590: may retain the old catalog until reopening the client.
• src/client/connect.ts:576: connection metadata includes catalog synchronization state.

Related #3729 covers catalog delivery mechanics and #3774 covers drag-and-drop picker ordering. This proposal covers action-specific status, scope, and recovery communication across the hub/client boundary. No propagation timing claim was measured in this audit, and no user model settings were changed to manufacture a reproduction.

Design rationale: truthful success/partial/stale states; one primary next action; preserve useful density in an expert tool instead of hiding everything behind a long wizard. Acceptance should cover hub-only save, unsynced client, synced-but-running client, already-current state, failed sync, and an offline hub.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.