Codex disable_response_storage: A Removed ZDR Setting
As of 2026-10-08, disable_response_storage is an old Codex CLI setting that has been removed: PR #714 in the Codex open-source repository added it to config.toml on 2025-04-28 for OpenAI organizations with Zero Data Retention (ZDR), and PR #3212, merged on 2025-09-05, states "The disable_response_storage configuration option is removed." The change shipped in rust-v0.30.0, and a search of the current config-reference finds no such key. This page covers what it did, why it was dropped, and what happens if an old config still has it.
Updated 2026-10-08
Four key points
Added to config.toml (PR #714)
The PR says passing the command-line flag every time was tedious for ZDR customers, so it let them set the value once in config.toml and be done with it.
Removed (PR #3212)
The Breaking change section of the PR "Never store requests" states that the option is removed; rust-v0.30.0, released the same day, lists the PR among its merged changes.
How requests go out after removal
PR #3212 fixed store to false in Responses requests; in rust-v0.161.0, released 2026-10-07, the request builder still sets store: false.
If an old config still has it
When rust-v0.161.0 loads config.toml, it lists keys it does not recognize in a startup warning and marks each one "is ignored"; launched with --strict-config, it stops with an error instead.
What it was and why it existed
As of 2026-10-08, disable_response_storage is a removed boolean setting in Codex CLI, and a search of the current config-reference finds no such key. It grew out of Zero Data Retention (ZDR): PR #642, merged on 2025-04-25, first gave the Rust CLI a --disable-response-storage flag, and its description explains that for a client using ZDR, previous_response_id is never available, so the input of every request must carry the full conversation transcript so far. Three days later PR #714 made it settable in config.toml; the source comment reads "Disable server-side response storage (sends the full conversation context with every request)" and notes that this was then necessary for OpenAI customers who had opted into ZDR. Left unset, it was false.
How PR #3212 worded the removal (2025-09-05)
PR #3212 is titled "Never store requests", and its Breaking change section holds a single sentence: "The disable_response_storage configuration option is removed." The stated reason: when item IDs are sent to the Responses API, it loads them from the database and ignores the provided values, and "This adds extra latency"; dropping the mode that stores requests also simplifies the code. The same PR deleted the disable_response_storage section from the repository's docs/config.md and cut the body of docs/zdr.md down to one line: "Codex CLI natively supports OpenAI organizations with Zero Data Retention (ZDR) enabled." It shipped in rust-v0.30.0, released the same day, whose notes list it as "Never store requests".
Timeline
PR #714 is merged, so disable_response_storage = true can go in config.toml; PR #642, merged on 2025-04-25, had already added the --disable-response-storage command-line flag.
PR #3212, "Never store requests", is merged: the option is removed and requests switch to store: false. rust-v0.30.0 ships the same day with it included.
Checked on this date: a search of the current config-reference finds no such key, and the rust-v0.161.0 source (released 2026-10-07) treats it as an unrecognized setting and lists it in a startup warning.
Confirmed vs not verified
Confirmed (verbatim in the Codex open-source repository and OpenAI's official docs)
The following can be checked word for word in the Codex open-source repository or OpenAI's official Codex docs: PR #642 (merged 2025-04-25) added the --disable-response-storage flag to support ZDR customers; PR #714 (merged 2025-04-28) made the key settable in config.toml; PR #3212 (merged 2025-09-05) states "The disable_response_storage configuration option is removed." and changed store in requests to false; the rust-v0.30.0 release notes list PR #3212; as of 2026-10-08, a search of the current config-reference finds no such key; the rust-v0.161.0 config structure has no such field, and unrecognized keys trigger a warning that begins "Codex is ignoring"; the official CLI docs state that --strict-config errors when config.toml contains fields that version of Codex does not recognize. One more thing: docs/config.md under the rust-v0.40.0 tag (released 2025-09-23, after PR #3212) still lists the key in its table with the note "Required for ZDR orgs." Go by the current docs.
Unverified or not stated by the vendor
The following have not been verified, so do not draw conclusions from them: first, whether the versions between rust-v0.30.0 and rust-v0.161.0 silently ignored this key or warned about it; this page checked only the rust-v0.161.0 source, not each release. Second, a search of OpenAI's current Codex docs found no section dedicated to Codex CLI and ZDR; the "natively supports" line comes from the repository doc rewritten by PR #3212 on 2025-09-05. Third, a user on GitHub has proposed an explicit response-storage opt-in for custom providers; as of the check date that proposal is still open and is not a current setting. Fourth, whether your organization has ZDR enabled and how its data is retained is governed by your OpenAI account settings and agreement; this page makes no judgment on it.
Before and after the removal
Before (prior to rust-v0.30.0)
Unset meant false. Setting it to true turned off server-side response storage and sent the full conversation context with every request. The docs/config.md of the time said accounts with ZDR had to set it to true, and docs/zdr.md listed the matching error, which ended in "Previous response cannot be used for this organization due to Zero Data Retention." In the source of the time, requests made while signed in with ChatGPT were not stored anyway.
After (from rust-v0.30.0)
The key went away together with the mode that stores requests: PR #3212 fixed store to false in requests, and its description says dropping that mode simplifies the code. In rust-v0.161.0, released 2026-10-07, the Responses request builder still sets store: false. PR #3212 rewrote the repository doc to read "Codex CLI natively supports OpenAI organizations with Zero Data Retention (ZDR) enabled."
Clean up an old config and connect to QCode
① Open ~/.codex/config.toml and delete the disable_response_storage line; if you also set it inside a profile section, delete that too (PR #3212 removed it from profile config as well). Drop --config disable_response_storage=true from any launch scripts. ② Run codex --strict-config once: the official CLI docs state it errors when config.toml contains fields that version does not recognize. In the rust-v0.161.0 source it reports only the first unrecognized field per run (unknown configuration field plus the field name), so fix it and rerun until the error is gone. ③ On a normal launch without that flag, if you still see a warning containing "Check for typos or deprecated settings.", delete each key it lists. ④ To use QCode, follow the QCode docs and put these in config.toml: model_provider = "crs", model = "gpt-6-sol", model_reasoning_effort = "high", preferred_auth_method = "apikey", then a [model_providers.crs] section with name = "crs", base_url = "https://api.qcode.cc/openai", wire_api = "responses", requires_openai_auth = true, env_key = "CRS_OAI_KEY". The provider name and the environment variable name are up to you; the docs example uses crs and CRS_OAI_KEY. ⑤ Put your key (it starts with cr_) in OPENAI_API_KEY in ~/.codex/auth.json, or supply it through the CRS_OAI_KEY environment variable instead.
Running Codex on QCode
Per the QCode docs, Codex connects to QCode over the OpenAI Responses protocol: in config.toml set base_url = "https://api.qcode.cc/openai" and wire_api = "responses", and use your QCode API key, which starts with cr_. This endpoint serves GPT models; Claude and Chinese-developed models do not go through it. For model, use gpt-6-sol as in the docs example, or gpt-6.1-sol. The Codex config example in the QCode docs has no disable_response_storage line, so configure it exactly as documented. Billing is per token; see /models for each model's price.
Frequently asked questions
What is disable_response_storage?
It was an early boolean setting in Codex CLI, removed on 2025-09-05. Set to true, it made Codex turn off server-side response storage and send the full conversation context with every request; it was meant for OpenAI organizations with Zero Data Retention (ZDR) enabled. PR #714 added it to config.toml on 2025-04-28, and PR #3212 removed it on 2025-09-05, shipping in rust-v0.30.0.
Do I still need disable_response_storage = true?
No, and setting it has no effect. As of 2026-10-08, a search of the current config-reference finds no such key; PR #3212 states "The disable_response_storage configuration option is removed." and switched requests to store: false. rust-v0.161.0 lists it as an ignored setting when loading the config.
Will an old config.toml that still has it cause an error?
Not by default, but you will get a warning. Per the rust-v0.161.0 source, unrecognized keys go into a startup warning that begins "Codex is ignoring" with the number of ignored settings, adds "Check for typos or deprecated settings.", and then lists each key followed by "is ignored." If you launch with --strict-config, the official CLI docs say Codex errors when config.toml contains fields it does not recognize; the error text in the source is unknown configuration field followed by the field name.
Is there a newer setting that replaces it?
As of 2026-10-08, a search of the current config-reference finds no such key, and no key related to ZDR or response storage either. PR #3212 explains why: it fixed store to false in Responses requests, dropped the mode that stores requests, and rewrote the repository doc to "Codex CLI natively supports OpenAI organizations with Zero Data Retention (ZDR) enabled."
What error did ZDR organizations used to hit?
The pre-removal docs/zdr.md listed an error ending in "Message: 400 Previous response cannot be used for this organization due to Zero Data Retention." The fix at the time was to launch with --config disable_response_storage=true or add disable_response_storage = true to ~/.codex/config.toml. PR #3212 deleted that passage, and current versions no longer have the setting.
How do I write config.toml when using Codex through QCode?
Follow the QCode docs: base_url = "https://api.qcode.cc/openai", wire_api = "responses", a QCode key starting with cr_, and gpt-6-sol or gpt-6.1-sol as the model; the full field list is in the setup steps above. The docs' config example has no disable_response_storage, and you do not need to add it. Billing is per token; see /models for each model's price.
Sources
The Codex open-source repository (github.com/openai/codex): the descriptions and code changes of PRs #642, #714 and #3212; the release notes for rust-v0.29.0, rust-v0.30.0, rust-v0.40.0 and rust-v0.161.0; docs/config.md under the rust-v0.40.0 tag; the codex-rs/config and codex-rs/core source under the rust-v0.161.0 tag; and issue #46470 (used only as a signal of user demand). OpenAI's official Codex docs: the Configuration Reference page and the command-line options table in the Codex docs collection (learn.chatgpt.com). The QCode docs' Codex guide (updated 2026-09-30). All fetched on 2026-10-08.
Set up Codex from the docs and start
One key starting with cr_ runs gpt-6-sol and gpt-6.1-sol in Codex, billed per token; see /models for each model's price.
Related reading
Codex CLI Third-Party API Setup Guide
How to set model_provider, base_url and env_key in config.toml, plus common errors.
Codex 401 Unauthorized: Causes and Fixes
codex login, API keys, auth.json and env_key, and 401 checks for QCode.
Codex "Selected model is at capacity"
How the capacity message differs from quota and 429, and how to switch models and back off.
The details and quotes on this page were checked on 2026-10-08 against OpenAI's official Codex docs and the Codex open-source repository; upstream changes may happen without notice. Behavior varies by version, so go by the version that codex --version reports on your machine; model availability is whatever /models shows.