[Bug]: Disabling CLI update checks also blocks new model catalog

[makeavish]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On T3 Code 0.0.42 with Claude Code 2.1.280, turn off Settings → General → Provider update checks.
2. Refresh provider status and inspect the Claude model list. Opus 5.5 is absent.
3. Turn the setting back on and refresh. Opus 5.5 appears without updating either app.

Expected behavior

Disabling CLI version checks should not silently block model-catalog updates. Model metadata should refresh independently, or the setting should clearly explain the coupling and offer a separate refresh.

Actual behavior

The setting is described as checking provider CLI versions, but it also gates the remote model-manifest fetch. A supported new model stays absent from the picker while the setting is off.

Impact

Minor bug or occasional failure: new models remain undiscoverable until the setting is enabled or a later app release bundles them.

Version or commit

T3 Code 0.0.42

Environment

Claude Code 2.1.280; Claude Opus 5.5

Workaround

Enable Provider update checks and refresh provider status.

[juliusmarminge]

Triage

Confirmed on current main and on v0.0.42. This is one phone-home switch doing two jobs, and the settings copy only describes the first.

enableProviderUpdateChecks (default on) skips the npm "latest version" lookup for installed provider CLIs. The same flag also returns before ModelManifest fetches model-manifest.json from main. That includes an explicit refresh: Settings → Providers → Refresh provider status sends refreshModels: true, which calls ModelManifest.forceRefresh, and forceRefresh still bails out when the switch is off. A manifest already cached on disk is kept; the switch stops new network fetches, it does not delete data the server already holds. Both paths are covered by ModelManifest.test.ts ("does not fetch when provider update checks are disabled") and have been since the hosted manifest landed in #8227.

The settings text does not say this. Web (Settings → General → Provider update checks) says "Check installed provider CLIs for newer available versions." Mobile (Check provider updates) says "Check installed provider CLIs for newer versions." The provider health interval copy says those probes refresh model metadata, which they do not while this switch is off.

That matters for Claude specifically. Claude's built-in picker is the manifest catalog, filtered by the installed Claude Code version (docs/internals/model-manifest.md). Codex still takes its model list from the Codex app server and only uses the manifest as a legacy-classification overlay, so this switch does not hide Codex models the same way.

On T3 Code 0.0.42 the bundled manifest is dated 2026-09-12 and has no claude-opus-5-5. That model was added on main in #13094 (minVersion 2.1.280, merged 2026-09-22). Claude Code 2.1.280 meets that floor, so a refresh with the switch on pulls the remote catalog and Opus 5.5 shows up without updating Claude Code or T3 Code. With the switch off, and no newer on-disk manifest, the picker stays on the 0.0.42 bundle.

#13094 is in v0.0.43-nightly.20260922.2123 and v0.0.43-preview.20260923.2138. It is not in the latest stable tag, v0.0.42 (2026-09-15). A build that contains #13094 bundles Opus 5.5, and a newer bundle outranks an older disk cache, so that one model shows up even with checks off. The coupling is unchanged on main: the next model that exists only on the remote manifest stays hidden until the switch is turned back on or a later release bundles it.

No existing issue covers this. Workaround in the report is right: turn Provider update checks back on and refresh provider status.

The gate itself is deliberate. The bug is that the control does not say it also blocks catalog updates, and since #9084 those updates are how new Claude models appear between releases. A fix is either copy on web and mobile that states the coupling, or a separate control so model-catalog refresh is not tied to CLI version checks. Explicit refresh should follow whichever decision we make.

Investigated against main by Grok 4.7 in Cursor.

[john-griffin]

Also had to toggle this to get it working.