Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature]: Extend background catalogAutoRefresh to fan out to enabled client integrations (Grok, Claude Desktop, Cline, etc.)

Closed
  • Is something wrong?
#6,784 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
backend

Research direction

Start in src/codex/catalog-auto-refresh.ts, where startCatalogAutoRefresh's tick() only converges the Codex catalog when outcome.changed is true. Then read syncEnabledClientIntegrations in src/server/management/config-routes.ts and refreshOwnedCatalogIntegrations in src/integrations/catalog-refresh.ts to reuse their fan-out. Done means a changed background refresh also updates enabled client files, with a failure in one client logged without stopping the others.

Written by the indexing model from the issue text.

Description

catalog enhancement
Area

Catalog / models

What are you trying to accomplish?

I use OpenCodex with multiple client integrations and agent harnesses simultaneously on the same machine (e.g. Codex, Grok CLI, Claude Desktop, Cline, and OpenCode). When upstream model providers release new models or update available rosters, I want all configured client harnesses to automatically receive the updated model catalog without requiring me to run manual CLI commands or restart/reconfigure OpenCodex.

What prevents this today?

While manual commands like ocx sync and dashboard config mutations perform multi-client fan-out sync via syncEnabledClientIntegrations (propagating changes to Grok, Claude Desktop, and owned integrations such as Cline, OpenCode, Pi, etc.), the background periodic auto-refresh mechanism (startCatalogAutoRefresh in src/codex/catalog-auto-refresh.ts) only converges the Codex client catalog (createManagementConvergeCodex with scope: 'catalog').

As a result, when new models appear from upstream providers in the background, only Codex receives the update. Other connected client harnesses continue to hold stale model lists until a manual ocx sync is executed.

What should OpenCodex do?

When the periodic background catalog refresh detects updated upstream models (outcome.changed === true), it should automatically fan out the refreshed catalog to all enabled and owned client integrations (mirroring the behaviour of syncEnabledClientIntegrations), with isolated error handling so failures in non-critical client files do not disrupt the background cycle.

Observable result: Newly released models from configured providers become immediately visible and selectable across all active client harnesses (e.g. Grok and Claude Desktop) in the background, without requiring a manual ocx sync trigger.

Example usage or interface

Workflow comparison:

Before:

  1. Upstream provider releases a new model (e.g. claude-sonnet-5-5 or deepseek-v4).
  2. OpenCodex background catalog auto-refresh detects the change and updates the Codex catalog in CODEX_HOME.
  3. Grok (~/.grok/config.toml) and Claude Desktop (claude_desktop_config.json) remain unchanged with stale model lists.
  4. User must manually run ocx sync to push the new models to Grok/Claude Desktop.

After:

  1. Upstream provider releases a new model.
  2. Background catalog auto-refresh detects the change, updates Codex, and triggers fan-out synchronization to all enabled client integrations.
  3. Grok, Claude Desktop, and other enabled clients immediately see the new models without manual user intervention.
Alternatives or workarounds

Running ocx sync manually in a terminal whenever upstream model rosters change.

Additional context
  • Relevant source: src/codex/catalog-auto-refresh.ts (startCatalogAutoRefresh / ick())
  • Multi-client sync implementation: src/server/management/config-routes.ts (syncEnabledClientIntegrations) and src/integrations/catalog-refresh.ts (
    efreshOwnedCatalogIntegrations)
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.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
7h 50m
Merged PRs (30d)
645

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.