Repository navigation
The encrypted content ... could not be verified and Stream disconnects before completion #11653
Description
Issue 1: Azure encrypted content verification fails
Summary
Requests sometimes fail with invalid_encrypted_content and message The encrypted content ... could not be verified.
Error
{
"error": {
"message": "The encrypted content gAAA...5IEt could not be verified.",
"type": "invalid_request_error",
"param": null,
"code": "invalid_encrypted_content"
}
}
Impact
Chat fails for affected requests.
Steps to Reproduce
- Start a chat request.
- Observe intermittent failure with
invalid_encrypted_content.
Expected
Encrypted content is accepted and chat completes. Or at a minimum, Codex automatically continues from where it was with all of the previous turn context present.
Actual
Request fails with invalid_encrypted_content.
Issue 2: Stream disconnects before completion
Summary
Streaming responses are cut off with: stream disconnected before completion: stream closed before response.completed.
Error
stream disconnected before completion: stream closed before response.completed
Impact
Streaming chat responses fail or truncate.
Steps to Reproduce
- Start a streaming chat request.
- Observe stream terminates early with the error above.
Expected
Stream completes and returns response.completed. Or at a minimum, Codex automatically continues from where it was with all of the previous turn context present.
Actual
Stream disconnects early.
Activity
[-]The encrypted content ... could not be verified.[/-][+]The encrypted content ... could not be verified and Stream disconnects before completion[/+]etraut-openai commentedon Feb 13, 2026
Thanks for the bug report. I recommend reporting this to the Azure team as well.
Falven commentedon Feb 13, 2026
@etraut-openai I will. They will likely say there will always be transient network issues. One of these is obviously more than a transient network issue, but my primary intention for opening this report here is in the hopes that we can have some more robust retry logic around these kinds of errors from the Codex CLI where it can retry when receiving these errors while maintaining any turn context it's already undertaken (thoughts, tool calls and tool call results, etc.). Because it's pretty frustrating when it's in a 10 minute turn only to receieve one of these errors, stop and forget all of the exploration it did. Strangely enough, I have also potentially noticed that the longer the conversation gets with these encrypted content verification errors with me just replying "Continue.", the more often the error will happen.
etraut-openai commentedon Feb 13, 2026
The codex app does have extensive retry logic. This error is categorized as a nonrecoverable error, so we don't even attempt to retry it. If it occurs once, it's going to keep occurring. It's definitely not a network issue.
smileBeda commentedon Feb 26, 2026
@Falven did your error occur on a
resume'd chat?Because that is the case for me, and only when using API key - not when using logged in auth.
Falven commentedon Mar 5, 2026
Resumed chats cause it, also being behind an AI Gateway causes it - I realized I needed to use sticky sessions to ensure the SSE stream goes to the same endpoint behind the gateway and doesn't violate the encryption. But it also happened transiently when going directly to an Azure Foundry project or services endpoint. The last one hasn't happened in a couple of weeks because something worse has been happening through the Codex CLI - the LLM responds, saying it's going to do something then just stops. Looking at the response it has a max token reached reason. Not sure why we removed the ability to define the max output tokens for a model configuration, seems potentially like Codex doesn't understand what the max output tokens are for models hosted in Azure Foundry and there's currently no way to explicitly tell it.