Feature request: configurable `base_url` / `api_base` for the `amazon-bedrock` provider

Open 💬 6 comments Opened Jun 18, 2026 by mberthelier94

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:

  1. The proxy knows the client is talking Bedrock semantics, not raw OpenAI semantics.
  2. The proxy can apply the correct transformations for Mantle (strip compaction_trigger, handle reasoning tokens, etc.) without needing to guess based on heuristics.
  3. Context compaction, apply_patch, and other Codex-native features work correctly end-to-end through the proxy.

Alternatives considered

  • Use openai provider + 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!

View original on GitHub ↗

6 Comments

mberthelier94 · 1 month ago

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.rsmerge_configured_model_providers

Adds base_url as an accepted override field for amazon-bedrock alongside the existing aws.profile/aws.region. All other non-default fields still produce a clear error.

let base_url_override = provider.base_url.take();
// ...
if let Some(base_url) = base_url_override {
    built_in_provider.base_url = Some(base_url);
}
codex-rs/model-provider/src/amazon_bedrock/mod.rsapi_provider / runtime_base_url

Both methods previously called mantle::runtime_base_url() unconditionally, overwriting any configured base_url with the region-derived Mantle endpoint. They now short-circuit when a custom URL is set:

fn has_custom_base_url(&self) -> bool {
    self.info.base_url.as_deref()
        .is_some_and(|u| u != AMAZON_BEDROCK_DEFAULT_BASE_URL)
}

async fn runtime_base_url(&self) -> Result<Option<String>> {
    if self.has_custom_base_url() {
        return Ok(self.info.base_url.clone());
    }
    // ... existing region-based resolution
}

AWS credentials/region are still resolved normally (SigV4 signing still needs the region).

codex-rs/model-provider-info/src/model_provider_info_tests.rs

Two new tests:

  • test_merge_configured_model_providers_applies_amazon_bedrock_base_url_override
  • custom_base_url_bypasses_runtime_url_computation

---

Happy to make any changes if needed.

houleixx · 1 month ago

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-bedrock configurable in the same spirit as the OpenAI provider: it enables usage tracking, budget control, and request inspection
without patching Codex itself.

mabaojinbj · 24 days ago

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.

Nicolas0315 · 24 days ago

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: 4cb41eb29c381738d93d7c3c183fce6015ee5a1a

What changed:

  • model_providers.amazon-bedrock.base_url is now an allowed built-in override, alongside aws.profile and aws.region.
  • The Amazon Bedrock runtime provider preserves a custom base_url instead of replacing it with the region-derived Mantle endpoint.
  • AWS auth resolution remains on the existing path; only runtime URL selection changes.
  • Added focused coverage for merge behavior, config loading, custom runtime URL behavior, and the existing unsupported-override rejection path.
  • Also fixed a one-line CreateThreadParams test fixture compile miss by adding the new history_mode field default.

Local validation:

  • git diff --check
  • just fmt
  • just 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_override
  • just test -p codex-core load_config_rejects_unsupported_amazon_bedrock_overrides
  • just test -p codex-core submission_loop_channel_close_runs_full_thread_teardown

SSH validation on the exact commit:

  • cyberagent-mac-m5max: git diff --check HEAD~1 HEAD + all focused just test commands passed.
  • nicolas2025: git diff --check HEAD~1 HEAD + focused cargo test fallback passed (cargo-nextest is not installed on that host).
  • nicolas-macbook-pro: git diff --check HEAD~1 HEAD passed; Rust tests skipped because cargo is not installed there.
  • rtx5060ti: git diff --check HEAD~1 HEAD passed; Rust tests skipped due the host's known linker setup issue.

Full just test -p codex-core was also attempted locally. It compiled after the fixture fix, then failed on environment-dependent tests unrelated to this patch: parent C:\Users\ogosh\AGENTS.md was injected into agents_md snapshots, and codex-windows-sandbox-setup.exe was not present for a Windows sandbox integration test.

bilal4k · 21 days ago

up please for review/merge

francisreyes-tfs · 4 days ago

just updated! 3151954