Codex desktop: switching an existing thread to a custom API provider can break continuity and remote compact still hits api.openai.com

Summary

When using the Codex desktop app, switching authentication/model routing from ChatGPT-plan auth to a custom third-party Responses-compatible API provider is currently very fragile for long-running threads.

The existing thread can remain visible, but when the thread needs compaction or certain follow-up work, Codex may still send the request to https://api.openai.com/v1/responses instead of the configured custom provider base_url. Because the active key belongs to the third-party provider, the request fails with 401 invalid_api_key.

This creates a serious continuity/UX problem: users can have a long-running task half completed on disk, switch to a third-party provider because their ChatGPT/Codex plan quota is exhausted, and then discover that the same thread cannot continue reliably. The practical workaround becomes opening a new thread, manually recovering Git/worktree state, creating handoff files, and later re-synchronizing the old thread when ChatGPT quota returns. That is error-prone and can cause duplicate work or conflicting edits.

Expected behavior

One of these behaviors would be much safer:

1. Provider routing should be thread-consistent: once a custom provider is active, all model-dependent subrequests for that thread (including remote/local compaction) should honor the configured provider/base URL; or
2. If an existing thread cannot safely switch providers, Codex should explicitly block the switch and offer a first-class Continue with another provider flow that carries forward the thread summary, working directory, branch/worktree, diff state, approvals, and pending tasks; or
3. Codex should automatically generate a durable handoff/checkpoint before switching auth/provider, then let the new provider resume from that checkpoint without requiring users to manually inspect Git/worktrees.

Reproduction

1. Start a long-running Codex/Work task using ChatGPT-plan auth.
2. Let the task modify a local repository/worktree and continue until the thread is long enough to require compaction.
3. Exhaust or otherwise stop using ChatGPT/Codex plan quota.
4. Configure a custom third-party Responses-compatible provider with its own API key and base_url.
5. Return to the existing thread and attempt to continue.
6. The thread may remain visible, but compaction/follow-up can fail with a request to https://api.openai.com/v1/responses and 401 invalid_api_key, instead of using the custom provider endpoint.

Why this matters

• Long-running tasks can be stranded halfway through even though the repository state is still present locally.
• Users are forced to manually manage config.toml, auth, Git branches/worktrees, local history, and handoff files just to change billing/provider.
• Returning later to ChatGPT-plan auth risks stale-thread context causing repeated work or edits that conflict with changes made by the third-party-provider thread.
• A third-party API key being routed to the wrong host is also an undesirable credential-routing failure mode, even if the request is rejected.

Requested product behavior

Please make provider switching a first-class, resumable operation at the thread/task level, with automatic preservation of:

• thread/task summary and pending checklist
• current working directory
• branch/worktree identity
• uncommitted diff state
• approvals/permissions state
• model/provider routing for all subrequests, including compaction

The user should not need to understand Git worktrees or manually create a handoff document simply because they switched from ChatGPT-plan usage to a custom API provider and later back again.

Start with the provider and thread-continuation paths described in the reproduction, then inspect config.toml and the authentication/provider handling around compaction requests. Reproduce the existing-thread switch and trace why the request reaches api.openai.com instead of the configured base_url. Done means provider routing is consistent for subrequests or the switch offers a durable, resumable handoff.