Feature request: provider-neutral sessions with hot provider switching and cold resume without forking

Summary

Codex should treat the conversation/session as a durable user asset and the model provider as a runtime route.

Today, provider selection is coupled too tightly to an active or persisted session. This creates two separate UX problems:

1. Cold switch / resume problem: after changing provider/profile and restarting Codex, users should be able to resume the exact same session under the new provider without copying or forking it.
2. Hot switch problem: while staying in the same session, users should be able to switch provider/model from a picker and have the new route take effect on the next turn, without restarting Codex and without creating a new session.

These should be designed as one coherent capability, not as unrelated fixes.

Related discussions:

• #38365 — cross-provider session handoff / normalization
• #35728 — unified session visibility across providers

Product principle

Session state and execution backend should be decoupled.

A session should own:

• session/thread ID
• conversation history
• workspace/worktree state
• attachments/artifacts
• tool history / tool results
• user-visible task state

The runtime route should own:

• provider/profile
• model
• endpoint/base URL
• auth/credential reference
• protocol
• capability snapshot

Changing the runtime route should not require changing the session identity.

Required UX

A. Cold switch: restart and resume the same session

Supported flow:

1. Session is running on Provider A.
2. User exits Codex.
3. User changes provider/profile/model.
4. User restarts Codex.
5. User resumes the same existing session.
6. The session continues under Provider B.

Expected behavior:

• same session/thread ID
• same transcript
• same workspace/worktree
• same attachments and task state
• no copy
• no fork
• no duplicate session
• provider client is rebuilt from the new runtime configuration

This is useful when switching network environments, credentials, enterprise gateways, VPNs, or provider stacks where a clean process restart is desirable.

B. Hot switch: change provider inside the same live session

Supported flow:

1. Session is idle after completing a turn on Provider A.
2. User opens a Provider / Model picker.
3. User selects Provider B and a compatible model.
4. Codex validates the new route.
5. The next turn runs on Provider B.
6. The session ID and history remain unchanged.

Suggested UI:

Provider: [ OpenAI ▼ ] Model: [ GPT-5.6 ▼ ]

Possible scope choices:

• next turn only
• current session from now on
• set as default for new sessions

A provider switch should happen between turns, not in the middle of an actively streaming turn.

Recommended runtime behavior

Provider switching should be an atomic route-change transaction:

1. Validate credentials/auth reference.
2. Validate endpoint reachability and model availability.
3. Validate protocol compatibility.
4. Validate context length.
5. Validate tool/image/reasoning support required by the current history.
6. Build the new provider client.
7. Only after successful construction, atomically update the session's active route.
8. The next turn uses the new route.

If any step fails:

• keep Provider A active
• do not mutate the session route
• preserve the user's draft/input
• show the exact failure reason
• allow immediate retry or rollback

The UI must never show Provider B while the runtime client is still Provider A.

Provider-neutral transcript

Cross-provider history should not depend on one provider's wire format.

Codex should maintain a canonical internal conversation representation and adapt it per provider at send time.

The canonical transcript should preserve:

• user and assistant messages
• completed tool calls and outputs
• attachments/artifacts
• necessary structured state

Provider-specific protocol items should be normalized or translated before sending to a different backend.

If a historical record cannot be translated safely, Codex should:

• keep the original session unchanged
• explain the incompatibility precisely
• offer a safe fallback such as history compaction / textual handoff

Fork should remain an explicit semantic branching operation, not a workaround for changing provider, credentials, quota source, or gateway.

Per-turn route metadata

Each turn should record the actual execution route independently of the session identity, for example:

• provider/profile ID
• model ID
• endpoint alias
• protocol
• credential fingerprint/reference
• start/end time
• result/status

Do not store plaintext secrets in the session.

This makes it possible for one session to legitimately contain:

• turns 1–10: OpenAI
• turns 11–15: enterprise LiteLLM gateway
• turns 16–20: another compatible provider

while remaining one continuous task.

Enterprise / data-boundary requirements

Provider switching can cross trust boundaries, so Codex should make the destination explicit.

Before switching from an enterprise/internal provider to an external provider, the UI should be able to show or enforce:

• target provider/profile
• endpoint alias
• whether conversation history will be sent
• whether attachments will be sent
• whether tool outputs / workspace-derived content will be sent
• whether organization policy allows the transfer

Enterprise policy should be able to block prohibited cross-boundary switching.

Secrets must never be written into:

• thread/session history
• logs
• telemetry
• feedback bundles

Acceptance criteria

1. Provider A → Provider B cold resume keeps the same session/thread ID.
2. Provider A → Provider B hot switch keeps the same session/thread ID.
3. B → A works as well.
4. No automatic copy, duplicate task, or fork is created.
5. Restarting Codex re-resolves the current provider profile and credentials instead of reusing a stale client.
6. Hot switching takes effect on the next turn only.
7. A provider switch cannot partially commit.
8. Invalid credentials, unavailable models, protocol errors, context overflow, or unsupported capabilities leave the previous provider usable.
9. Session history remains visible regardless of currently selected provider.
10. The UI clearly shows the provider/model that will handle the next turn.
11. Actual provider/model used is recorded per turn.
12. Fork remains available, but only as an explicit branch operation.
13. Plaintext API keys are never persisted in session state.
14. Cross-boundary provider switches can be warned about or blocked by enterprise policy.
15. Prompt-cache loss may be communicated as a performance/cost effect, but must not be treated as loss of conversation history.

Why this matters

Users increasingly switch among:

• OpenAI account-backed models
• enterprise gateways
• LiteLLM-compatible endpoints
• Azure/Bedrock-style providers
• local or self-hosted inference
• third-party compatible providers

They should not have to fragment one task into multiple copies just because the execution backend changed.

A clean model is:

stable session state + mutable runtime route

This would support both reliable restart-and-resume workflows and seamless in-session provider switching while keeping Fork reserved for actual branching.

Start by mapping the session persistence, provider configuration, route construction, and per-turn execution paths in Codex; no specific files or tests are named. Review related issues #38365 and #35728 before choosing an implementation boundary. Done means the listed cold-resume, hot-switch, validation, rollback, history, metadata, and policy acceptance criteria are covered without forking or exposing secrets.