Cursor model list never drops models after an account change; refreshes only ever add to it #28008

What happened

After switching Cursor accounts in the desktop app, the Cursor provider's model picker showed 48 models, including ones my current account can't use (for example Claude Opus 5.5, Gemini 4 Argon, GPT-5.6 Sol). My current account is on the Plus tier and only has access to 4 models: grok-4.7, grok-4.6, composer-2.5 and grok-4.5. agent models in the terminal lists the correct ones. The extra models came from a previous Cursor account with broader access, which had been signed out hours earlier. Refreshing the provider didn't remove them. They went away only after I moved ~/.t3/caches/cursor.json aside and relaunched.

Diagnosis

Not a Cursor SDK problem. With the current account's key, Cursor.models.list() (@cursor/sdk 1.0.35, GET /v1/models) returns exactly the 4 models, matching agent models. T3 Code's catalog code (CursorSdkCatalog.ts, status.ts) passes the result through unchanged.

The extra models are retained by ProviderRegistry.ts, which merges every refresh into the previous snapshot (mergeProviderSnapshot → mergeProviderModels):

• shouldRetainMissingProviderModels returns true for every driver not special-cased as pi, acpRegistry, grok, antigravity, codex or opencode (line 188 on main: return true). The cursor driver falls through to it.
• With that flag set, mergeProviderModels returns the new models plus every previous non-custom model absent from the new list.
• The merged list is persisted to ~/.t3/caches/cursor.json, so it survives restarts. The snapshot is also repopulated from that file at startup.
• A refresh can therefore only add models, never remove them, even when the check succeeds.

In my cache the 4 current models came first, followed by 44 retained from the old account, which is consistent with [...mergedModels, ...retainedPrevious]. After switching to an API key that returned 4 models (the trace shows the catalog reads succeeded), the saved list was still 48.

By reading the code only (not reproduced), claudeAgent, fx and muse also fall through to return true, so they should keep models that disappear too. The pi, acpRegistry, grok, codex, opencode and antigravity clauses retain old models only while a probe is incomplete or errored, which looks intended.

Suggested fixes (complementary):

1. Retain previous models only while the probe is incomplete or failed, as the grok clause does (!(installed && status === "ready")), and apply that to the cursor driver. A successful discovery should replace the list, which also covers plan downgrades and retired models within the same account.
2. As a safeguard, when the signed-in identity (for example auth.email, which the cache already stores) differs from the cached snapshot's, discard the cached models instead of merging into them. A probe failure shouldn't resurrect another account's models.

Steps to reproduce

1. In Settings > Providers > Cursor, sign in with an account that has access to many models (like Premium).
2. Wait for the model list to load.
3. Sign out, then sign in with an account on a lower tier with access to fewer models (like Plus). Alternatively, downgrade the plan.
4. Refresh the provider, or restart the app.
5. Observe that the picker still lists the models from the first account.
6. Move ~/.t3/caches/cursor.json aside and relaunch. The list is now correct.

I didn't reproduce this on a clean install from scratch. The above is what happened here, plus what the code does.

Version

0.1.5 (T3 Code (Beta) desktop app, matching the local server's serverVersion 0.1.5). Code references are from tag v0.1.5 and are unchanged on main.

Environment

macOS (Darwin arm64), desktop app against the local server, Cursor CLI 2026.10.22-27dcf5f (Plus tier). Browser sign-in.

Evidence

# Cursor.models.list with the current account's key (4 entries)
grok-4.7
grok-4.6
composer-2.5
grok-4.5

# agent models (same set, with variants)
composer-2.5, grok-4.7-{low,medium,high,xhigh}[-fast], cursor-grok-4.6-medium, cursor-grok-4.5-medium

# ~/.t3/caches/cursor.json before moving it aside: 48 models; first 4 as above, then
# 'default', claude-opus-5-5, ..., gpt-5.6-sol, gemini-4-argon, muse-wonder-1.0, kimi-k3, glm-5.2, ...
# after moving it aside and relaunching: 4 models

# trace: CursorSdkCatalog.read spans exit Success while the saved list still had 48 entries

Related issues

• [Bug]: Cursor Plus subscription fails with 'Model unavailable on Plus' on all included models #24386: Cursor Plus accounts see models they can't use ("Model unavailable on Plus"). It's a different failure (the turn is rejected), but it shares the theme that the Cursor model list doesn't reflect the account's access. This issue is about the picker keeping models that had been removed, not about turns failing.
• I found no existing issue about the model list retaining removed models.

Fix applied or workaround

Moved ~/.t3/caches/cursor.json aside (renamed, not deleted) and relaunched, with the user's approval. Nothing else was changed, and no source was patched.

Filed by

claude (claude-sonnet-5-5) via t3 triage (Claude Code)