Skip to content

[Feature]: Periodic auto-refresh of provider model catalog (pick up newly released models without manual 'ocx sync') #3630

Closed

Description

@doublewater777

Problem

Newly released upstream models are not picked up automatically while the proxy is running. They only appear after a manual ocx sync (or a proxy restart, since ocx start auto-syncs).

Example: OpenAI added a new native model upstream (visible via GET /backend-api/codex/models for my account), but the running proxy kept serving the older catalog. The new model was absent from /v1/models and from ~/.codex/opencodex-catalog.json until I ran ocx sync by hand.

Why this matters

  • Discovering that a model is "missing" currently requires noticing it elsewhere and then remembering to run ocx sync.
  • The Codex Desktop model picker additionally keeps its own cached model/list, so even after a manual sync the desktop app can keep showing the stale list until app-server processes restart. This makes the whole flow feel manual and error-prone.

Proposed behavior

Add an opt-in (or default-on) periodic catalog refresh so the running proxy re-discovers provider models on an interval and updates the served catalog without a manual ocx sync. Concretely:

  1. A configurable interval (e.g. catalogRefreshIntervalMinutes, default maybe 30-60 min, 0 = off) that triggers the same code path as ocx sync for model discovery + catalog write.
  2. On successful refresh, if the served model set changed, also refresh the Codex-side catalog/cache the same way ocx sync does today (respecting the existing "external provider owns config.toml" guard).
  3. Ideally surface "N new model(s) discovered" in the request log / dashboard so users can see when the catalog changed.
  4. Optional: a --restart-codex-style hook (or an in-band signal) so the Codex Desktop app-server drops its cached model/list after a catalog change, without requiring the user to restart the desktop app manually.

Alternatives considered

  • Manual ocx sync (current behavior) — works but easy to forget.
  • A user-side cron/launchd job calling ocx sync — works around it, but is per-machine setup that the tool could reasonably own.

Environment

  • opencodex 2.41.0 (npm @bitkyc08/opencodex)
  • macOS (arm64), Codex CLI 0.153.2

Activity

  1. added
    enhancementNew feature or request
    catalogModel catalog, slugs, visibility, routed entries
    cliCLI, config inject, packaging flags
    on Sep 5, 2026
  2. lidge-jun commented on Sep 5, 2026

    @lidge-jun
    Owner

    리뷰 · 우선순위 40 / 80

    이 이슈는 프록시가 이미 떠 있는 동안 새로 나온 upstream 모델이 /v1/models와 ~/.codex/opencodex-catalog.json에 안 보이는 문제를 말합니다. 지금은 손으로 ocx sync를 치거나, ocx start가 자동 sync를 돌릴 때만 카탈로그가 갱신됩니다. 제안은 catalogRefreshIntervalMinutes 같은 설정으로 주기적으로 같은 sync 경로를 돌리고, 모델 집합이 바뀌면 Codex 쪽 카탈로그/캐시도 같이 맞추며, 가능하면 Codex Desktop의 메모리 model/list까지 갱신 신호(또는 --restart-codex류)를 주자는 것입니다.

    지금 dev(a53775103)에는 이미 관련 조각이 흩어져 있습니다. CLI help/registry의 ocx sync / ocx sync-cache(--restart-codex, --restart-desktop-app), src/codex/sync.ts와 src/codex/catalog/sync.ts의 catalog-only 경로, src/cli/catalog-prewarm.ts의 시작 시 prewarm, doctor가 app-server PID가 카탈로그보다 오래됐다고 경고하는 문장, account 변경 후 catalog refresh pending 경고(src/cli/account-catalog-refresh.ts)가 그것입니다. 즉 “한 번 sync하면 디스크 카탈로그는 맞출 수 있다”는 축은 이미 있고, 이 이슈가 새로 요청하는 핵심은 실행 중 주기 타이머와 Desktop 인메모리 캐시까지 자동으로 흔들기입니다. 후자는 Windows에서 --restart-desktop-app 이슈(#2292 계열)와도 겹칩니다.

    우선순위는 중간 아래입니다. 사용자가 새 모델을 놓치는 체감은 진짜지만, 기본값을 켜면 모든 프로바이더에 주기적인 discovery/OAuth 트래픽이 생기고, 외부 provider가 config.toml을 소유한 경우의 catalog-only 가드와도 맞춰야 합니다. 지금 HEAD 열차(메인 계정 99% hard lock GUI, 외부 이미지 왕복, effort CLI)와는 다른 스택입니다. 바로 블로커로 넣기보다, 기존 sync 경로를 재사용하는 opt-in 타이머로 설계 범위를 좁히는 편이 맞습니다.

    경로/심볼 - ocx sync / src/codex/sync.ts - 이미 수동·시작 시 갱신과 external-owner catalog-only 가드가 있다. 새 타이머는 이 경로를 그대로 호출해야지 별도 fetch를 새로 짜면 안 된다.
    경로/심볼 - src/cli/catalog-prewarm.ts - CLI 프로세스 시작 prewarm만 있고, 떠 있는 proxy 서버의 주기 루프는 없다. 타이머는 server 쪽 lifetime에 걸어야 한다.
    경로/심볼 - doctor app-server stale 경고 / --restart-codex·--restart-desktop-app - Desktop model/list 캐시 문제는 이미 반쯤 도구화돼 있다. 자동 restart를 기본으로 켤지는 정책 결정이다.
    경로/심볼 - 기본값 on vs off - 이슈는 opt-in 또는 default-on을 열어 둔다. default-on이면 쿼타·레이트리밋·OAuth refresh 비용이 전 사용자에게 간다.
    이슈 본문 - 환경이 2.41.0이다. HEAD는 2.43.0대이며 sync/doctor 문구가 더 늘었다. 재현 전에 최신 ocx sync+doctor 경고만으로도 완화되는지 한 번 확인해 달라고 댓글에 남겨도 좋다.

    메인테이너의 판단이 필요한 지점

    너의 추천
    바로 구현 PR을 급히 받지 말고, 범위를 “proxy 프로세스 안의 opt-in interval → 기존 ocx sync/catalog-only 경로 재사용 → 변경 시 로그/대시보드 이벤트”로 고정한 설계 메모를 먼저 받기. Desktop 자동 restart는 기본 제외(기존 플래그·doctor 안내 유지). 우선순위 40 — 유용하지만 현재 dev 최적화 축은 아님. help wanted로 두되 needs-design을 붙이는 쪽을 추천.

    이 댓글은 grok-bot이 작성했습니다

  3. lidge-jun commented on Sep 14, 2026

    @lidge-jun
    Owner

    Landed on dev by 43f4450.

    There is now an opt-in periodic catalog refresh. It converges through the same management converge funnel an explicit ocx sync uses, so a provider that releases a model overnight shows up without anyone running a command. The config section is additive and strict: absent, disabled, or malformed all degrade to off while the rest of the config is preserved, so an operator who sets nothing keeps exactly the behavior they had.

    Two things this issue mentioned are not in that merge, and I would rather say so than close it silently as fully done: the "N new models discovered" count, and the Codex Desktop cache-drop hook that would make a refreshed model visible in an already-open client without a restart. If either matters to you, please open a focused issue for it and it will be scheduled; they are small and separable now that the scheduler exists.

    Closing the periodic-refresh ask itself as delivered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    catalogModel catalog, slugs, visibility, routed entriescliCLI, config inject, packaging flagsenhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions