model and model_reasoning_effort are not set by global policy

[mangiucugna]

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.519.31651 (3017)

What subscription do you have?

Enterprise

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

When setting global policies via https://chatgpt.com/codex/cloud/settings/policies the model and model_reasoning_effort fields are ignored by the app (both cli and desktop) while feature flags are correctly applied

What steps can reproduce the bug?

Step 1.
Set a global policy in https://chatgpt.com/codex/cloud/settings/policies as follows:

# requirements.toml

model = "gpt-5.4"
model_reasoning_effort = "medium"

[features]
fast_mode = false

Step 2.
Close the app(s)

Step 3.
Edit ~/.codex/config.toml and remove the model and model_reasoning_effort fields

Step 4.
Open the app and notice that fast_mode is not available anymore but the model is set based on the last model and reasoning effort used in the last thread

I have asked Codex to debug the problem and this was the summary:

The cloud policy is being applied, but model / model_reasoning_effort are losing to the session/collaboration-mode state. fast_mode can still work because it is a feature/service-tier flag; it does not need to rewrite the session’s pinned model.

Evidence in this thread:

cloud policy cache: model = "gpt-5.4", model_reasoning_effort = "medium", fast_mode = false
active turn context: collaboration_mode.settings.model = "gpt-5.5", reasoning_effort = "xhigh"
sqlite thread row: model = "gpt-5.5", reasoning_effort = "xhigh"

So the likely bug is narrower: cloud-managed policy can affect feature flags, but model/reasoning are captured into collaboration_mode and/or persisted through SQLite, then reused. That aligns with Codex source where session startup builds CollaborationMode from resolved model and model_reasoning_effort (source), and with an existing issue about SQLite-persisted reasoning overriding config (#17436).

Disabling sqlite may mask it, but it is not a clean fix. The cleaner bug report is: “cloud policy disables fast_mode, but model and model_reasoning_effort from the same policy are ignored because Desktop/local session state persists collaboration_mode model/reasoning.”

What is the expected behavior?

codex should set the defaults of the group policies set by the administrator

Additional information

No response

[JunJieLiu51520]

Root cause analysis

I traced the full policy loading → config resolution → session startup → thread resume flow. The issue has two parts.

Part A: ConfigRequirementsToml has no model or model_reasoning_effort fields

The cloud/global policy struct ConfigRequirementsToml (codex-rs/config/src/config_requirements.rs, ~line 747-769) does not define model or model_reasoning_effort fields. It only supports:

• feature_requirements (feature flags — the working path)
• allowed_approval_policies, allowed_sandbox_modes, allowed_web_search_modes
• enforce_residency, network, permissions, hooks, mcp_servers, etc.

If the cloud policy API returns model = "gpt-5.4", it is silently discarded during TOML deserialization (serde's default behavior ignores unknown fields).

Why feature flags work but model doesn't

Feature flags work because ConfigRequirementsToml.feature_requirements is a proper field (~line 757):

#[serde(rename = "features", alias = "feature_requirements")]
pub feature_requirements: Option<FeatureRequirementsToml>,

This is loaded via the config layer system (codex-rs/config/src/loader/mod.rs, ~line 132) and applied via ManagedFeatures::from_configured_with_warnings() (codex-rs/core/src/config/managed_features.rs, ~line 42-87), which pins features to their required values.

There is no equivalent pinning mechanism for model or model_reasoning_effort.

Part B: Session and SQLite state override even local config

The model resolution path:

1. ConfigOverrides.model (CLI override) at codex-rs/core/src/config/mod.rs ~line 2489
2. Merged with cfg.model (user config.toml) at ~line 3153
3. Used in CollaborationMode construction at codex-rs/core/src/session/mod.rs ~lines 558-567

On thread resume, merge_persisted_resume_metadata() (codex-rs/app-server/src/request_processors/thread_processor.rs, ~lines 153-171) applies the thread's previously-persisted model/reasoning_effort as overrides — further ensuring cloud policy cannot win.

Proposed fix approach

Recommended (direct enforcement):

1. Add model: Option<String> and model_reasoning_effort: Option<ReasoningEffort> to ConfigRequirementsToml in config_requirements.rs
2. Add corresponding fields to ConfigRequirementsWithSources and handle them in merge_unset_fields()
3. In config resolution (~line 3153 of config/mod.rs), apply cloud policy model with higher priority than user config — similar to how feature_requirements pins features
4. In session startup (session/mod.rs ~line 558), check if cloud policy forces a specific model
5. In the resume path (thread_processor.rs ~line 158), do NOT apply persisted model/reasoning_effort when cloud policy is enforcing specific values

Alternative (constraint-based):

Add allowed_models: Option<Vec<String>> and allowed_reasoning_efforts: Option<Vec<ReasoningEffort>> to ConfigRequirementsToml, and validate user selections against these constraints (like the existing allowed_sandbox_modes pattern). This doesn't set a default but prevents users from deviating.

The direct enforcement approach is simpler and matches the reporter's expectation.

Happy to submit a PR if the team would like me to implement this fix.