Repository navigation
fix: explain invalid_encrypted_content errors after a provider change - #668
Merged
Merged
Conversation
Codex resends the encrypted reasoning of earlier turns with every request, and only the provider that encrypted it can read it. After the provider changes in a thread, the new provider rejects the history with invalid_encrypted_content, and the client showed the raw provider JSON. Recognize the error in the plain provider form, in the Codex service envelope, and in a gateway error that carries it in metadata, and show what caused it and how to continue instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Result
When a thread continues on another provider, the client now shows what went wrong instead of the raw provider JSON:
Before, Air showed the whole gateway error body:
{"error":{"message":"Provider returned error","code":400,"metadata":{"raw":"{\n \"error\": {...\"code\": \"invalid_encrypted_content\"....Cause
Codex sends requests with
store: falseand resends the encrypted reasoning of earlier turns with every request. Only the provider (and account) that encrypted it can read it. Afterproviders/setmoves a thread to another route, the new route rejects the history withinvalid_encrypted_content, and a retry fails the same way.This is Codex behavior, not an adapter bug:
codex exec resume <id> -c model_provider=<other>sends the other provider's encrypted reasoning too. Codex has no option to drop it, so the adapter only makes the error readable and does not rewrite the history.Changes
readableServiceErrorMessagerecognizesinvalid_encrypted_contentin three forms: the plain provider error{error: {code}}, the Codex service envelope{type: "error", status, error}, and a gateway error that carries it inmetadata.provider_error_codeor in the JSON ofmetadata.raw.Verification
ServiceErrorMessage.test.ts, and snapshot tests for ACP v1 (legacy text and typed failure) and ACP v2. All 7 fail without the change.npm run typecheckpasses.npm test: 1877 passed, 36 skipped.providers/setto gateway B, which returns the gateway error above; the client gets the readable message.