Skip to content

fix: explain invalid_encrypted_content errors after a provider change - #668

Merged
EugeneTheDev merged 1 commit into
mainfrom
fix/readable-invalid-encrypted-content
Oct 23, 2026
Merged

EugeneTheDev merged 1 commit into
mainfrom
fix/readable-invalid-encrypted-content

Conversation

@EugeneTheDev

@EugeneTheDev EugeneTheDev commented Oct 23, 2026 •

Copy link
Copy Markdown
Collaborator

Result

When a thread continues on another provider, the client now shows what went wrong instead of the raw provider JSON:

The current provider can't read this thread's earlier reasoning, which another provider or account encrypted. This happens after the provider changes in a thread. Switch back to the previous provider or start a new thread.

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: false and resends the encrypted reasoning of earlier turns with every request. Only the provider (and account) that encrypted it can read it. After providers/set moves a thread to another route, the new route rejects the history with invalid_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

  • readableServiceErrorMessage recognizes invalid_encrypted_content in three forms: the plain provider error {error: {code}}, the Codex service envelope {type: "error", status, error}, and a gateway error that carries it in metadata.provider_error_code or in the JSON of metadata.raw.
  • Other error text stays unchanged.
  • The function is already used for every path a provider error reaches the client, so ACP v1 (agent message and Air typed failure) and ACP v2 (agent message and idle error) all get the message.

Verification

  • New unit tests in 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 typecheck passes. npm test: 1877 passed, 36 skipped.
  • End to end with real Codex and two local OpenAI-compatible gateways on ACP v1 and v2: two prompts on gateway A, providers/set to gateway B, which returns the gateway error above; the client gets the readable message.

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.
@EugeneTheDev
EugeneTheDev merged commit a77829f into main Oct 23, 2026
7 checks passed
@EugeneTheDev
EugeneTheDev deleted the fix/readable-invalid-encrypted-content branch October 23, 2026 13:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant