[Desktop Client Bug] Chat session model ID remains locked after switching providers, breaking context continuation in existing threads

What version of the Codex App are you using (From “About Codex” dialog)?

26.908.70816

What subscription do you have?

use costom provider

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Description:
When an API request fails or errors out using Model X (Provider A), switching the global configuration to Model Y (Provider B) fails to update the underlying model payload for existing chat sessions. When the user sends a new message in the original chat window to continue their vital historical context, the client incorrectly sends the old "Model X" ID to Provider B's endpoint, causing a "Model Not Found" error.

Users cannot simply "start a new chat" as the existing context and message history within the current thread are critical and must be preserved/continued.
Steps to Reproduce:

1. Send a message in a chat thread using Provider A with Model X, which results in a failure or error response.
2. Switch the active model/provider settings to Provider B with Model Y (where Model X does not exist).
3. Remain in the original chat thread to preserve the important historical context.
4. Type and send a new message in this same window.
5. Result: The client routes the request to Provider B's API endpoint, but stubbornly injects the old model: "X" parameter from the session's initial binding, causing the API to reject the request with a "Model Not Found" error.

Expected Behavior:
When sending a new message in an existing chat thread after a provider/model switch, the desktop client should dynamically update the session's target model parameter to match the newly selected active model (Model Y), allowing users to seamlessly continue their important conversation context without being blocked by a hardcoded old model ID.

What steps can reproduce the bug?

Feedback ID: 01a0a32f-e87f-7ce2-96cf-614badc95c5d

What is the expected behavior?

When sending a new message in an existing chat thread after a provider/model switch, the desktop client should dynamically update the session's target model parameter to match the newly selected active model (Model Y), allowing users to seamlessly continue their important conversation context without being blocked by a hardcoded old model ID.

Additional information

No response

Reproduce the provider and model switch in an existing chat thread, then trace how the session model payload is created and reused when the next message is sent. Verify that the request uses the newly selected Model Y while retaining the original conversation history and no longer sends the stale Model X ID.