Built-in amazon-bedrock provider uses outdated Mantle endpoint path (/openai/v1/responses)

I have a small fix branch ready here if it helps maintainers cherry-pick it:

https://github.com/kiwigitops/codex/tree/fix-bedrock-mantle-base-url

It changes the built-in Bedrock Mantle endpoint path from /openai/v1 to /v1 in both places that construct the provider URL:

• codex-rs/model-provider-info/src/lib.rs
• codex-rs/model-provider/src/amazon_bedrock/mantle.rs

It also updates the existing assertions in:

• codex-rs/model-provider-info/src/model_provider_info_tests.rs
• codex-rs/model-provider/src/amazon_bedrock/mantle.rs
• codex-rs/model-provider/src/amazon_bedrock/mod.rs
• codex-rs/tui/src/status/tests.rs

I tried opening this as a PR, but GitHub returned a CreatePullRequest permissions error for this repository. Verification I could run locally:

• git diff --check
• rg -n bedrock-mantle.*openai/v1 codex-rs -g *.rs returns no remaining Rust matches

I could not run the Rust test locally because this Windows environment does not have cargo on PATH.

I've independently verified this bug across all 6 Mantle-supported regions (2026-05-29, with AWS account):

| Region | /v1/responses | /openai/v1/responses |
| --- | --- | --- |
| us-east-1 | ✅ HTTP 200 | ❌ HTTP 400 |
| us-east-2 | ✅ HTTP 200 | ❌ HTTP 400 |
| us-west-2 | ✅ HTTP 200 | ❌ HTTP 400 |
| ap-northeast-1 | ✅ HTTP 200 | ❌ HTTP 400 |
| eu-west-1 | ✅ HTTP 200 | ❌ HTTP 400 |
| ap-southeast-1 | ⏱️ timeout (inference latency) | ❌ HTTP 400 |

The 400 response body is always:

{"error":{"code":"validation_error","message":"The model 'openai.gpt-oss-120b' does not support the '/openai/v1/responses' API","type":"invalid_request_error"}}

Regarding the comment in #21352 that /openai/v1 is "intentional for post-GA" — note that Bedrock Mantle (bedrock-mantle.<region>.api.aws) and Bedrock Runtime OpenAI-compat (bedrock-runtime.<region>.amazonaws.com) are two entirely different services with different SigV4 service names:

• Mantle: SigV4 service bedrock-mantle, path /v1/*, supports Responses API
• Runtime OpenAI-compat: SigV4 service bedrock, path /openai/v1/*, Chat Completions only

The /openai/v1 prefix belongs to Bedrock Runtime, not Mantle. PR #20109 conflated the two. AWS official docs (Generate responses using OpenAI APIs) have never listed /openai/v1 as a Mantle endpoint.

Fix branch with full unit tests + regression test: https://github.com/kingdoooo/codex/tree/worktree-fix-bedrock-mantle-path (commit 60a68f911)

The fix is a one-line change per file — "/openai/v1" → "/v1" in mantle.rs and model-provider-info/src/lib.rs, plus a new regression test base_url_must_not_use_openai_v1_prefix to prevent this from recurring.

Binary patch for v0.135.0 (workaround until this is merged)

Since the repo does not accept external PRs, here is a binary patch that fixes the URL path in the pre-built npm binary. This lets users on v0.135.0 use amazon-bedrock provider immediately without waiting for an official release.

The technique

The Codex binary assembles the Mantle URL via format!("https://bedrock-mantle.{region}.api.aws/openai/v1"). Rust compiles this into two string pieces: "https://bedrock-mantle." and ".api.aws/openai/v1" (18 bytes). The SDK then appends /responses after calling base_url.trim_end_matches('/').

We exploit trim_end_matches('/') by replacing .api.aws/openai/v1 (18 bytes) with .api.aws/v1/////// (18 bytes, 7 trailing slashes). Same byte length — no need to find Rust's (ptr, len) metadata. After trim_end_matches('/'), the URL collapses to the correct https://bedrock-mantle.{region}.api.aws/v1, and /responses is appended normally.

Script

import subprocess

BIN = "/opt/homebrew/lib/node_modules/@openai/codex/node_modules/" \
      "@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin/codex"

with open(BIN, "rb") as f:
    data = f.read()

old = b".api.aws/openai/v1"   # 18 bytes (format piece + default constant substring)
new = b".api.aws/v1///////"   # 18 bytes — trailing slashes stripped by trim_end_matches('/')

assert len(old) == len(new)
count = data.count(old)
assert count == 2, f"Expected 2 occurrences, found {count} — binary layout may have changed"

data = data.replace(old, new)
with open(BIN, "wb") as f:
    f.write(data)

# Re-sign (macOS rejects modified binaries without valid signature)
subprocess.run(["codesign", "--force", "--sign", "-", BIN], check=True)
print(f"Patched {count} occurrences. Done.")

Verification after patching

# Confirm no /openai/v1 remains for Mantle
BIN="$(dirname $(which codex))/../lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin/codex"
strings "$BIN" | grep "bedrock-mantle.*openai/v1"  # should be empty

# End-to-end test (requires AWS credentials + Mantle model access)
eval "$(aws configure export-credentials --format env)"
echo "" | codex exec \
  -c 'model_provider="amazon-bedrock"' \
  -c 'model="openai.gpt-oss-120b"' \
  -c 'model_providers.amazon-bedrock.aws.region="us-east-1"' \
  -c 'features.code_mode=false' \
  -c 'features.multi_agent_v2=false' \
  --skip-git-repo-check "Say hi"

The features.*=false flags are needed due to a separate issue where namespace_tools wrapping is incompatible with Mantle (tracked in #25034).

Notes

• Patch survives until next npm update @openai/codex (which overwrites the binary)
• macOS requires codesign --force --sign - after patching, otherwise the binary is killed on exec
• Path for Linux/x86 would be under codex-linux-x64 instead of codex-darwin-arm64
• Once this fix is officially released, the patch is no longer needed

Additional context from my side.

The patch mentioned in this issue appears to target npm-installed versions of Codex. Since I installed Codex via Homebrew, I have not been able to apply and test that patch in my environment.

Also, my understanding is that changes to the Codex repository generally require review and action from project maintainers. Given the current volume of open issues and pull requests, I wonder if this issue may have been overlooked or buried among other reports.

Based on the investigation and testing shared in this thread, it seems increasingly likely that the problem is related to the endpoint used by the amazon-bedrock provider rather than user configuration.

If a Codex maintainer or contributor sees this issue, could you please take a look at the endpoint implementation used by the amazon-bedrock provider and determine whether it needs to be updated?

It would be greatly appreciated, as this issue may affect other users attempting to use Codex with AWS Bedrock Mantle as well.

Thank you for your time and assistance.

It looks like this issue is related to the previously reported #21352, which has since been closed.

However, as far as I can tell, the underlying problem does not appear to be resolved yet:

• The built-in amazon-bedrock provider still sends requests to /openai/v1/responses.
• AWS Bedrock Mantle expects /v1/responses.
• This continues to result in a 404 Not Found.
• Using a custom OpenAI-compatible provider with the /v1 base URL works correctly as a workaround.

Could you clarify why #21352 was closed? Was it considered a duplicate, or was it believed to be fixed?

If it was closed as fixed, this issue is still reproducible with the current implementation and appears to require an actual code change.

for GPT 5.4/5.5, Amazon Bedrock Mantle expects /openai/v1/responses, unlike gpt-oss。

@kingdoooo

Thanks for pointing this out.

I found this AWS blog post about GPT-5.5 / GPT-5.4 and Codex on Amazon Bedrock:
https://aws.amazon.com/jp/blogs/news/get-started-with-openai-gpt-5-5-gpt-5-4-models-and-codex-on-amazon-bedrock/

I’ll try configuring Mantle to use /openai/v1/responses for GPT-5.4 / GPT-5.5, since that seems to be expected on Amazon Bedrock, unlike gpt-oss.

I've confirmed this works with GTP-5.5, so I'll switch to using GTP-5.5. Thank you — I'll close this issue.