Skip to content

Switching global provider hides previous sessions from the sidebar #17316

Open

Description

@bakaburg1

What feature would you like to see?

Switching the global provider should not make previous chat sessions disappear from the Codex app sidebar.

Current behavior

  • I create sessions with one provider.
  • I switch the global provider.
  • Older sessions no longer appear in the sidebar.

Expected behavior

Previous sessions should remain visible and accessible even after changing provider.

If sessions are being filtered by provider, the UI should make that explicit and let me view sessions from other providers.

Why this matters

Changing provider is a normal workflow when testing OpenAI, Azure, or local models. It should not hide session history.

Activity

  1. added
    enhancementNew feature or request
    appIssues related to the Codex desktop app
    custom-modelIssues related to custom model providers (including local models)
    on Apr 10, 2026
  2. Wangnov commented on May 22, 2026

    @Wangnov

    This sounds very close to the provider-bucket visibility problem that codex-threadripper was built for.

    Project: https://github.com/Wangnov/codex-threadripper

    It checks how Codex threads are distributed across model_provider values in state_5.sqlite and the rollout JSONL metadata, then can reconcile them so Codex Desktop / codex resume / app-server clients see the same local history after provider switches.

    Suggested safe flow:

    codex-threadripper status
    codex-threadripper sync

    It writes backups before mutating local state. Still, please back up ~/.codex first, especially if your sessions contain important work.

    Important caveat: this is an unofficial workaround for local history visibility. It does not migrate encrypted conversation ownership across accounts/providers, and it should not replace an official Codex fix for provider-aware history listing/resume behavior.

  3. steveepreston commented on Jun 6, 2026

    @steveepreston

    @Wangnov Thanks!

    1. has it any GUI?
    2. If we change bucket of a chat, can it be continued with new model? or it's just for read?
  4. Wangnov commented on Jun 6, 2026

    @Wangnov

    @steveepreston
    no gui and not planned, sry.
    Yeah it can be continued, but you need to confirm that two bucket are encrypted by the same way.
    Such as openai (ChatGPT Oauth) and other provider by ChatGPT Oauth just name different.
    ChatGPT Oauth and Vertex/AWS/... are encrypted by different way. So will failed.

  5. steveepreston commented on Jun 6, 2026

    @steveepreston

    @Wangnov thanks for explain.

    can Move openai chats into 9router bucket?

  6. Wangnov commented on Jun 6, 2026

    @Wangnov

    Of course you can.

    model_provider = "9router"
    
    [model_provider.9router]
    blabla
    
    

    If your "9router" is like this, it will work.

  7. steveepreston commented on Jun 6, 2026

    @steveepreston

    @Wangnov Thanks!

  8. Necmttn commented on Jun 21, 2026

    @Necmttn

    Provider changes should not mutate session visibility without an explicit filter.

    Keep model_provider as metadata on the session row, then let the sidebar default to all providers with provider badges. If a session cannot be resumed under the active provider, show a compatibility warning and the original provider/root rather than hiding it.


    Generated with ax.

  9. steveepreston commented on Jun 21, 2026

    @steveepreston

    @Necmttn Agree

  10. bakaburg1 commented on Jun 22, 2026

    @bakaburg1
    Author

    Optionally, there could be a setting forbidding codex sessions to be able to see other sessions, in case one has data security issues, but I would not make it the default

  11. bakaburg1 commented on Jun 22, 2026

    @bakaburg1
    Author

    Provider changes should not mutate session visibility without an explicit filter.

    Keep model_provider as metadata on the session row, then let the sidebar default to all providers with provider badges. If a session cannot be resumed under the active provider, show a compatibility warning and the original provider/root rather than hiding it.

    Generated with ax.

    and in OpenCode you can change provider even midway in the session

  12. Lin-Guanguo commented on Aug 13, 2026

    @Lin-Guanguo

    I can confirm that this is particularly painful in a Codex Desktop + SSH Remote + worktree workflow.

    Codex Desktop is an excellent agent, and its SSH Remote and managed-worktree experience is a major reason I use it. However, switching providers currently feels risky because task visibility appears coupled to the provider identity.

    My setup is:

    • Codex Desktop on macOS
    • the same ChatGPT account/authentication
    • the same repositories, including projects opened through SSH Remote
    • provider profiles that mainly differ in routing/base URL and model catalog

    What I observed:

    • After changing the top-level model_provider, tasks created under the previous provider can disappear from the sidebar, even though the underlying session data still exists.
    • This makes a provider change feel like switching to a different task-history namespace.
    • The impact is greater for long-lived remote/worktree tasks than for one-off CLI sessions, because the sidebar is the primary way to return to those tasks.
    • My practical workaround is to keep the provider ID stable and manually change the base URL/auth/model-catalog configuration. That preserves task visibility, but it prevents first-class provider switching and makes configuration management more fragile.

    What I would expect:

    • The sidebar should show tasks from all providers by default.
    • The original provider should be retained and displayed as task metadata, ideally with a provider badge/filter.
    • Resuming should use the original provider when it is available.
    • If that provider or its credentials are unavailable, Codex should keep the task visible and show an actionable compatibility/authentication warning instead of hiding it.
    • Routing configuration and provider selection should not determine whether a persisted task is discoverable.

    This would make it much safer to experiment with compatible gateways or different model providers without giving up one of the strongest parts of Codex Desktop: durable tasks across local, SSH Remote, and worktree environments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appcustom-modelIssues related to custom model providers (including local models)enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions