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.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #12934

Powered by Codex Action

pezzos · 5 months ago

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 contributor · 5 months ago

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 · 5 months ago

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 · 5 months ago

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 · 5 months ago

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

shleder · 14 days ago

The old-thread-only invalid_encrypted_content failure 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.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized 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

darlingm contributor · 11 days ago
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.

I tested this today with Codex CLI v0.147.0 using two separate ChatGPT logins, concerned if I needed to use separate CODEX_HOME directories 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 no invalid_encrypted_content or 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 legacy function_call pairs. 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.