Published Codex config schema is stricter than tolerated real-world `~/.codex/config.toml` files (4 root-level fields)

The published/editor-facing Codex config schema is currently stricter than at least some real ~/.codex/config.toml files that the installed CLI still tolerates.

This issue is about schema content / compatibility, not schema delivery.

What I validated

I validated a real ~/.codex/config.toml against the live published schema URL:

• https://developers.openai.com/codex/config-schema.json

As of April 7, 2026, that endpoint is reachable from this host and returns HTTP 200 / application/json, so this is no longer about 403 or schema fetch failures.

I parsed the TOML and validated it directly against the published schema. The mismatch is now much narrower than I originally thought.

Exact incompatibility

The published schema rejects exactly these 4 top-level fields from the real config:

• ask_for_approval = "never"
• sandbox = "danger-full-access"
• experimental_use_rmcp_client = true
• top-level [env]

In my case the top-level [env] table only contains:

• USE_OMX_EXPLORE_CMD = "1"

The validation failure is:

• Additional properties are not allowed ('ask_for_approval', 'env', 'experimental_use_rmcp_client', 'sandbox' were unexpected)

What now validates correctly

Everything else I tested in this same real-world config now validates correctly, including:

• approval_policy
• sandbox_mode
• experimental_compact_prompt_file
• features.child_agents_md
• mcp_servers.*
• notice.*
• plugins.*

So this no longer looks like a broad schema mismatch. It looks like a precise 4-field compatibility gap at the config root.

Important runtime data point

On the same host, the installed CLI still starts against this same ~/.codex/config.toml:

• codex-cli 0.119.0-alpha.11
• codex features list succeeds

So the current practical mismatch seems to be one of these:

1. the published schema is stricter than a config format still tolerated by the CLI/runtime for compatibility reasons, or
2. these 4 fields are legacy and the CLI still tolerates them, but the schema intentionally does not, in which case there needs to be an explicit migration path / compatibility note.

Request

Please clarify which of these is intended:

1. these 4 root-level fields are still accepted for backward compatibility and should be represented in the schema as deprecated compatibility aliases, or
2. these 4 root-level fields are no longer part of the supported config dialect and users should migrate away from them, with docs and/or CLI warnings pointing to the canonical replacements.

If the second is intended, it would help to document the canonical replacements explicitly for:

• ask_for_approval -> approval_policy
• sandbox -> sandbox_mode
• experimental_use_rmcp_client -> current canonical feature/config path, if any
• top-level [env] -> current canonical config location, if any

I can provide a minimized repro config if useful.