AWS Builder Center

Builder Center

OpenAI Codex on Amazon Bedrock

OpenAI Codex on Amazon Bedrock Run in India — a self-service setup for in-country AI coding

Hari Shanker Tripathi

Development teams increasingly want a capable AI coding assistant such as Codex. The usual path is Codex talking to OpenAI's hosted API, where OpenAI runs the model on its own infrastructure and determines where that processing happens. For a regulated or public-sector organization, that can mean source code, prompts, and proprietary context are processed outside your control and potentially outside your country. Routing Codex through Amazon Bedrock removes OpenAI's hosted API from the request path: the model runs in your AWS account, in the region you choose, meeting your data sovereignty requirements.
This article walks through a small, cross-platform set of scripts that connect Codex to Amazon Bedrock in an India region, so OpenAI-compatible models are served in-country.
Note: This is technical reference material describing a setup and its configuration options. It is not a security certification, compliance attestation, or legal advice. Validate the approach against your own security, privacy, and regulatory requirements before production use.


Overview and context

Running Codex on Amazon Bedrock is intended to reduce the data-residency trade-off. OpenAI-compatible models (for example  in.openai.gpt-5.6-terra ) are served from Bedrock in  ap-south-1  (Mumbai), with  ap-south-2  (Hyderabad) as the in-country cross-Region destination.
How this is designed to support data residency
  • In-country inference — model calls go to the Bedrock endpoint in an India region, and the India geographic inference profile keeps routing within  ap-south-1  /  ap-south-2 .
  • Your account, your controls — everything runs in your AWS account under your IAM, logging (CloudTrail), and Bedrock invocation logs in the India regions.
  • Per-user identity — each developer gets a dedicated low-privilege IAM user and their own credential, rather than a shared account-wide secret.
  • OpenAI's hosted API is out of the request path — Codex is pointed at the Bedrock runtime endpoint, so inference runs in your AWS account rather than on OpenAI's own infrastructure.

Important — this direct setup is for validation / proof-of-concept

In this configuration, Codex connects directly to Amazon Bedrock using a per-user bearer token. The provisioning script creates a real IAM user and a long-lived Amazon Bedrock API key for each developer. That is a quick way to validate in-country Codex works end to end — but a long-lived credential on each developer's machine is a wider blast radius than you want for ongoing use.
Preferred production path: front Bedrock with a governance gateway (such as Bedrock Meter) and onboard developers there. In that model, developers never hold an AWS/Bedrock credential — they get a revocable, budget-capped gateway key, and the only AWS credential is a short-lived, auto-rotated ECS task role held by the gateway (not by any person). That is a much smaller blast radius, plus per-user budgets, usage metering, console onboarding, and instant revocation.


Challenges this setup addresses

  • Data residency — model traffic needs to stay within the India regions rather than reach an external SaaS or another geography.
  • Correct endpoint & model wiring — small configuration details (provider name, inference-profile id, API surface) determine whether calls succeed or fail with a 404 — easy to get wrong by hand.
  • Per-user credentials — each developer should have their own low-privilege identity and credential, not a shared account-wide secret.
  • Cross-platform setup — developers run macOS or Windows; installing Codex and writing the right config on each machine is repetitive and error-prone.
  • Repeatable onboarding — adding each new user (IAM user, least-privilege policy, credential, hand-off) should be a consistent, scripted sequence.
  • Safe secret handling — issued tokens and key files must be stored with restrictive permissions and kept out of version control.


How it works

The bundle is a set of cross-platform Python scripts driven by a single editable settings file ( codex.properties ). An admin provisions each user in AWS; the end user installs Codex and applies their token. Precedence for every setting is predictable:
CLI flag >  codex.properties  > interactive prompt > built-in default
The client never talks to a public AI SaaS — it is pointed at the Bedrock runtime endpoint and carries only the per-user bearer token.


Architecture

The admin provisions a per-user IAM identity and bearer token; the user's Codex client then calls the Bedrock runtime endpoint directly, which routes through the India inference profile.


The scripts (run in order)

Step 0 —  0_setup_admin_credentials.py  (Admin, once) Store admin AWS credentials in a named CLI profile and verify identity. Creates no resources.
Step 1 —  1_create_codex_user_and_token.py  (Admin, per user) Create a low-privilege IAM user, attach the least-privilege Bedrock policy, and issue a bearer token (or IAM key). Saves the secret to a restricted-permission file.
Step 2 —  2_install_codex.py  (User machine) Install the Codex CLI (and desktop app), write  ~/.codex/config.toml  and  ~/.codex/.env , and verify the CLI runs.
Step 3 —  3_apply_token.py  (User machine) Write the bearer token into the Codex environment so it authenticates to Bedrock.
Master —  install_all.py  (Both) Runs the steps in sequence ( --admin  /  --user  / all), reading  codex.properties .
Separation of roles
  • Admin (steps 0–1) runs on the administrator's machine with admin AWS credentials and produces a per-user token file to hand off securely.
  • End user (steps 2–3) runs on the developer's own machine; model, region, and provider usually stay at the validated defaults.


Authentication and access controls

Each developer authenticates to Amazon Bedrock with their own per-user credential, backed by a dedicated low-privilege IAM user. Two credential types are supported:
  • Bearer token (recommended for this setup) — an Amazon Bedrock API key issued to the user's IAM identity. Codex reads it from  ~/.codex/.env  ( AWS_BEARER_TOKEN_BEDROCK ). The file is written with restrictive (600) permissions.
  • IAM access key — a SigV4 credential used via the AWS SDK credential chain, for teams that prefer standard IAM keys.
Least-privilege IAM policy. Script 1 attaches a scoped policy to each user that allows only Bedrock invocation of the India inference profile and the underlying foundation model in  ap-south-1  /  ap-south-2 :
  •  bedrock:InvokeModel*  scoped to the India geographic inference-profile ARN and the foundation-model ARNs, gated by a  bedrock:InferenceProfileArn  condition.
  • For the bearer path,  bedrock:CallWithBearerToken  — Amazon Bedrock API key auth requires this action and it does not support ARN scoping (so it is granted on  * ). The SigV4 / IAM-key path does not need it.

Secret handling and the preferred credential model

  • Issued secrets are written to 600-permission files; the file path is printed for a secure hand-off.
  • Token/key files ( *_BEARER.txt ,  *_IAMKEY.txt ) and the local  codex.properties  are excluded from version control; delete the local secret file after hand-off.
  • The per-user bearer token here is long-lived — appropriate for validation, but for ongoing use the preferred approach is short-lived credentials with a smaller blast radius via a governance gateway (Bedrock Meter), where the only AWS credential is a short-lived, auto-rotated ECS task role and developers hold only a revocable gateway key.
  • For administrators, prefer AWS IAM Identity Center (SSO) over long-lived admin access keys.


Installation steps

Prerequisites: Python 3 and AWS CLI v2 on each machine; an admin AWS identity able to create IAM users, attach inline policies, and issue Amazon Bedrock API keys; Bedrock model access enabled for the target India model; a package installer for Codex (Homebrew on macOS, winget on Windows). On Windows, use  python  instead of  python3 .
First, clone the repository:
git clone https://github.com/tripathihsr/codex-on-bedrock.git
cd codex-on-bedrock

0. Edit  codex.properties 

One file drives every script. Copy the template and set the values you need (model, region, provider, auth type, username). Anything left blank is prompted for or defaulted.
cp codex.properties.template codex.properties
# then edit: username, auth_type, admin_profile (admin) / token_file (user)

1. Admin — configure admin AWS credentials

Stores your admin credentials in a named CLI profile and verifies identity with  sts get-caller-identity . Creates no AWS resources.
python3 0_setup_admin_credentials.py

2. Admin — create the user and issue a token

Creates the low-privilege IAM user  codex-bedrock-user-<name> , attaches the scoped Bedrock policy, and issues the credential. It prints exactly what it will create and asks for confirmation first.
# bearer token (recommended)
python3 1_create_codex_user_and_token.py --user alice --type bearer

# or an IAM access key instead
python3 1_create_codex_user_and_token.py --user alice --type iamkey
The secret is saved to a 600-permission file (path printed). Hand it to the user securely and delete the local copy afterwards; never commit it. IAM changes can take ~30s to propagate.

3. User — install Codex and write config

Installs the Codex CLI (and desktop app) and writes  ~/.codex/config.toml  and  ~/.codex/.env  resolved to the current user's home. It verifies the CLI actually runs — do not continue until that check passes.
python3 2_install_codex.py

4. User — apply the bearer token

Writes the token into the Codex environment so it authenticates to Bedrock.
python3 3_apply_token.py --token-file /path/to/codex-bedrock-user-alice_BEARER.txt
On Windows, fully restart the Codex desktop app afterwards. On macOS, open a new terminal so the environment loads.

5. Verify

Confirm the full path works. The  unset  ensures the bearer token is used rather than a leftover SDK profile.
unset AWS_PROFILE AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
codex exec --skip-git-repo-check "reply with exactly: BEDROCK OK"
# Expected: BEDROCK OK  (ignore the harmless "Model metadata not found" warning)

One-shot install (optional)

After editing  codex.properties , the master installer can run the steps for you — all of them, or just the admin or user subset — reading the settings file and stopping on the first failure with a resume hint.
python3 install_all.py            # interactive menu (pick steps)
python3 install_all.py --admin    # admin steps only (0,1)
python3 install_all.py --user     # user steps only (2,3)
python3 install_all.py --dry-run  # print the sequence without executing

Key configuration detail

The provider name is the make-or-break setting: use  model_provider = "amazon-bedrock-runtime" . The older  amazon-bedrock  value targets a different endpoint and returns a  404 model does not exist  for the India inference profile.
# ~/.codex/config.toml
model = "in.openai.gpt-5.6-terra"           # India geographic inference profile id
model_provider = "amazon-bedrock-runtime"   # NOT "amazon-bedrock"
model_reasoning_effort = "high"

[model_providers.amazon-bedrock-runtime.aws]
region = "ap-south-1"                        # ap-south-2 (Hyderabad) also valid


Summary

This bundle makes "run Codex against Amazon Bedrock in India" a repeatable, per-user setup rather than manual configuration. An admin provisions each developer's low-privilege identity and token; the developer installs Codex and applies the token; a built-in check confirms the path works.
  • Data residency — Codex points at the Bedrock runtime endpoint in India; the geographic inference profile routes within  ap-south-1  /  ap-south-2 .
  • Correct wiring — validated  config.toml  and provider settings written by the scripts, avoiding the common 404 misconfiguration.
  • Per-user access — a dedicated low-privilege IAM user and credential per developer, with a scoped Bedrock policy.
  • Cross-platform onboarding — same scripts on macOS and Windows, driven by one settings file.
  • Safe secrets — secrets written to restricted-permission files and excluded from version control.
Use this bundle to validate the in-country Bedrock path. For ongoing use — short-lived credentials with a smaller blast radius, per-user budgets, usage metering, console onboarding, and instant key revocation — pair it with a governance gateway in front of Bedrock.
Get the scripts:  github.com/tripathihsr/codex-on-bedrock 
Pair this with Bedrock-meter , a self-managed gateway for user governance:  github.com/tripathihsr/bedrock-meter 

Provided as-is for technical guidance; validate against your own security, privacy, and regulatory requirements. OpenAI Codex, Amazon Bedrock, AWS, and related marks are the property of their respective owners.
# agentic-ide# codex# amazon-bedrock
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article