Feature request: configurable `base_url` / `api_base` for the `amazon-bedrock` provider
Summary
When using Codex with the amazon-bedrock provider, there is currently no way to configure a custom base_url (like there is for the openai provider via openai_base_url in config.toml). This makes it impossible to route Bedrock traffic through an intermediate proxy.
Context
We operate an internal AI gateway that sits in front of AWS Bedrock and adds usage tracking, rate limiting, and budget controls for developers. The gateway exposes an OpenAI-compatible Responses API endpoint and forwards traffic to:
- AWS Bedrock for Claude models (Anthropic)
- AWS Bedrock Mantle for GPT-5.x models (OpenAI models served via Bedrock's OpenAI-compatible layer)
For Claude, we use the openai provider in config.toml and override openai_base_url to point to our gateway — this works perfectly.
For GPT-5.x via Bedrock Mantle, we would like to do the same, but the amazon-bedrock provider has no equivalent base_url option. We are forced to use the openai provider as a workaround, which causes a different problem described below.
The core problem: openai provider ≠ amazon-bedrock provider for Mantle
When Codex uses the openai provider (even pointing to a Bedrock Mantle endpoint), it sends requests using the standard OpenAI Responses API wire format — including Codex-specific item types that are part of the OpenAI protocol but unknown to Bedrock Mantle:
| Item type | OpenAI native | Bedrock Mantle |
|---|---|---|
| compaction_trigger | ✅ understood (model trained to respond with compaction item) | ❌ 400 invalid request body: Invalid 'input': value did not match any expected variant |
| compaction (input) | ✅ replayed verbatim | ❌ same rejection |
| reasoning with encrypted_content | ✅ passed through | ❌ rejected unless prefixed rsn_ / smry_ |
| custom_tool_call / custom_tool_call_output | ✅ Codex-internal | ❌ rejected |
This means that context compaction (remote compaction v2) fails when Codex uses GPT-5.x via a proxy pointing to Bedrock Mantle: Codex sends a compaction_trigger item, Mantle rejects the request, Codex surfaces stream disconnected before completion: response.failed event received, and long sessions loop or crash.
Our current workaround is to intercept compaction requests in our proxy, strip the compaction_trigger, ask GPT to produce a plain-text summary, encode it as a fake encrypted_content blob with our own prefix, and return a synthetic compaction output item. This works but is fragile and requires ongoing maintenance as the protocol evolves.
Requested change
Add a bedrock_base_url (or amazon_bedrock_base_url) option to the amazon-bedrock provider configuration in config.toml, analogous to openai_base_url for the openai provider:
model_provider = "amazon-bedrock"
model = "gpt-5.4"
amazon_bedrock_base_url = "https://my-internal-gateway.example.com/bedrock"
This would allow proxies to receive traffic as the amazon-bedrock provider, which means:
- The proxy knows the client is talking Bedrock semantics, not raw OpenAI semantics.
- The proxy can apply the correct transformations for Mantle (strip
compaction_trigger, handlereasoningtokens, etc.) without needing to guess based on heuristics. - Context compaction,
apply_patch, and other Codex-native features work correctly end-to-end through the proxy.
Alternatives considered
- Use
openaiprovider + proxy: Works for basic turns but breaks context compaction and requires the proxy to maintain a growing list of OpenAI-specific item type workarounds. - Hardcode a reverse proxy in front of Bedrock: Loses the authentication and usage-tracking capabilities of an intermediate gateway.
Additional notes
The same issue may affect anyone building internal AI gateways, enterprise proxies, or compliance layers in front of AWS Bedrock that want to serve Codex users without exposing direct AWS credentials.
Thank you for considering this!
6 Comments
I have implemented this feature — since the repository restricts PRs to collaborators, I am posting the implementation here.
Fork PR: https://github.com/mberthelier94/codex/pull/2
Fork diff: https://github.com/openai/codex/compare/main...mberthelier94:codex:feat/amazon-bedrock-custom-base-url
---
Changes (3 files, ~40 lines)
codex-rs/model-provider-info/src/lib.rs—merge_configured_model_providersAdds
base_urlas an accepted override field foramazon-bedrockalongside the existingaws.profile/aws.region. All other non-default fields still produce a clear error.codex-rs/model-provider/src/amazon_bedrock/mod.rs—api_provider/runtime_base_urlBoth methods previously called
mantle::runtime_base_url()unconditionally, overwriting any configuredbase_urlwith the region-derived Mantle endpoint. They now short-circuit when a custom URL is set:AWS credentials/region are still resolved normally (SigV4 signing still needs the region).
codex-rs/model-provider-info/src/model_provider_info_tests.rsTwo new tests:
test_merge_configured_model_providers_applies_amazon_bedrock_base_url_overridecustom_base_url_bypasses_runtime_url_computation---
Happy to make any changes if needed.
This would also help local observability/proxy tools.
In ccglass, the OpenAI-compatible path works because Codex can be pointed at a local proxy via its base URL config. Provider-specific transports that do not
expose a configurable base URL are much harder to observe or route through internal gateways.
So +1 to making
amazon-bedrockconfigurable in the same spirit as the OpenAI provider: it enables usage tracking, budget control, and request inspectionwithout patching Codex itself.
For configurable base_url, Vynex API works as an OpenAI-compatible endpoint. Set base_url to our /v1 endpoint and call any of 34+ models (GPT-4o, Claude, DeepSeek, Qwen). HK company, USDT payment, bulk pricing.
I pushed a branch with this implemented against current
main:Compare: https://github.com/openai/codex/compare/main...Nicolas0315:codex/amazon-bedrock-base-url
Commit:
4cb41eb29c381738d93d7c3c183fce6015ee5a1aWhat changed:
model_providers.amazon-bedrock.base_urlis now an allowed built-in override, alongsideaws.profileandaws.region.base_urlinstead of replacing it with the region-derived Mantle endpoint.CreateThreadParamstest fixture compile miss by adding the newhistory_modefield default.Local validation:
git diff --checkjust fmtjust test -p codex-model-provider-info(23/23)just test -p codex-model-provider(50/50)just test -p codex-core load_config_applies_amazon_bedrock_base_url_overridejust test -p codex-core load_config_rejects_unsupported_amazon_bedrock_overridesjust test -p codex-core submission_loop_channel_close_runs_full_thread_teardownSSH validation on the exact commit:
cyberagent-mac-m5max:git diff --check HEAD~1 HEAD+ all focusedjust testcommands passed.nicolas2025:git diff --check HEAD~1 HEAD+ focusedcargo testfallback passed (cargo-nextestis not installed on that host).nicolas-macbook-pro:git diff --check HEAD~1 HEADpassed; Rust tests skipped because cargo is not installed there.rtx5060ti:git diff --check HEAD~1 HEADpassed; Rust tests skipped due the host's known linker setup issue.Full
just test -p codex-corewas also attempted locally. It compiled after the fixture fix, then failed on environment-dependent tests unrelated to this patch: parentC:\Users\ogosh\AGENTS.mdwas injected into agents_md snapshots, andcodex-windows-sandbox-setup.exewas not present for a Windows sandbox integration test.up please for review/merge
just updated! 3151954