Wiring Codex and ChatGPT Desktop to OpenAI Models on Amazon Bedrock Runtime

Codex CLI and the ChatGPT desktop app can use the same native Amazon Bedrock Runtime configuration. The working pattern has three parts: the built-in Runtime provider, an AWS profile and Region, and a global model profile ID.

I verified this pattern on September 11, 2026 with four OpenAI model profiles: GPT-5.6 Sol, Terra, Luna, and GPT-6 Astra. All four completed headless runs through the native Runtime provider in the desktop app’s bundled Codex 0.153.4. Astra also passed with Codex CLI 0.154.0 using the same saved configuration.

TL;DR

• Codex CLI and the ChatGPT desktop app read the same local Codex configuration, so one provider definition can serve both surfaces.
• The endpoint remains regional, while a global.openai.* model ID selects global cross-Region inference.
• The built-in amazon-bedrock-runtime provider uses an AWS profile directly; no static API key, token generator, or local proxy is required.
• amazon-bedrock and amazon-bedrock-runtime are different providers. The first selects Mantle in the tested clients; the second selects Bedrock Runtime.

The working architecture

OpenAI documents shared local configuration across Codex surfaces. Amazon Bedrock documents the Runtime endpoint as the recommended endpoint for new applications, including OpenAI-compatible Responses and Chat Completions paths under /openai/v1.

The resulting request path is direct:

Codex CLI or ChatGPT desktop
        |
        | reads ~/.codex/config.toml
        v
Native amazon-bedrock-runtime provider
        |
        | uses AWS profile and Region
        v
bedrock-runtime.<region>.amazonaws.com/openai/v1
        |
        v
global.openai.<model>

There is no gateway in this path. AWS credentials stay in the normal local profile chain, and Codex sends Responses API traffic directly to Bedrock Runtime.

The word global applies to the model profile, not the hostname. The network endpoint still contains a Region such as us-west-2; the global.openai.* model ID tells Bedrock to use its global cross-Region inference profile. The Bedrock Responses API documentation shows the Runtime base URL and global profile naming pattern.

Prerequisites

The setup needs:

• A current Codex CLI installation
• The ChatGPT desktop app with Codex support
• An AWS profile with permission to invoke the selected Bedrock models

Confirm the AWS session before changing Codex:

aws sts get-caller-identity --profile YOUR_AWS_PROFILE

The shared Codex configuration

Add the following provider to ~/.codex/config.toml. Replace YOUR_AWS_PROFILE and select a Bedrock Region where the models are available.

model = "global.openai.gpt-6-astra"
model_provider = "amazon-bedrock-runtime"
model_reasoning_effort = "medium"

[model_providers.amazon-bedrock-runtime.aws]
region = "us-west-2"
profile = "YOUR_AWS_PROFILE"

The Codex configuration sample documents AWS profile and Region settings for built-in Amazon Bedrock providers. This configuration references the selected profile rather than embedding access keys. The profile can still use AWS IAM Identity Center, role assumption, environment credentials, or another supported AWS credential source.

Global OpenAI model profiles

These are the four global profile IDs I verified:

AWS introduced Sol, Terra, and Luna on Amazon Bedrock in July 2026 and announced GPT-6 Astra availability in September 2026. Model access still depends on the account, selected Region, and current Bedrock catalog, so discovery in one account is evidence for that environment rather than a universal availability guarantee.

Set Astra as the default in the configuration, or select a model for an individual Codex run:

codex -m global.openai.gpt-5.6-sol
codex -m global.openai.gpt-5.6-terra
codex -m global.openai.gpt-5.6-luna
codex -m global.openai.gpt-6-astra

Verify the Runtime path

A headless run provides a clean test because it removes the interactive interface from the request path:

codex exec \
  --ephemeral \
  --skip-git-repo-check \
  -m global.openai.gpt-5.6-sol \
  "Reply with exactly SOL_RUNTIME_OK"

Repeat the probe with the other model IDs and a distinct expected string. My four probes returned:

SOL_RUNTIME_OK
TERRA_RUNTIME_OK
LUNA_RUNTIME_OK
ASTRA_RUNTIME_OK

This verifies more than model discovery. It confirms that Codex can load the provider, resolve the named AWS profile, reach the Runtime endpoint, select the global profile, and receive a model response.

For the desktop app, fully quit and reopen the application after changing ~/.codex/config.toml. The model picker should then expose the same provider catalog. Existing conversations may retain their original model selection, so use a new task when validating a newly selected model.

The provider name selects the endpoint

The two built-in Bedrock provider names do not select the same endpoint.

This distinction is visible in an actual call. With Codex 0.153.4, amazon-bedrock sent Astra to a bedrock-mantle URL and received a model-not-found response. The same binary, model ID, AWS profile, and Region succeeded after changing only the provider to amazon-bedrock-runtime.

The native provider passed across both tested Codex versions:

• Desktop-bundled Codex 0.153.4 returned SOL_NATIVE_OK, TERRA_NATIVE_OK, LUNA_NATIVE_OK, and ASTRA_NATIVE_OK.
• Standalone Codex CLI 0.154.0 returned CLI_NATIVE_RUNTIME_OK from the same saved provider configuration.

Inspect the versions when diagnosing behavior:

codex --version

The desktop app’s bundled version is visible in its diagnostic output. Version differences still matter for model catalogs and client features, but they do not require a custom provider for this Runtime path.

Direct Runtime first, gateway when required

Direct Bedrock Runtime is the lower-complexity path when AWS identity, model access, logging, and billing controls meet the requirement. An AWS reference architecture for Codex with LiteLLM positions a gateway as an additional layer for centralized routing, budgets, or policy controls—not as a requirement for basic Codex connectivity.

That distinction matters. A local proxy or hosted gateway adds another credential boundary, another failure point, and another component to operate. Add one when it supplies a control the direct path does not provide.

What remains open

The native Runtime provider passed direct Codex execution in both binaries. The desktop app also restarted with successful configuration and model-catalog reads. I have not yet tested every desktop-only helper action against all four global model profiles; those flows can select models independently from the main conversation.

The configuration boundary is the part to keep under test: one file, two client surfaces, four global model profiles, and one AWS profile. When any client version changes, rerun one headless probe and one fresh desktop task before treating the wiring as stable.

So what: Bedrock model access is only one layer of the setup. The complete contract is endpoint, API format, authentication, model profile, and client configuration—and all five need to work together.