Windows: no equivalent managed OTel migration after managed_config.toml removal; requirements.toml ignores [otel]

What version of Codex CLI is running?

codex-cli 0.153.4, using the Windows binary installed by the desktop app, invoked directly as codex.exe app-server --stdio.

The latest release at the time of writing is 0.154.0. I have not run the reproduction on 0.154.0; source inspection shows that its Windows legacy-config exclusion and lack of an otel field in ConfigRequirementsToml remain (links below).

What subscription do you have?

The reproduction uses isolated CODEX_HOME directories without account credentials. No sign-in or model request is required.

Which model were you using?

Not applicable: configuration-read RPCs only, before starting a model turn.

What platform is your computer?

Windows x64, OS version 10.0.26200.0.

What terminal emulator and version are you using (if applicable)?

Not applicable: the app-server is launched as a subprocess with stdin/stdout pipes from a Python harness, through PowerShell.

Codex doctor report

Not collected for this report. The evidence below comes from isolated configuration-read RPCs.

What issue are you seeing?

We distribute Codex OTel settings to Windows devices through Intune. After the removal of default CODEX_HOME/managed_config.toml loading, we cannot identify a supported migration that preserves managed OTel startup precedence over user configuration, let alone enforces OTel policy.

I understand that #38947 intentionally removed this loading behavior and appears in the 0.149.0 changelog. I am not reporting this as a change first introduced in 0.153.4.

The replacement paths have different semantics:

• System config.toml provides defaults that users can override; it does not preserve the legacy managed startup precedence.
• In the tested 0.153.4 binary, system requirements.toml is read, but its [otel] block has no effect. A user setting of exporter = "none" remains effective.

The official managed-configuration documentation, accessed September 10, still lists ~/.codex/managed_config.toml for Windows, describes managed startup precedence over user configuration and CLI overrides, and recommends using managed configuration for OTel settings. This does not explain how Windows administrators should migrate this use case after #38947.

I recognize that legacy managed defaults were startup defaults, not an immutable policy for the entire runtime. The issue is both the lost startup precedence and the lack of an identified enforceable replacement for OTel.

What steps can reproduce the bug?

Use a disposable Windows test environment: the requirements path below is machine-wide and affects new Codex processes. Do not overwrite an existing policy file. Restore the original machine state afterward.

1. Place this in C:\ProgramData\OpenAI\Codex\requirements.toml:

allow_appshots = false

[otel]
environment = "requirements-probe"
log_user_prompt = false
trace_exporter = "none"
metrics_exporter = "none"

[otel.exporter.otlp-http]
endpoint = "http://127.0.0.1:9/v1/logs"
protocol = "binary"

2. Set CODEX_HOME to an isolated directory with a config.toml containing only:

[analytics]
enabled = false

3. Start codex.exe app-server --stdio. Send the following JSON-RPC messages in order, waiting for initialization to succeed before sending the remaining messages:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"clientInfo":{"name":"requirements-probe","version":"1"},"capabilities":{"experimentalApi":true}}}
{"jsonrpc":"2.0","method":"initialized"}
{"jsonrpc":"2.0","id":2,"method":"configRequirements/read","params":{}}
{"jsonrpc":"2.0","id":3,"method":"config/read","params":{"includeLayers":true}}

4. Repeat in a fresh process with another isolated user config containing [analytics] enabled = false and this OTel table:

[otel]
environment = "user-probe"
exporter = "none"
trace_exporter = "none"
metrics_exporter = "none"
log_user_prompt = false

5. As a positive control, repeat in a fresh process with the OTel block from step 1 in the user config.toml, changing only environment to "user-positive-probe". Keep analytics disabled and the same system requirements file.

Observed results, omitting unrelated response fields:

Case	configRequirements/read	config/read effective otel
No user OTel block	requirements.allowAppshots = false	null
User exporter disabled	requirements.allowAppshots = false	User environment and exporter = "none"
User positive control	requirements.allowAppshots = false	user-positive-probe, OTLP/HTTP endpoint http://127.0.0.1:9/v1/logs, protocol binary

All three configuration reads succeeded without RPC errors. The recognized allowAppshots setting proves that the system requirements file was read. The positive control demonstrates that the OTel TOML is accepted in user configuration. This test checks configuration loading, not successful OTLP delivery; the loopback endpoint is deliberately not a collector.

What is the expected behavior?

Please provide or document a supported Windows migration for administrator-managed OTel configuration. In particular:

1. How should an administrator ensure a configured exporter/endpoint and log_user_prompt = false cannot be overridden by user configuration?
2. If this is not currently supported, can OTel requirements or an equivalent managed mechanism be added, with a migration path for existing Windows deployments?
3. Please align the Windows documentation and migration warning with the supported OTel behavior. A warning for unsupported keys in a requirements file would also help avoid a false impression that the policy is active.

Copying settings into each user's config.toml can restore opt-in export, but does not meet the central policy requirement. This gap blocks our managed Windows rollout.

Additional information

• Related but distinct: #16248 asks for OTel distribution through the cloud admin console for teams without MDM. This report concerns existing Windows MDM deployments after the legacy file was retired.
• Intentional removal: https://github.com/openai/codex/pull/38947
• 0.154.0 Windows exclusion: https://github.com/openai/codex/blob/rust-v0.154.0/codex-rs/config/src/loader/layer_io.rs#L65
• 0.154.0 requirements type, with no otel field: https://github.com/openai/codex/blob/rust-v0.154.0/codex-rs/config/src/config_requirements.rs#L987
• The live reproduction above is Windows-only. It does not establish a macOS MDM regression.

Start with codex-rs/config/src/config_requirements.rs and codex-rs/config/src/loader/layer_io.rs, then reproduce the Windows behavior using the configRequirements/read and config/read RPCs described in the issue. Compare the requirements schema and Windows loading path with the documented managed-configuration behavior. Done means a supported Windows OTel migration is identified or implemented, with aligned documentation and clear handling of unsupported requirements keys.