thread/resume does not restore model_provider from persisted metadata — breaks cross-provider conversation continuation
What version of the Codex App are you using?
26.317.21539 (1088) — bundled codex-cli 0.116.0-alpha.1
What subscription do you have?
ChatGPT Plus + Azure OpenAI (custom model_providers.azure in config.toml)
What platform is your computer?
Darwin 24.5.0 arm64
What issue are you seeing?
Resuming any past conversation from ChatGPT Plus while the current profile is set to Azure (or vice versa) produces:
{ "error": { "message": "The encrypted content gAAA...Sq-D could not be verified.
Reason: Encrypted content could not be decrypted or parsed.",
"type": "invalid_request_error", "param": null, "code": "invalid_encrypted_content" } }
Root cause: merge_persisted_resume_metadata() in codex_message_processor.rs restores model and reasoning_effort from ThreadMetadata but does not restore model_provider. So the conversation history (containing encrypted_content from the original provider) is sent to the _wrong_ API endpoint, which cannot decrypt it.
The ThreadMetadata struct already stores model_provider (populated from threads.model_provider in state_5.sqlite), and ConfigOverrides.model_provider exists. It just is not wired up during resume.
Proposed fix
In codex-rs/app-server/src/codex_message_processor.rs, merge_persisted_resume_metadata:
fn merge_persisted_resume_metadata(
request_overrides: &mut Option<HashMap<String, serde_json::Value>>,
typesafe_overrides: &mut ConfigOverrides,
persisted_metadata: &ThreadMetadata,
) {
if has_model_resume_override(request_overrides.as_ref(), typesafe_overrides) {
return;
}
typesafe_overrides.model = persisted_metadata.model.clone();
+ typesafe_overrides.model_provider = Some(persisted_metadata.model_provider.clone());
if let Some(reasoning_effort) = persisted_metadata.reasoning_effort {
request_overrides.get_or_insert_with(HashMap::new).insert(
"model_reasoning_effort".to_string(),
serde_json::Value::String(reasoning_effort.to_string()),
);
}
}
This ensures the thread is resumed on the same provider that created it, regardless of the user's current active profile.
What steps can reproduce the bug?
- Configure both
profiles.plus(model_provider = "openai") andprofiles.azure(model_provider = "azure") in~/.codex/config.toml - Create conversations using Plus profile
- Switch to Azure profile:
profile = "azure"in config.toml - Open the Codex App and click on any previous Plus conversation → encrypted_content error
What is the expected behavior?
Resuming a conversation should automatically route to the original provider that created it. The model_provider is already persisted in threads.model_provider — it just needs to be applied during resume.
Additional information
Related: #11653 (encrypted content verification failures)
Related: #12998 (model picker empty for custom providers)
state_5.sqlite correctly stores the provider per thread — verified:
SELECT model_provider, count(*) FROM threads GROUP BY model_provider;
-- openai|922
-- azure|106
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I think the tagged issues are related but this isnt IMHO a duplicate issue. This current issue provides a KISS-one liner which the others issues dont seem to include.
Im currently however using a shell script to flip between ChatGPT plus and Azure OpenAI API endpoints for Codex which fixes the session/thread data in a way that allows me to continue existing sessions relatively smoothly with Azure/ChatGPT sub.
Adding another user report here: I’m also running into this regularly.
A common real-world reason is quota / access differences. The Codex usage included with ChatGPT Pro is not always enough for heavier workflows, so I often switch between my Pro login and an external GPT API provider / gateway. In practice that also means switching
model_provider. When that happens, session history and resume continuity become fragmented across providers, even though from a user perspective it still feels like the same ongoing work.I have explored the obvious workarounds on my side, but neither seems like a good solution:
openaiprovider used by the official subscriptionopenaiprovider id so it matches the external provider / gatewayBoth approaches have practical downsides: some features may no longer work correctly, websocket behavior can break, and provider / gateway-specific issues can appear.
So I would really appreciate an official fix here rather than a workaround. Even if fully cross-provider continuation needs guardrails because of encrypted / reasoning content, the current
model_providerimpact on session discovery / resume is too limiting for users who legitimately need to alternate between the built-in subscription and external API providers.Please keep this issue updated if there is progress, and ideally call out the fix in release notes or issue updates when it lands.
Thanks for the bug report. This will be addressed in the next release.
I am also facing this problem