old threads broken after update (invalid_encrypted_content / organization_id mismatch)
Open 💬 8 comments Opened Mar 6, 2026 by pezzos
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
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
1) Open this old thread in Codex App
2) Send a message
3) 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.
8 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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.
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.
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.
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.
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
The old-thread-only
invalid_encrypted_contentfailure after the app/model transition is relevant because the conversation remained locally available and the same thread could later answer through CLI resume.Codex Rescue cannot decrypt, normalize, or repair organization-bound encrypted reasoning, and it does not fix the Desktop replay path. I’m trying to validate whether its current local diagnostic boundary reports the affected persisted history safely and can produce a bounded handoff without touching the source.
If you still have an affected old thread, could you try:
pipx install codex-rescue==0.1.0a3codex-rescue sessionscodex-rescue doctor --latestSanitized output only is sufficient—please don’t share raw rollouts, encrypted blobs, SQLite databases, account details, prompts, paths, tokens, or secrets.
https://github.com/shleder/codex-rescue
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.