Repository navigation
thread/resume does not restore model_provider from persisted metadata — breaks cross-provider conversation continuation #15219
Description
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
Activity
github-actions commentedon Mar 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ilmarioranen commentedon Mar 20, 2026
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.
Boulea7 commentedon Apr 22, 2026
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.
Restore persisted model provider on thread resume (#19287)
etraut-openai commentedon Apr 25, 2026
Thanks for the bug report. This will be addressed in the next release.
Update codex fork to upstream 0.128.0 (#14)
Restore persisted model provider on thread resume (openai#19287)
carry third-party provider auth for both agents into the sandbox
jossadev-prog commentedon Jun 19, 2026
I am also facing this problem
Restore persisted model provider on thread resume (openai#19287)