CLI not respecting the disableResponseStorage setting from the ~/.codex/config.yaml file

Resolved 💬 2 comments Opened Apr 29, 2025 by alwell-kevin Closed Apr 29, 2025

💡 Likely answer: A maintainer (alwell-kevin, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

OpenAI Codex (research preview) v0.1.2504251709 │

Which model were you using?

o4-mini

What platform is your computer?

MacOS

What steps can reproduce the bug?

cat ~/.codex/config.yaml
disableResponseStorage: true
model: o4-mini
provider: openai
providers:
openai:
baseURL: https://proxy.x.ai/v1
envKey: OPENAI_API_KEY
DEBUG=1 codex
-- Note disableResponseStorage false
config: {
apiKey: 'KEY',
model: 'o4-mini',
provider: 'openai',
instructions: '',
notify: false,
approvalMode: undefined,
disableResponseStorage: false,
history: [Object],
providers: [Object],
flexMode: false
},
DEBUG=1 codex --disableResponseStorage
-- Note disableResponseStorage true
config: {
apiKey: 'KEY',
model: 'o4-mini',
provider: 'openai',
instructions: '',
notify: false,
approvalMode: undefined,
disableResponseStorage: true,
history: [Object],
providers: [Object],
flexMode: false
},

What is the expected behavior?

The CLI should respect the disableResponseStorage setting from the ~/.codex/config.yaml file without requiring the command-line flag.

What do you see instead?

The disableResponseStorage setting in the configuration file is ignored unless explicitly set via the command line.

Additional information

Additional Information:

Codex CLI Version: OpenAI Codex (research preview) v0.1.2504251709

This issue seems similar to the one discussed in Issue #561, where configuration settings like approvalMode are not respected. However, the recent PR #361 addressing approvalMode does not appear to resolve the disableResponseStorage issue.

Workaround:

As a temporary solution, users can explicitly set the --disableResponseStorage flag when running the CLI to ensure the desired behavior.

View original on GitHub ↗

2 Comments

notImposterSyndromeIfImposter · 1 year ago

I think the disableResponseStorage setting is not persisting because of a mismatch between the loading and saving processes:

The flag seems to be correctly defined in the config types (StoredConfig and AppConfig)
It's properly loaded from the config file via loadConfig() (https://github.com/openai/codex/blob/main/codex-cli/src/utils/config.ts#L368):

disableResponseStorage: storedConfig.disableResponseStorage ?? false,

However, when saveConfig() runs, it omits this property from the saved object (https://github.com/openai/codex/blob/main/codex-cli/src/utils/config.ts#L478-L483):

  const configToSave: StoredConfig = {
    model: config.model,
    provider: config.provider,
    providers: config.providers,
    approvalMode: config.approvalMode,
  };

As a result, whenever anything triggers a config save we lose the value.

Potentially Ugly fix

An ugly fix.. there's probably a more sustainable way to handle this:
Add disableResponseStorage to the list of properties in configToSave:
```
const configToSave: StoredConfig = {
model: config.model,
provider: config.provider,
providers: config.providers,
approvalMode: config.approvalMode,
disableResponseStorage: config.disableResponseStorage,
};

alwell-kevin contributor · 1 year ago

Should be fixed by this PR if issues persist. Can reopen.