Repository navigation
old threads broken after update (invalid_encrypted_content / organization_id mismatch) #13724
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.305.950 (863)
What subscription do you have?
ChatGPT login
What platform is your computer?
Darwin 25.4.0 arm64 arm
What issue are you seeing?
Symptom
On sessions started before the Codex App update / transition to GPT-5.4, I get:
{
"error": {
"message": "The encrypted content gAAA... could not be verified. Reason: Encrypted content organization_id did not match the target organization.",
"type": "invalid_request_error",
"code": "invalid_encrypted_content"
}
}
Impacted threads (example)
- thread_id: 019cbe2c-5ea1-7313-a3fb-6bac7d57c0c0
Checks already done
- Complete logout/login: done
- Default organization checked: OK
- New sessions: working
- The issue only concerns old threads
Timestamps observed (Europe/Paris)
- 2026-03-06 09:08:20
- 2026-03-06 09:31:40
What steps can reproduce the bug?
Reproduction
- Open this old thread in Codex App
- Send a message
- Invalid_encrypted_content error above
Observed result
- The thread fails with organization_id mismatch.
What is the expected behavior?
Expected result
- The thread should reopen and accept new turns.
Additional information
The same thread was able to respond later via CLI (resume + ping), which suggests a Desktop migration/resumption issue rather than a global account problem.
Activity
github-actions commentedon Mar 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
pezzos commentedon Mar 6, 2026
It's not a duplicate, even if the issue seems to be the same.
The other ticket is relying on an API key, and I don't, I use the ChatGPT Pro subscription + the other issue occurs when running codex, I can use Codex, I just lost all the sessions existing before the Codex App or GPT5.4 update.
etraut-openai commentedon Mar 6, 2026
Were you using a different account when you created these threads originally? The encryption key is based on the account that you used to sign in.
pezzos commentedon Mar 6, 2026
No, I didn't change the account or even the organization or the subscription or something like that. That's why I think it's an issue. I keep working with the same account for months now, and the organization is the same default one for years now, and my account is working. I pay my subscription, so nothing changed on my side beside the update of the Codex App and GPT 5.4.
weeco commentedon Mar 9, 2026
I have the exact same problem on the Codex App. Connected via chatgpt subscription on enterprise with SSO enabled.
Codex Version 26.305.950 (863)
I just installed Codex, signed in with my account and that's it.
mwildehahn commentedon Mar 11, 2026
I've also been running into this the past couple of days. I'm running codex via device-auth in a sandbox and occasionally when i send a follow up message I'll run into this -- it's not consistent though but I've had it happen ~3 times today
darlingm commentedon Aug 17, 2026
I tested this today with Codex CLI v0.147.0 using two separate ChatGPT logins, concerned if I needed to use separate
CODEX_HOMEdirectories for two each login.I closed all Codex processes, changed the login in the same
CODEX_HOME, and resumed a thread created by the first account. The thread contained encrypted reasoning from before the switch and continued normally under the second account, with noinvalid_encrypted_contentor organization mismatch.I also tested two legacy threads created in February/March 2026 with Codex 0.98/0.107. They contained
gAAAA...compactions, 97–128 encrypted reasoning records, and 144–197 legacyfunction_callpairs. One was copied into the second account’s Codex home and indexed there. Both resumed and accepted new turns, including under the second account.I have not been able to reproduce account-bound rejection.
EDIT: Or does "a different account" not mean a different chatgpt.com account, but accounts with different providers like Amazon Bedrock, Azure, vs OpenAI? I haven't tested that, and don't need to be able to resume across providers.