DEV Community

Cover image for How to Set Up the ChatGPT Desktop App with Amazon Bedrock
AWS profile image Matheus Guimaraes
Matheus Guimaraes for AWS

Posted on Originally published at matheusguimaraes.com

How to Set Up the ChatGPT Desktop App with Amazon Bedrock

#ai #chatgpt #aws #bedrock

A while ago, I tried setting up the ChatGPT desktop app with Amazon Bedrock on another laptop and, while I eventually got it working, it wasn't without a few snags.

Fast-forward to last week, when I got a brand-new, shiny, beautiful MacBook Pro (yes, not a very humble brag! 😆) and realised I regretted not writing a blog about the setup the first time around. It would have been pretty handy to have my own instructions when I needed to do it all again. So here we are.

What I want is fairly simple: to use Codex in the desktop app while sending its model requests through Amazon Bedrock, using my AWS identity, permissions and billing.

There is an important detail to call out here. This configuration works with Codex and Work, not the regular ChatGPT experience. When the app loads with the Bedrock configuration, the ChatGPT option in the dropdown becomes unavailable and is replaced by Work. It also doesn't change the provider behind normal conversations on chatgpt.com.

ChatGPT desktop app dropdown showing Work and Codex as the only available options.

With the Bedrock configuration loaded, the desktop app offers Work and Codex but not regular ChatGPT.

Getting everything in place isn't that difficult, really. Some bits can be a little confusing, though, and I don't think the official documentation out there does a particularly good job of covering them all or explaining how the pieces fit together.

Before getting started

For this setup, you need:

  • a current version of the Codex desktop app;
  • access to an AWS account with Amazon Bedrock enabled;
  • permission to invoke the OpenAI model you want to use;
  • AWS CLI v2 because you are authenticating through AWS SSO; and
  • an AWS Region where the selected model is available.

I'm using openai.gpt-6-astra as the model. Supported models and minimum app versions can change, so it is worth checking the OpenAI Bedrock configuration guide before following the same setup.

1. Giving Bedrock its own AWS profile

I don't want Codex quietly depending on whichever AWS profile happens to be the default on my machine, so I create a named profile specifically for this setup. This keeps the configuration explicit, makes it easier to maintain and reduces the risk of a future change to the default profile breaking the Codex integration.

First, I start the AWS SSO configuration wizard with:

aws configure sso
Enter fullscreen mode Exit fullscreen mode

The wizard asks for several values:

  • an SSO session name;
  • your SSO start URL;
  • the AWS Region that hosts IAM Identity Center;
  • the AWS account and role you want to use;
  • the default AWS Region for the profile; and
  • a profile name.

If you're not familiar with it, the SSO session name can sound a little confusing. It is simply a local name for the IAM Identity Center session used to authenticate. Multiple AWS profiles can reuse the same SSO session while pointing to different accounts, roles or default Regions.

Let's call the SSO session:

amazon-sso
Enter fullscreen mode Exit fullscreen mode

And the AWS profile:

codex-bedrock
Enter fullscreen mode Exit fullscreen mode

For the default client Region, I'm going to choose a Region where the OpenAI model is available. I use us-west-2 in the examples below, but this is one of those values you shouldn't copy blindly if your AWS environment uses a different Region.

I follow the steps and, once the profile is created, I sign in with:

aws sso login --profile codex-bedrock
Enter fullscreen mode Exit fullscreen mode

This opens the browser so I can complete the login. I then check which AWS identity the new profile resolves to:

aws sts get-caller-identity --profile codex-bedrock
Enter fullscreen mode Exit fullscreen mode

If everything is working, the command returns a JSON response containing the account, user ID and ARN for the selected identity. If it cannot use the profile, you will see a credentials, profile or SSO-related error instead. A successful response confirms that the profile points where I expect it to before I involve Bedrock or Codex.

2. Checking the model is available in the right Region

Before touching the Codex configuration, you should check whether the model you want to use is available in the same Region you configured in your profile. The model I want is:

openai.gpt-6-astra
Enter fullscreen mode Exit fullscreen mode

And the Region in the codex-bedrock profile I just set up is:

us-west-2
Enter fullscreen mode Exit fullscreen mode

I could use the Amazon Bedrock console to check, or I can just run the following command from Terminal:

aws bedrock list-foundation-models \
  --by-provider OpenAI \
  --region us-west-2 \
  --profile codex-bedrock
Enter fullscreen mode Exit fullscreen mode

This shows me the OpenAI models available through my SSO profile in us-west-2, based on the permissions attached to the role I selected. I can see that openai.gpt-6-astra is available, so I'm good to proceed.

Terminal output listing GPT-6 Astra as an available OpenAI model in Amazon Bedrock.

Confirming that GPT-6 Astra is available through the SSO profile in us-west-2.

Foundation models should be available in Bedrock by default when the required permissions are in place. With third-party models, however, Bedrock may start the subscription process in the background the first time you invoke one, and that can take a few minutes. In a centrally managed AWS account, an administrator may also need to enable the model or grant the required Marketplace and Bedrock permissions.

3. Editing the Codex configuration without losing what's already there

Here is where we need to be a bit more careful. The desktop app has already populated its configuration with desktop settings, plugins and local tooling, so replacing the whole file with a minimal example would throw away configuration we want to keep.

Codex reads its local configuration from:

~/.codex/config.toml
Enter fullscreen mode Exit fullscreen mode

If the directory does not exist yet, create it with:

mkdir -p ~/.codex
Enter fullscreen mode Exit fullscreen mode

Because my config.toml already exists, I make a backup before changing anything:

cp ~/.codex/config.toml ~/.codex/config.toml.backup
Enter fullscreen mode Exit fullscreen mode

Codex loads the file named config.toml, so the .backup copy is there if I need it without being treated as the active configuration.

I then open the configuration in Kiro:

open -a "Kiro" ~/.codex/config.toml
Enter fullscreen mode Exit fullscreen mode

If you would rather stay in Terminal, nano works too, of course:

nano ~/.codex/config.toml
Enter fullscreen mode Exit fullscreen mode

The code that we need to add it the following:

model = "openai.gpt-6-astra"
model_provider = "amazon-bedrock"

[model_providers.amazon-bedrock.aws]
profile = "codex-bedrock"
region = "us-west-2"
wire_api = "responses"
Enter fullscreen mode Exit fullscreen mode

If your file already contains model or model_provider, update those values rather than adding the same keys twice.

There are three values worth checking before saving:

  • model is an exact model ID supported by the current Codex and Bedrock integration. In my case, I'm using astra but you pick what you prefer, of course;
  • profile matches the named AWS profile you created earlier; and
  • region matches the Region in which that model is available.

I choose to set the AWS profile directly in config.toml. That makes the dependency explicit and avoids relying on the desktop app to inherit environment variables from my shell, which desktop applications do not always do.

By the way, be careful where you add the snippet on config.toml because placement matters. Not because Codex requires the sections in a particular visual order, but because TOML uses section headings to determine which settings belong together.

In the configuration created by my desktop app, the file begins with a notify setting followed by the [desktop] section. I keep the existing notify line unchanged and insert the Bedrock block immediately before [desktop]:

Codex config.toml with the Amazon Bedrock settings inserted before the desktop section.

The Bedrock settings go after the existing top-level values and immediately before [desktop].

4. Restarting the desktop app

This is an easy step to overlook. After saving the file, I quit the desktop app completely and open it again. Editing config.toml while the app is running does not force the current process to reload the provider configuration.

Once the app reopens, I start a new Codex session.

5. Proving that Codex is actually using Bedrock

I don't want to treat “Codex answered me” as proof that the setup works. A successful response only proves that some provider handled the request.

To check the provider directly, I start a Codex CLI session and open:

/status
Enter fullscreen mode Exit fullscreen mode

The model provider should be:

amazon-bedrock
Enter fullscreen mode Exit fullscreen mode

I also confirm that Astra is the selected model.

Codex status showing amazon-bedrock as the model provider and GPT-6 Astra as the selected model.

The status output provides a direct check that Codex is using Amazon Bedrock.

Finally, I send a small test prompt through the desktop app. I deliberately use something that exercises Codex without involving one of my real codebases yet:

Create a small C# console application that prints the current UTC time, and explain each file you create.
Enter fullscreen mode Exit fullscreen mode

Once that completes and /status shows amazon-bedrock, I know the local Codex setup is genuinely sending its requests through Bedrock.

If it doesn't work...

Once you split the setup into AWS authentication, Bedrock model access and the local Codex configuration, most failures become much easier to narrow down. These are the checks I would make first.

aws is not found

AWS CLI is either not installed or is not available on your shell’s PATH. Install AWS CLI v2, open a new Terminal window and run aws --version again.

The SSO session has expired

Authenticate again:

aws sso login --profile codex-bedrock
Enter fullscreen mode Exit fullscreen mode

Then restart the desktop app if the current session does not recover.

The ChatGPT desktop app error shown when the AWS SSO session has expired.

An expired AWS SSO session may appear as a less obvious provider error in the desktop app.

Codex cannot find the AWS profile

Check that the profile exists:

aws configure list-profiles
Enter fullscreen mode Exit fullscreen mode

Then make sure the spelling in config.toml matches it exactly.

The model ID is rejected

Model IDs must match one of the values currently supported by the Codex and Bedrock integration. Do not assume that every model visible in the Bedrock catalog is supported by Codex, and do not shorten the model ID.

You receive AccessDeniedException

Check all three layers:

  1. the AWS profile resolves to the identity you expected;
  2. that identity has permission to invoke the model in Amazon Bedrock; and
  3. the model is available to the account in the selected Region.

On first use of a third-party model, Bedrock may still be completing its subscription process. If permissions are correct, wait a few minutes and try again. In an organisation-managed AWS account, you may need the account administrator to enable the model or update your permissions.

The desktop app still uses the previous provider

Check that you edited ~/.codex/config.toml, saved the file and completely restarted the app. If you are using environment-variable-based AWS authentication instead of a named profile, remember that the desktop app may not inherit variables exported only in Terminal; OpenAI recommends putting required desktop-app variables in ~/.codex/.env.

An unexpected Bedrock API key is being used

Codex checks AWS_BEARER_TOKEN_BEDROCK before the AWS SDK credential chain. If that variable contains an old or unintended key, it takes precedence over your named AWS profile. Remove or correct it, then restart Codex.

What actually changes?

With model_provider = "amazon-bedrock", my local Codex setup authenticates with AWS and sends model requests through Amazon Bedrock’s implementation of the Responses API. The OpenAI-hosted API is not in that request path.

Not every feature is supported

The unavailable ChatGPT option is the most immediately visible difference, but it isn't the only one. The Bedrock-backed experience does not necessarily include every feature available when Codex is backed by ChatGPT. OpenAI’s documentation lists limitations including image generation, voice transcription, the cloud plugin store, cloud configuration and policies, and cloud agents. Feature support can change, so I would check the documentation rather than treating that as a permanent list.

There is another limitation I wasn't expecting. Even with amazon-bedrock shown as the active provider, I still reached the ChatGPT desktop app's standard usage limit. In other words, using Bedrock changes where the model request goes and where that usage is billed, but it does not necessarily make the desktop experience unlimited, which is surprising, but a topic for another day.

Switching between different accounts

At this point, I have Bedrock working on the new Mac. But I have also replaced the configuration used by my personal ChatGPT-backed setup, which brings me straight to the next practical problem: how do I use both without manually editing config.toml every time?

That is what I'll cover in the second post in this series, where I'll show how I keep the two environments separate and use simple shell commands to switch between them.

Further reading

Top comments (0)