Expose Unity Gateway model catalogs to Codex App

[andy-xu-db]

Summary

Codex App starts its own app server and does not receive the catalog overrides passed by ug codex. Successful model discovery now validates the catalog with the installed Codex binary, refreshes ~/.ucode/codex-model-catalog.json, and adds its model_catalog_json reference to shared Codex config. CLI launches retain their workspace/source-scoped catalog overrides. Managed static lists use the same stable path and retain their existing local build/validation flow.

Existing custom catalogs, including Isaac's, and custom providers are preserved. Unreadable shared config is not overwritten, and a failed refresh does not replace the previous catalog file. Discovery or validation failure removes ug's shared reference; incompatible catalogs stop the launch with an actionable error. Reconfiguration and revert also clean up the reference owned by ug.

Codex loads model_catalog_json when an app server starts. A persistent server keeps its startup list after the catalog file changes, and reconnecting does not reload it. Whenever ug adds, refreshes, or removes its shared catalog, it now reports that the connected host's app server must be restarted after active tasks finish. It does not restart automatically because that would interrupt running work. For a standalone managed daemon the command is codex app-server daemon restart; npm/manual app servers must be restarted by the process or application that owns them.

Before ug installs or updates Codex, including forwarded ug codex update, it detaches its shared catalog reference. The next successful configure/discovery republishes it after validation. The app's gateway provider/authentication must already be configured; validation covers the host's Codex binary, not a separate desktop binary on another machine. The most recently refreshed workspace/source supplies the shared catalog.

Testing

• After merging the latest main, 771 focused Codex/catalog/agent/CLI/routing tests and 89 model-discovery/integration-contract tests passed locally.
• Ruff lint/format checks and git diff --check passed.
• Real Codex 0.154.0 accepted its bundled catalog and rejected an incomplete catalog through the validator, using an isolated temporary home.
• A fresh app server using the actual user config returned exactly the seven visible gateway models from the shared catalog.
• A mount-isolated real managed ug configure run on final be44d393 declared seven gateway models, wrote the stable shared app catalog through the public CLI, emitted the restart notice, and a real Codex 0.154.0 app-server returned exactly those seven visible picker entries in order with no native extras. The remote host has no Desktop/Electron executable, so this validates the exact model/list payload consumed by the picker rather than GUI rendering.
• An isolated real standalone daemon started with catalog A, kept A after catalog B replaced the same file and a client reconnected, while a fresh one-shot app server saw B. codex app-server daemon restart then made new daemon connections return B.
• The same isolated check confirmed daemon stop/daemon restart reject an npm/manual codex app-server --listen unix:// process as unmanaged, so the instructions distinguish the two installation types.
• Extended integration journeys assert bare app-server model lists for discovered and static catalogs, real ug revert cleanup, user-setting preservation, and the restart notice after managed configuration.
• Full PR CI passed on the mergeable final be44d393 commit: unit and gateway API tests, every agent-launch lane, installation, workspace validation, managed Claude/Codex, both agents' smoke/full journeys, and the required e2e gate all succeeded. The managed Codex lane includes the combined independent-provider, stable app catalog, fresh app-server, revert, and restart-guidance assertions.

Desktop GUI rendering and inference through the desktop app remain untested.