TUI config/batchWrite fails for model and feature persistence when CODEX_HOME is read-only to the session

[kingtistel]

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?

1. 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.
2. Change the model in the TUI and attempt to save it as the default.
3. Observe:

Failed to save default model: config/batchWrite failed in TUI

4. Try changing feature selection / feature flags from the TUI.
5. 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:

model = "gpt-5.5"

Running codex doctor afterward shows the new model is loaded.

Related issues

Possibly related:

• TUI trust prompt hides config/batchWrite failure cause when setting project trust #25008
• unable to trust hooks, error in CLI #22847

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• TUI trust prompt hides config/batchWrite failure cause when setting project trust #25008

Powered by Codex Action

[kingtistel]

Follow-up RCA and workaround:

Root cause: the TUI error was not specific to model selection. config/batchWrite revalidates the user config before writing, and my user config had:

[features]
fast_mode = true

That conflicted with enterprise-managed requirements constraining fast_mode to false. A direct app-server probe surfaced the real validation error behind the generic TUI message:

Invalid configuration: invalid value for `features`: `features.fast_mode=true` is not in the allowed set [fast_mode=false]

Because the whole config failed validation, unrelated TUI saves such as model selection and /statusline failed through the same generic config/batchWrite failed in TUI path.

Resolution: remove the stale features.fast_mode = true entry or set it to false, then restart Codex. After setting it to:

[features]
fast_mode = false

config/batchWrite returned status: ok, and codex doctor --json reported config.toml parse: ok with fast_mode=false in the feature flag overrides.

Product improvement suggestion: surface the underlying config validation error in the TUI instead of only showing config/batchWrite failed in TUI.