What version of Codex CLI is running?

codex-cli 0.124.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

N/A - config schema/runtime validation issue

What platform is your computer?

Darwin 25.3.0 arm64 arm

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

N/A - config schema/runtime validation issue

What issue are you seeing?

The generated/editor-facing Codex config schema accepts mcp_servers.<name>.bearer_token as a valid MCP server config field, but the runtime rejects that field.

In the local generated schema, RawMcpServerConfig includes:

"bearer_token": {
  "type": "string"
}

The published schema currently appears to expose the same field:

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

However, runtime config parsing rejects bearer_token for MCP configs and uses bearer_token_env_var instead.

This is related to #5011, but not the same issue. #5011 covered documentation for bearer_token vs bearer_token_env_var. This report is about the generated/editor-facing config schema still accepting bearer_token even though the runtime rejects it.

What steps can reproduce the bug?

Use an MCP streamable HTTP config like:

[mcp_servers.docs]
url = "https://example.com/mcp"
bearer_token = "secret"

The config schema accepts bearer_token as a string property, but runtime validation rejects it.

Code references:

• codex-rs/config/src/mcp_types.rs: RawMcpServerConfig includes bearer_token, but TryFrom<RawMcpServerConfig> rejects it for streamable HTTP.
• codex-rs/config/src/mcp_edit.rs: inline bearer_token is rejected with guidance to use bearer_token_env_var.
• codex-rs/config/src/mcp_types_tests.rs: deserialize_rejects_inline_bearer_token_field.
• codex-rs/core/src/config/config_tests.rs: load_global_mcp_servers_rejects_inline_bearer_token.
• codex-rs/core/config.schema.json: RawMcpServerConfig.properties.bearer_token.

What is the expected behavior?

The editor-facing/generated config schema should not present bearer_token as a valid supported MCP config field if the runtime rejects it.

A narrow fix might be to keep the raw field internally only for compatibility/error reporting, but hide it from the generated schema or mark it clearly as unsupported/deprecated.

Additional information

Validated against local repo state and the published schema on April 24, 2026.

I’m happy to help with a focused schema/docs PR if maintainers think this is the right scope and invite a contribution, following the repo’s invitation-only contribution policy.