Codex CLI With Bedrock: Compatibility and Practical Options

Codex CLI is designed around the OpenAI API. AWS Bedrock is Amazon's managed model hosting service, which exposes models from Anthropic, Mistral, Amazon, and others through its own API shape. These two things are not the same, and whether Codex CLI can use a Bedrock-hosted model depends on whether a compatibility layer bridges the two API formats.

Whatever combination of coding tools and models you end up with, project context should not be trapped inside any one of them. A tool like fenbs keeps tasks, decisions and Where we left off outside the model, so switching between Codex CLI, Claude Code, or another assistant does not mean losing the work.

How Codex CLI connects to a model

Codex CLI sends requests to an API endpoint. By default, that endpoint is OpenAI's API at api.openai.com. The CLI authenticates with an API key or through codex auth, selects a model, and sends prompts in the OpenAI chat format.

Most configuration knobs, including the OPENAI_BASE_URL environment variable, let you point the CLI at a different endpoint as long as that endpoint speaks the OpenAI API format. This is how the CLI can be used with a local model proxy like Ollama. See codex cli with ollama for that setup.

What Bedrock exposes

AWS Bedrock exposes models through the Bedrock API, which is distinct from the OpenAI API. The request format, authentication method, and model identifiers are different. Sending a raw OpenAI-format request to a Bedrock endpoint will fail because the API shapes do not match.

AWS does offer an "Amazon Bedrock cross-region inference" and several model providers have their own SDKs for Bedrock. What matters for Codex CLI is whether there is a proxy or adapter layer that accepts OpenAI-format requests and translates them to Bedrock API calls.

Check the AWS Bedrock documentation and the OpenAI Codex repository↗ (opens in a new tab) for current compatibility notes. AWS adds features regularly, and the compatibility landscape may have changed since any guide was written.

Using a compatibility proxy

A compatibility proxy sits between Codex CLI and Bedrock. It accepts requests in the OpenAI format that the CLI sends, translates them to Bedrock API calls, and returns Bedrock responses in the format the CLI expects. Several open-source projects implement this proxy pattern.

With a proxy running locally or on a server, set OPENAI_BASE_URL to the proxy's address and provide whatever API credentials the proxy requires:

export OPENAI_BASE_URL=http://localhost:8080/v1
export OPENAI_API_KEY=proxy-key-if-required
codex "your task"

The quality of the result depends on how well the proxy handles the full range of requests Codex CLI makes, including tool calls and streaming responses. Test with a simple task before relying on the setup for longer work.

Native clients for Bedrock models

If your goal is to use a specific model available on Bedrock, check whether that model has its own native CLI or IDE tool. Anthropic's Claude models, for example, are available on Bedrock but also have their own clients, including Claude Code, which connects directly to the Anthropic API.

Using the native client for a model is usually more reliable than routing through a proxy. The native client understands the model's specific capabilities, system prompt format, and tool calling conventions. A proxy adds a translation step that can drop features or behave differently from the vendor's own implementation.

The codex subagents guide covers patterns for splitting work across multiple agents; those same patterns apply when your orchestration layer uses different tools for different models.

Verify before committing to a setup

Before building a workflow around Codex CLI plus Bedrock, verify three things: the proxy or adapter works with the specific Bedrock model you need, tool calls work correctly (not just plain text responses), and streaming responses arrive in the right format for interactive sessions.

A short verification task that uses file edits and a command is a reasonable test: "Create a file called test.txt with the content 'hello' and then read it back." If that works end to end, the core agent loop is functioning.

Keep project context portable

Whether you use Codex CLI with OpenAI directly, through a Bedrock proxy, or alongside a native Bedrock client, the project context should not be locked inside any one tool. Decisions, task plans, and progress notes in a shared record stay useful regardless of which coding tool is active.

When you switch between Codex CLI and another assistant, the new session reads the same project state from fenbs. Rules apply consistently, and Where we left off reflects what the previous session did, regardless of which tool ran it.

How to do this with fenbs

1. Create a free account and add your project with tasks, rules, and current status.
2. Connect whichever coding tools you are using from Integrations: Codex CLI, Claude Code, Cursor, and others connect over MCP.
3. Write standing rules as Decisions and rules in fenbs: which model or tool to use for which type of task, any provider-specific limits to respect.
4. When you switch from one tool to another, ask the new session to read the project context from fenbs before it starts work.
5. Before each session ends, save Where we left off so the picture stays current for the next tool you use.