Codex Desktop needs a supported recovery path when a thread's persisted model provider is unavailable

What variant of Codex are you using?

Codex Desktop and app-server (observed with app-server 0.147/0.148 behavior).

What feature would you like to see?

Codex Desktop should provide a supported way to continue an existing local thread when the thread's persisted model_provider is no longer present in the current configuration.

A common lifecycle is:

1. A user starts with the built-in openai provider or another existing provider.
2. A local provider manager temporarily installs an OpenAI-compatible proxy as [model_providers.proxy] and sets model_provider = "proxy".
3. Threads are created or resumed through that proxy.
4. The manager later restores the user's original config.toml exactly. The proxy definition is therefore no longer present.
5. The local thread remains intact in the rollout JSONL and state_5.sqlite.
6. Even if Desktop lists all providers (thread/list with modelProviders: []), selecting the thread cannot recover it: Desktop calls thread/resume with the thread's persisted modelProvider (proxy), which is no longer configured.

This is distinct from history discovery. Fixing thread/list visibility alone makes the thread visible but still not usable.

Please provide an official recovery path, for example one of:

• Desktop detects that the persisted provider is unavailable and offers Open with current provider, with an explicit compatibility warning.
• thread/resume accepts a provider override that can optionally be persisted as the thread's latest effective provider.
• A dedicated API such as thread/provider/update atomically updates the canonical rollout metadata and SQLite projection.

The important requirements are:

• Preserve the same thread ID and history.
• Do not fork the thread into two independently progressing copies.
• Do not require users or provider managers to rewrite rollout JSONL and SQLite directly.
• Keep the default safe for encrypted or provider-specific history: migration should be explicit and may be rejected when compatibility cannot be established.

Additional information

Current behavior and constraints observed in source:

• thread/list can enumerate all providers with modelProviders: [].
• thread/resume already has an optional modelProvider parameter, so an external client that knows the thread ID can resume the same ID through a compatible current provider.
• Desktop selects the persisted thread.modelProvider, so a normal sidebar click cannot use that recovery path.
• thread/metadata/update does not expose model-provider changes.
• thread/fork supports a target provider, but creates a second thread ID and produces two potentially divergent conversations.
• Editing only state_5.sqlite is not safe because rollout JSONL remains the durable source and can rebuild the projection.

Related but distinct issues:

• #24648 covers cross-provider history visibility / thread/list filtering.
• #20004 requests broader provider/account-aware visibility and continuation.

This request is specifically for the case where a thread is known and visible, but its persisted provider definition is unavailable and Desktop has no supported same-thread recovery action.

Start with the thread/resume, thread/list, thread/metadata/update, and thread/fork entry points described in the issue, then trace how Desktop selects the persisted thread.modelProvider. Compare the rollout JSONL with the state_5.sqlite projection. Done means a supported explicit recovery path preserves the same thread ID and history without requiring direct data edits or creating a fork.