What version of Codex CLI is running?
codex-cli 0.136.0
What subscription do you have?
Business
Which model were you using?
gpt-5.5 / gpt-5.4
What platform is your computer?
Mac OS 26.5.1 arm64
What terminal emulator and version are you using?
iTerm2 3.6.10
Codex doctor report
Config loads successfully and ~/.codex/config.toml parses OK. Doctor reports the effective model correctly after a manual edit. State DB/log DB integrity checks are OK. Remaining warnings are unrelated rollout/session inventory warnings.
What issue are you seeing?
Trying to change the model from within codex gives the below error. I'm typing /model and following prompts, but get this error (Note though that in-session the model does change).
Failed to save default model: config/batchWrite failed in TUI
Trying to change a feature like the status-line, e.g. by typing /statusline and following prompts, shows no error but the change is not persisted.
Logs also show feature persistence failing through the same path:
codex_tui::app::event_dispatch failed to persist model selection error=config/batchWrite failed in TUI
codex_tui::app::config_persistence failed to persist feature flags error=config/batchWrite failed in TUI
The active thread model can change, but the default does not persist to ~/.codex/config.toml.
The local config file itself is valid and writable by the OS user:
-rw------- ophers staff /Users/ophers/.codex/config.toml
Managed config does not appear to be involved. Nearby logs show:
/etc/codex/managed_config.toml not found
Managed preferences for com.openai.codex key config_toml_base64 not found
A reproduction through the app-server path from the same restricted session surfaced the lower-level failure:
failed to initialize sqlite state runtime under /Users/ophers/.codex:
attempt to write a readonly database
This suggests the TUI/app-server config write path is hitting the session filesystem permission boundary around $CODEX_HOME, but the TUI only shows the generic config/batchWrite failed in TUI.
What steps can reproduce the bug?
- Start Codex TUI in a trusted repo with
workspace-write / restricted filesystem permissions where the workspace is writable but $CODEX_HOME is not writable to the session.
- Change the model in the TUI and attempt to save it as the default.
- Observe:
Failed to save default model: config/batchWrite failed in TUI
- Try changing feature selection / feature flags from the TUI.
- Observe that those changes also fail through
config/batchWrite.
What is the expected behavior?
TUI config changes should persist successfully.
Actual behavior
The TUI shows only the generic message:
config/batchWrite failed in TUI
This is not actionable. It affects more than model selection; feature persistence fails too.
Workaround
Manually editing ~/.codex/config.toml works. For example:
Running codex doctor afterward shows the new model is loaded.
Related issues
Possibly related:
What version of Codex CLI is running?
codex-cli 0.136.0
What subscription do you have?
Business
Which model were you using?
gpt-5.5 / gpt-5.4
What platform is your computer?
Mac OS 26.5.1 arm64
What terminal emulator and version are you using?
iTerm2 3.6.10
Codex doctor report
Config loads successfully and
~/.codex/config.tomlparses OK. Doctor reports the effective model correctly after a manual edit. State DB/log DB integrity checks are OK. Remaining warnings are unrelated rollout/session inventory warnings.What issue are you seeing?
Trying to change the model from within
codexgives the below error. I'm typing/modeland following prompts, but get this error (Note though that in-session the model does change).Trying to change a feature like the status-line, e.g. by typing
/statuslineand following prompts, shows no error but the change is not persisted.Logs also show feature persistence failing through the same path:
The active thread model can change, but the default does not persist to
~/.codex/config.toml.The local config file itself is valid and writable by the OS user:
Managed config does not appear to be involved. Nearby logs show:
A reproduction through the app-server path from the same restricted session surfaced the lower-level failure:
This suggests the TUI/app-server config write path is hitting the session filesystem permission boundary around
$CODEX_HOME, but the TUI only shows the genericconfig/batchWrite failed in TUI.What steps can reproduce the bug?
workspace-write/ restricted filesystem permissions where the workspace is writable but$CODEX_HOMEis not writable to the session.config/batchWrite.What is the expected behavior?
TUI config changes should persist successfully.
Actual behavior
The TUI shows only the generic message:
This is not actionable. It affects more than model selection; feature persistence fails too.
Workaround
Manually editing
~/.codex/config.tomlworks. For example:Running
codex doctorafterward shows the new model is loaded.Related issues
Possibly related: