--- title: "Wiring Codex and ChatGPT Desktop to OpenAI Models on Amazon Bedrock Runtime" description: "A tested shared configuration for running Codex CLI and the ChatGPT desktop app against global OpenAI model profiles on Amazon Bedrock Runtime." canonical_url: "https://artificialcuriositylabs.ai/posts/2026-09-11-codex-chatgpt-bedrock-runtime/" md_url: "https://artificialcuriositylabs.ai/posts/2026-09-11-codex-chatgpt-bedrock-runtime.md" published_at: "2026-09-11T07:00:00.000Z" tags: - "agents" - "infrastructure" - "patterns" --- 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](https://learn.chatgpt.com/docs/amazon-bedrock). [Amazon Bedrock documents the Runtime endpoint](https://docs.aws.amazon.com/bedrock/latest/userguide/endpoints.html) as the recommended endpoint for new applications, including OpenAI-compatible Responses and Chat Completions paths under `/openai/v1`. The resulting request path is direct: ```text Codex CLI or ChatGPT desktop | | reads ~/.codex/config.toml v Native amazon-bedrock-runtime provider | | uses AWS profile and Region v bedrock-runtime..amazonaws.com/openai/v1 | v global.openai. ``` 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](https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-mantle.html) 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: ```bash 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. ```toml 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](https://learn.chatgpt.com/docs/config-file/config-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: | Model | Codex model ID | Verified result | | ------------- | ----------------------------- | --------------------- | | GPT-5.6 Sol | `global.openai.gpt-5.6-sol` | Native Runtime passed | | GPT-5.6 Terra | `global.openai.gpt-5.6-terra` | Native Runtime passed | | GPT-5.6 Luna | `global.openai.gpt-5.6-luna` | Native Runtime passed | | GPT-6 Astra | `global.openai.gpt-6-astra` | Native Runtime passed | [AWS introduced Sol, Terra, and Luna on Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/get-started-with-openai-gpt-5-6-sol-terra-and-luna-on-amazon-bedrock/) in July 2026 and [announced GPT-6 Astra availability](https://aws.amazon.com/blogs/machine-learning/take-on-your-most-ambitious-work-with-gpt-6-astra-on-amazon-bedrock/) 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: ```bash 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: ```bash 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: ```text 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. | Provider | Endpoint selected in the tested clients | | ------------------------ | --------------------------------------- | | `amazon-bedrock` | Bedrock Mantle | | `amazon-bedrock-runtime` | Bedrock Runtime | 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: ```bash 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](https://aws.amazon.com/blogs/machine-learning/set-up-openai-chatgpt-codex-with-litellm-on-amazon-ecs-and-amazon-bedrock/) 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.