What variant of Codex are you using?
App
What feature would you like to see?
Summary
config.toml currently has no way to attach custom HTTP headers (e.g. OpenAI-Project) to requests sent through the built-in amazon-bedrock model provider.
Current behavior
merge_configured_model_providers() (codex-rs/model-provider-info/src/lib.rs:462-493) only allows aws.profile and aws.region to be overridden for the amazon-bedrock provider. Any other non-default field, including http_headers, causes a hard error:
model_providers.amazon-bedrock only supports changing `aws.profile` and `aws.region`; other non-default provider fields are not supported
Setting headers under the aws sub-table instead (ModelProviderAwsAuthInfo, same file, lines 143-151) doesn't error, but is silently dropped, since that struct only has profile and region fields.
Why this matters
Some Bedrock setups (e.g. routing through an internal Bedrock proxy/gateway) require a project-identifying header such as OpenAI-Project on every request. Falling back to a fully custom (non-bedrock) model provider is not a good workaround, since it would require reimplementing AWS SigV4 signing / assume-role manually.
Note: runtime plumbing already supports this
The rest of the pipeline already handles arbitrary headers on the bedrock path:
ModelProviderInfo.http_headers is turned into a HeaderMap by build_header_map() and applied via to_api_provider().- The Bedrock provider's
api_provider() (codex-rs/model-provider/src/amazon_bedrock/mod.rs:81-87) uses this same to_api_provider().
- SigV4 header stripping (
codex-rs/model-provider/src/amazon_bedrock/auth.rs:111-124) only removes headers containing _ (e.g. session_id), so hyphenated headers like OpenAI-Project survive and get signed correctly.
So only the config-time validation blocks this — no changes are needed to request building or signing.
Proposed fix
In merge_configured_model_providers(), extend the amazon-bedrock special case to also accept http_headers and env_http_headers, merging (extending, not replacing) them into the built-in provider's maps so the existing x-amzn-mantle-client-agent header is preserved.
Additional information
No response
What variant of Codex are you using?
App
What feature would you like to see?
Summary
config.tomlcurrently has no way to attach custom HTTP headers (e.g.OpenAI-Project) to requests sent through the built-inamazon-bedrockmodel provider.Current behavior
merge_configured_model_providers()(codex-rs/model-provider-info/src/lib.rs:462-493) only allowsaws.profileandaws.regionto be overridden for theamazon-bedrockprovider. Any other non-default field, includinghttp_headers, causes a hard error:Setting headers under the
awssub-table instead (ModelProviderAwsAuthInfo, same file, lines 143-151) doesn't error, but is silently dropped, since that struct only hasprofileandregionfields.Why this matters
Some Bedrock setups (e.g. routing through an internal Bedrock proxy/gateway) require a project-identifying header such as
OpenAI-Projecton every request. Falling back to a fully custom (non-bedrock) model provider is not a good workaround, since it would require reimplementing AWS SigV4 signing / assume-role manually.Note: runtime plumbing already supports this
The rest of the pipeline already handles arbitrary headers on the bedrock path:
ModelProviderInfo.http_headersis turned into aHeaderMapbybuild_header_map()and applied viato_api_provider().api_provider()(codex-rs/model-provider/src/amazon_bedrock/mod.rs:81-87) uses this sameto_api_provider().codex-rs/model-provider/src/amazon_bedrock/auth.rs:111-124) only removes headers containing_(e.g.session_id), so hyphenated headers likeOpenAI-Projectsurvive and get signed correctly.So only the config-time validation blocks this — no changes are needed to request building or signing.
Proposed fix
In
merge_configured_model_providers(), extend theamazon-bedrockspecial case to also accepthttp_headersandenv_http_headers, merging (extending, not replacing) them into the built-in provider's maps so the existingx-amzn-mantle-client-agentheader is preserved.Additional information
No response