Azure Responses providers cannot opt out of 30-day response storage with store=false

What version of the Codex App are you using (From “About Codex” dialog)?

v0.146.1

What subscription do you have?

Azure

What platform is your computer?

_No response_

What issue are you seeing?

Codex forces store=true for providers detected as Azure Responses endpoints.

As a result, conversations sent through an Azure OpenAI endpoint are stored by the provider under its response-retention policy. Azure Responses supports stateless operation with store=false, including multi-turn reasoning through reasoning.encrypted_content, but Codex does not expose a provider-level setting to select this mode.

The current request construction sets:

store: provider.is_azure_responses_endpoint(),

Source: https://github.com/openai/codex/blob/e1831db7c31ec3ec3a88f29e95cc336858038bad/codex-rs/core/src/client.rs#L918-L927

This makes persistence depend on provider detection rather than an explicit provider capability or user privacy preference.

This issue is related to #35739, but requests the complementary supported behavior: an Azure endpoint should be able to use store=false safely. The solution should not require renaming the provider, hiding that it is Azure, or modifying requests in a proxy.

What steps can reproduce the bug?

1. Configure Codex App with a custom Azure OpenAI Responses provider.

model = "<deployment-name>"
model_provider = "my_azure"

[model_providers.my_azure]
name = "azure"
base_url = "https://<resource>.openai.azure.com/openai/v1"
wire_api = "responses"

1. Fully restart Codex App.
2. Start a new task and send any prompt.
3. Inspect the request at an authorized local proxy or other redacted request-logging boundary.
4. Inspecting the outbound request shows store:true. Independently, the current source constructs store from provider.is_azure_responses_endpoint().

{
  "store": true
}

1. Search Codex configuration options and observe that there is no provider-scoped setting to request store=false.

The behavior occurs before any particular prompt or tool call; it is determined during request construction. A multi-turn tool request can additionally verify that encrypted reasoning and tool-call history continue correctly in stateless mode.

What is the expected behavior?

Codex should allow an Azure Responses provider to explicitly select stateless operation, for example:

[model_providers.my_azure]
responses_store = false

When responses_store = false, Codex should:

• send store=false;
• request and replay reasoning.encrypted_content;
• retain stable item IDs internally;
• omit outbound item IDs when required for stateless compatibility;
• preserve call_id for function-call/result association;
• avoid persistence-dependent behavior such as stored-response retrieval;
• preserve ordinary messages, tool calls, tool results, ordering, and compaction items.

The existing Azure behavior can remain the compatibility default when the option is unspecified.

Additional information

Azure documents stateless Responses usage with store=false and encrypted reasoning items: https://learn.microsoft.com/azure/foundry/openai/how-to/responses#encrypted-reasoning-items

Suggested provider capability:

[model_providers.my_azure]
responses_store = false
serialize_item_ids = false

These controls may need to remain separate:

• responses_store controls provider-side persistence.
• serialize_item_ids controls outbound request serialization.
• Codex can still retain stable IDs internally.

Related issue: #35739 reported that custom/proxied Azure providers could not select a compatible request shape after item IDs became always enabled. That issue discusses store=true as a workaround. This report asks for the inverse, privacy-sensitive configuration explicitly supported by Azure: store=false with safe stateless history replay.