Codex Desktop should preserve local history visibility and continuation across providers/accounts

What version of the Codex App are you using?

Codex Desktop on Windows. I can provide the exact build from the About dialog if needed.

What subscription do you have?

Multiple paid OpenAI / ChatGPT accounts, plus custom OpenAI-compatible API providers configured through a provider/account switcher.

What platform is your computer?

Windows, using Codex Desktop with the default local Codex home under %USERPROFILE%\.codex.

What issue are you seeing?

Switching between OpenAI accounts and OpenAI-compatible custom providers makes local Codex Desktop history unreliable:

• Old local sessions disappear from the Codex Desktop project/history view after switching provider/account.
• Local rollout files still exist under %USERPROFILE%\.codex\sessions and %USERPROFILE%\.codex\archived_sessions.
• The visible provider metadata can differ between sessions, for example openai and custom.
• Existing third-party sync tools can make the sessions visible again by rewriting local metadata, but this is risky and can leave the user unsure whether history was actually lost.
• Many sessions contain encrypted_content; after switching provider/account, visible sessions may still fail to continue if encrypted history is sent to the wrong account/provider.

I understand that #15219 was closed by #19287, which restores the persisted model_provider during resume. That seems to address one important continuation path. However, the broader Desktop user problem remains:

1. Local history discovery/project-side visibility should not depend on the currently active provider/account.
2. Codex Desktop should make it clear which provider/account owns a persisted encrypted thread.
3. Resuming a thread should either route to the original provider/account automatically or show an actionable UI error instead of pushing users toward local SQLite/JSONL rewrites.
4. There should be an official repair/diagnostic path for local history indexes when Codex Desktop fails to show sessions that still exist on disk.

Local evidence

On my machine, a local diagnostic script reports:

Codex home: C:\Users\ShenKongDiao\.codex
Current provider: openai
Rollout files: 20
Rollout providers: {'openai': 12, 'custom': 8}
Encrypted content providers: {'openai': 12, 'custom': 8}
SQLite thread indexes:
  state_5.sqlite: threads=20, providers={'custom': 8, 'openai': 12}
logs_2.sqlite: present, backup-only

This means the sessions are physically present, but provider/account switching can make them disappear from normal Desktop history/project surfaces. All detected sessions contain encrypted_content, so simply rewriting model_provider metadata is not a safe complete migration.

Steps to reproduce

1. Use Codex Desktop with the built-in OpenAI provider/account and create local project sessions.
2. Switch to another OpenAI account or to a custom OpenAI-compatible provider.
3. Reopen Codex Desktop and inspect the local project/history view.
4. Observe that sessions from the previous account/provider may be hidden, even though rollout files and local SQLite metadata still exist.
5. If local metadata is rewritten to force visibility, try continuing an old encrypted session from a different account/provider.
6. Observe that continuation can still fail because encrypted history belongs to the original provider/account context.

Expected behavior

• Codex Desktop local history/project views should list local sessions across providers/accounts by default, or provide a clear filter that defaults to "all local sessions".
• Each session should preserve and display its original provider/account identity.
• Resuming should use the persisted provider/account context when possible.
• If a session cannot be continued because the required provider/account credential is unavailable, Codex should show a precise error and offer recovery options instead of silently hiding the thread.
• Users should not need to rewrite %USERPROFILE%\.codex\sessions or SQLite metadata to recover history visibility.

Actual behavior

• Provider/account switching makes history appear to disappear.
• Users are pushed toward third-party tools or hand-written scripts that mutate local rollout JSONL and SQLite metadata.
• Those workarounds can restore list visibility but cannot safely solve encrypted-content continuation across accounts/providers.

Related issues / PRs

• #15494: Switching model_provider hides existing local sessions from resume/fork/history. Closed as not planned, but it describes the visibility/discovery side of this problem.
• #15219: Resume did not restore persisted model_provider, causing invalid_encrypted_content.
• #19287: Merged fix for restoring persisted model provider on resume.

Suggested official fix

Please consider treating this as two separate product behaviors:

1. History discovery: Desktop project/history views should discover local sessions across providers/accounts without requiring metadata rewrites.
2. Continuation: Resume should use the persisted provider/account identity for encrypted sessions, and if credentials are unavailable, show a recoverable UI state.

An official diagnostic command or Desktop repair action would also help, for example:

codex doctor history
codex repair-history-index

These commands could verify rollout files, SQLite thread indexes, encrypted-content ownership, workspace root matching, and project visibility without changing auth data.

Additional information

I am not requesting that encrypted content be decrypted or migrated across accounts. I am asking for official history visibility and continuation semantics so local sessions do not appear lost after normal provider/account switching.