Config schema exposes unsupported MCP `bearer_token` field
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:
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:RawMcpServerConfigincludesbearer_token, butTryFrom<RawMcpServerConfig>rejects it for streamable HTTP.codex-rs/config/src/mcp_edit.rs: inlinebearer_tokenis rejected with guidance to usebearer_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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗