Allow explicit Responses storage opt-in for custom providers (agentic-api use case)

What variant of Codex are you using?

CLI: codex-cli 0.155.0-alpha.2.6, Windows x64. The request concerns the shared Responses client used by custom providers.

What feature would you like to see?

Allow a custom Responses provider to explicitly opt into store: true, while keeping the current store: false default.

Concrete use case: agentic-api

vllm-project/agentic-api exposes an OpenAI-compatible Responses API for self-hosted inference and supports durable response storage. I would like to select that storage behavior when using it as a Codex custom provider, without patching Codex or rewriting its requests in a proxy.

Codex currently hardcodes store: false in the shared Responses request builder. Its provider configuration has no supported storage override.

This is a missing opt-in, not a claim that store: false is invalid or that agentic-api cannot run Codex. Agentic-api documents temporary, connection-local WebSocket continuation with store: false; after reconnecting, an unstored response ID cannot be recovered from durable storage, so the client must replay history or a compacted window. With store: true, uncached responses can be loaded from durable storage. See its storage/continuation documentation.

The immediate benefit is allowing the user's chosen backend to retain response checkpoints for later retrieval and supported continuation workflows. Merely changing store would not automatically make Codex resume across connections using stored IDs, reduce token usage, or change prompt caching; those are separate behaviors.

Proposed approach

Add a typed provider-scoped option, for example:

model_provider = "agentic_api"

[model_providers.agentic_api]
name = "Agentic API"
base_url = "http://localhost:8000/v1"
wire_api = "responses"
responses_store = true # Proposed option; not currently supported

• Omitted or false: preserve current stateless behavior.
• true: serialize store: true consistently on supported HTTP and WebSocket Responses requests.
• Keep the setting independent of provider display names, Azure hostname detection, item-ID serialization, and local Codex history retention.
• Document that this explicitly authorizes backend response persistence and that retention is controlled by that backend.
• Preserve current history replay and encrypted-reasoning behavior unless a separately validated continuation mode requires changes. Avoid silently depending on durable storage just because storage is enabled.

This could initially be limited to custom providers. Unsupported endpoints should report a clear error rather than silently changing the requested persistence behavior.

An alternative is a validated per-provider request-body override, as requested in #5458. A typed storage option seems easier to document and test because it has defined privacy and protocol semantics.

Suggested validation: capture requests for default/false/true settings over HTTP and WebSocket; verify multi-turn messages and tool results remain correct; retain reconnect/full-history fallback; ensure enabling storage does not unexpectedly switch to ID-only replay.

Additional information

Observed behavior and reproduction

Using an isolated CODEX_HOME, configure a custom provider pointing to a local HTTP mock:

model = "store-probe-model"
model_provider = "store_probe"
web_search = "disabled"

[model_providers.store_probe]
name = "Local store verification"
base_url = "http://127.0.0.1:PORT/v1"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = false
request_max_retries = 0
stream_max_retries = 0

Replace PORT with the mock listener's port, then run:

codex exec --ephemeral --skip-git-repo-check --sandbox read-only "Say OK."

The installed binary sent POST /v1/responses with these captured fields:

{
  "model": "store-probe-model",
  "store": false,
  "stream": true
}

The mock deliberately returned HTTP 400 after capture; no model inference was performed. This verifies the outbound field, not an end-to-end agentic-api failure. Agentic-api semantics above were checked in its documentation/source at commit a38b0f0cbafb02b969da1c2724308bf23d375a8d; Codex source was inspected at 7498521d288b9b3b96ffba4eedf089d8d6e06a84.

Related issues and design history

Existing reports were searched before filing:

• #35739 (closed): Azure/proxy item-ID regression; explicitly proposed responses_store = true as one possible fix. This request overlaps with that proposal but asks for durable-storage opt-in independently of the Azure regression.
• #37275 (open): inverse request, allowing Azure users to select store: false.
• #34404 (open): discussion of the historical Azure-only store: true behavior.
• #5458 (open): broader provider-specific request-body configuration.
• #3212 (merged): intentionally removed disable_response_storage, citing lookup latency and code simplification.

This request acknowledges that earlier tradeoff and preserves the current default. It asks whether an explicit custom-provider opt-in can support self-hosted backends such as agentic-api without restoring storage-dependent behavior for everyone.

Start with the shared Responses request builder in codex-rs/core/src/client.rs and the provider configuration in codex-rs/model-provider-info/src/lib.rs. Trace how provider settings reach HTTP and WebSocket Responses requests, then review the existing history replay and retry paths. Done means an explicit custom-provider storage setting preserves the false default, sends the requested value consistently, and keeps replay and tool-result behavior unchanged.