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

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 ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗