Codex Desktop visible chats fail to resume when saved provider id is no longer configured

[TheLonelyDevil9]

This was generated by AI during triage.

What version of the Codex App are you using (From "About Codex" dialog)?

Codex Desktop / bundled CLI 0.126.0-alpha.8 (26.422.x Windows app package).

What subscription do you have?

Paid account, using a custom OpenAI-compatible provider configuration.

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Some pinned / visible Codex Desktop chats failed to resume with this toast:

Failed to resume chat
failed to load configuration: Model provider `custom` not found

The affected chats were still visible in the Desktop sidebar, but selecting/resuming them failed before any model request was made.

Local sanitized evidence:

• Active config.toml had model_provider = "current-provider" and defined [model_providers.current-provider].
• The active config did not define [model_providers.custom].
• The affected thread records still had model_provider = "custom" in local thread metadata.
• The affected rollout JSONL files also had session_meta.payload.model_provider = "custom" on their first metadata entry.
• Other chats whose saved provider matched the active provider resumed normally.

A local repair that changed only the stale local metadata from custom to the currently defined provider made the affected chats eligible to resume again:

• update local threads.model_provider for affected rows
• update the first session_meta.payload.model_provider entry in the corresponding rollout JSONL files

No chat content, API keys, endpoint URLs, or local paths are included here.

What steps can reproduce the bug?

1. Configure Codex Desktop with a custom model provider whose provider id is custom.

2. Create one or more chats, ideally pinning them so they remain visible in the Desktop sidebar.

3. Change the provider id in config.toml so the active provider is now a different id, and remove or rename the [model_providers.custom] table.

4. Restart / reopen Codex Desktop.

5. Select one of the pinned chats created under the old custom provider id.

6. Observe that the chat is visible, but resume fails with:

   Failed to resume chat
   failed to load configuration: Model provider `custom` not found
   

What is the expected behavior?

Codex Desktop should not leave visible chats in an unrecoverable resume state just because the persisted provider id no longer exists in the current config.

A few acceptable behaviors would be:

• preserve enough provider configuration with the session to resume under the original provider even if the active config changed;
• show an actionable recovery UI, such as "provider custom is missing; choose an available provider or re-add this provider";
• provide an official repair command that updates stale local provider metadata safely;
• at minimum, include the affected session id and a clear remediation hint in the error.

Additional information

This is related to, but narrower than, the broader provider/history visibility issues in #20004 and #20184. In this case the affected chats were visible, but resume failed because the saved provider id referenced a provider table that no longer existed.

The underlying data was not deleted. A local metadata-only repair restored the affected records to the current provider id.