Switching model_provider hides existing local sessions from resume/fork/history

Summary

Switching model_provider currently hides existing local sessions from multiple Codex surfaces, even though the rollout files and SQLite rows are still present.

Affected flows:

• codex resume --last
• codex fork --last
• TUI /resume / fork picker
• Codex Desktop local history picker and latest-session lookup

This makes local history appear to "disappear" whenever users switch between the built-in OpenAI provider and a custom provider/profile.

Why this matters

A common setup is:

• use built-in OpenAI auth for normal codex
• switch to a custom model_provider for a proxy / Azure / gateway / custom backend
• switch back later

Today, the session data is still on disk, but discovery defaults to the active provider, so prior local sessions are no longer visible from normal resume/history flows.

That pushes users toward risky local workarounds such as rewriting model_provider in rollout files / SQLite just to make history visible again.

Root cause

The problem is in the caller-side discovery defaults, not in storage.

The core listing APIs already support optional provider filtering, but several callers force the current provider by default:

• codex-rs/tui/src/lib.rs
• codex-rs/exec/src/lib.rs
• codex-rs/tui/src/resume_picker.rs
• codex-rs/tui_app_server/src/lib.rs
• codex-rs/tui_app_server/src/resume_picker.rs
• codex-rs/app-server/src/codex_message_processor.rs

There is also an app-server semantic wrinkle:

• model_providers: None is interpreted as "use the current provider"
• an explicit empty list can be treated as "all providers"

So even when the UI wants "show all local sessions", it can still accidentally fall back to the active provider.

Reproduction

1. Start with built-in OpenAI auth and create a few local sessions.
2. Switch config.toml to a custom model_provider.
3. Try any of the following:

• codex resume --last
• codex fork --last
• /resume inside TUI
• open Codex Desktop and browse local history

1. Observe that previously saved local sessions are missing from discovery/history, even though they still exist under ~/.codex/sessions and in state_5.sqlite.
2. Switch the provider back and the sessions reappear.

Expected behavior

Local session discovery should default to "all local providers" unless the user explicitly asks to filter by provider.

Provider identity should still be preserved per thread for actual resume/fork execution. This issue is about history visibility and local discovery, not about erasing provider metadata.

Proposed fix

Change the default local discovery behavior to be cross-provider:

• resume --last / fork --last should look across local providers
• local TUI and Desktop history pickers should list local CLI / VS Code sessions across providers
• app-server clients should use an explicit empty provider list to mean "all providers" rather than relying on None

This seems materially safer and smaller than introducing a built-in sync/migration command that rewrites rollout metadata and SQLite state.

Why not a built-in sync command?

I initially considered proposing an official sync command that rewrites local model_provider metadata so history becomes visible again.

That approach seems much more invasive because it would need to handle:

• rollout file rewrites
• SQLite updates
• locked files
• backup / rollback semantics
• future schema / migration compatibility

The visibility problem appears solvable without mutating history at all: make discovery cross-provider by default.

Prepared implementation

I already prepared a patch on my fork that takes this approach:

• branch: codex/cross-provider-session-discovery
• commit: 0592e899c6457207b18c4e2ebd14fc73f181ffd1
• fork branch URL: https://github.com/Dailin521/codex/tree/codex/cross-provider-session-discovery

It updates CLI, TUI, Desktop app lookup/picker paths, and adds a regression test for the empty-provider-filter behavior.

I have not opened a PR because docs/contributing.md says external PRs are invitation-only and uninvited PRs will be closed. If this direction aligns with the intended product behavior, I can open a PR immediately after a maintainer invitation.

Related

Related but distinct from:

• #15219

That issue is about resuming a thread on the wrong provider. This one is about local history/session discovery being hidden by the active-provider default.