DEV Community: Matheus Guimaraes

Switching Between Your Personal ChatGPT Account and Amazon Bedrock

Matheus Guimaraes — Thu, 01 Oct 2026 10:33:52 +0000

In the previous post in this series, I walked through how to configure the ChatGPT desktop app to use OpenAI models through Amazon Bedrock.

That works great if Bedrock is the only environment you want to use. But what if you want to use both your personal ChatGPT account and Amazon Bedrock?

That's when it gets awkward.

I found that out the hard way after setting up my Bedrock configuration, because my intention was always to keep using my personal ChatGPT account as well and switch between the two on demand to help me manage my token limits.

I also didn't want two completely separate Codex environments. I wanted to keep the same local conversations, files and working state, and simply change which provider was handling the model requests.

So I built a small account switcher to make that easier.

If you just want the solution, you can grab it here:

techwithmatheus/codex-account-switcher

It includes an installer, uninstaller and two simple commands:

codex-personal
codex-bedrock

If you'd rather understand what it's doing before installing it, keep reading. That's what the rest of this post is about.

The problem with simply switching accounts

When you're using the normal ChatGPT experience, switching accounts is something you generally think about at the application level.

Bedrock is different.

In the setup from the previous post, Codex is configured locally with something like:

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

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

That tells Codex to send model requests through Amazon Bedrock using the AWS profile and Region you've configured.

So Bedrock isn't another ChatGPT account that can simply appear in the normal account switcher. It's a different model-provider configuration.

My first thought was therefore to maintain two separate Codex environments: one for my personal account and another for Bedrock.

That would work, but there's a downside.

Why I decided not to separate the whole Codex environment

Codex stores its local state under:

~/.codex

And there's considerably more in there than config.toml.

On my machine, that directory contains authentication state, sessions, thread history, memories, plugins, skills, model caches, trusted-project settings and several local databases used by the desktop experience.

If I gave my personal and Bedrock setups completely separate Codex homes, I would also be separating much of that useful state.

That wasn't really what I wanted.

My use case was closer to this:

same Codex workspace
same conversations
same local state
different model provider

So I tried something simpler.

I completely quit the ChatGPT app, removed only the Bedrock-specific configuration from ~/.codex/config.toml, and launched it again.

The desktop app returned to my personal ChatGPT-backed Codex environment.

More importantly, a test conversation that I had originally created while using Bedrock was still there. It contained a small .NET console application, and I could still open the generated files in the desktop preview.

I then quit the app, restored the Bedrock configuration and launched it again.

The same conversation and files were still there.

So that's the model we'll use here: keep the Codex state shared and switch only the part of the configuration that selects Amazon Bedrock.

There was another nice surprise when I later tested the full uninstall flow. When I switched back to my personal ChatGPT environment, I expected to have to sign in again. I didn't.

My existing personal authentication was still part of the shared Codex state. Bedrock had changed which provider handled the model requests, but it hadn't logged me out of my personal ChatGPT account.

This is behaviour I've personally verified on macOS with the ChatGPT desktop app. I haven't tested every piece of desktop state, so I'm deliberately not claiming that every feature behaves identically across providers.

Back up your configuration first

Before changing anything, make a backup of your existing Codex configuration.

I like using the date and time in the filename so old backups remain meaningful:

cp ~/.codex/config.toml ~/.codex/config.toml.backup.$(date +%F-%H%M%S)

I'd also back up your .zshrc, since the installer will add a small block to it:

cp ~/.zshrc ~/.zshrc.backup.$(date +%F-%H%M%S)

You don't need to copy the whole ~/.codex directory for this. The switcher doesn't touch your sessions, memories, authentication databases or other Codex state.

We'll also make the switcher maintain a rolling safety backup before it modifies config.toml, but that's different from this manual checkpoint.

Install the switcher

I've put the maintained version of the switcher on GitHub:

techwithmatheus/codex-account-switcher

Clone the repository:

git clone https://github.com/techwithmatheus/codex-account-switcher.git
cd codex-account-switcher

Then run the installer:

bash install.sh

I'm deliberately using bash install.sh rather than ./install.sh. That means you don't have to change executable permissions on the downloaded script first.

The installer puts the switcher under:

~/.config/codex-switcher/
├── codex-switcher.zsh
└── config

and adds a small marked block to ~/.zshrc so zsh loads it whenever you open a shell.

The actual switching code lives in its own file rather than dumping a large shell function directly into your .zshrc. That makes it much easier to inspect, maintain or replace later.

After installation, reload your shell:

source ~/.zshrc

Configure your Bedrock settings

The switcher's Bedrock-specific settings live in:

~/.config/codex-switcher/config

The defaults used throughout this series are:

CODEX_BEDROCK_MODEL="openai.gpt-6-astra"
CODEX_BEDROCK_PROFILE="codex-bedrock"
CODEX_BEDROCK_REGION="us-west-2"

If you used different values when configuring Bedrock, update them there.

For example, if your AWS profile is called work-bedrock:

CODEX_BEDROCK_PROFILE="work-bedrock"

The model and Region should likewise match the Bedrock setup you've already verified.

What if Bedrock is already configured?

If you've just followed the first article, you may already have Amazon Bedrock active when you install the switcher.

The installer handles that case too.

If it finds the standard Bedrock configuration already active, it shows the values it discovered:

Existing Amazon Bedrock configuration found.

Model:       openai.gpt-6-astra
AWS profile: codex-bedrock
Region:      us-west-2

These provider settings will be adopted by the switcher and will not be replaced.

Continue? [Y/n]

It then adopts the existing settings rather than creating a duplicate Bedrock provider configuration.

If you're starting from your normal personal ChatGPT environment instead, your current Codex configuration is left alone and the switcher starts from there.

What the switcher actually changes

When Bedrock is active, the tool owns one clearly marked block inside ~/.codex/config.toml:

# >>> codex-bedrock-switcher >>>
model = "openai.gpt-6-astra"
model_provider = "amazon-bedrock"

[model_providers.amazon-bedrock.aws]
profile = "codex-bedrock"
region = "us-west-2"
wire_api = "responses"
# <<< codex-bedrock-switcher <<<

The values come from the separate switcher configuration file we just looked at.

Everything outside those markers belongs to Codex, or to you, and the switcher leaves it alone.

That's important because the desktop-generated config.toml can contain much more than provider configuration: desktop preferences, plugins, MCP servers, trusted projects and other settings may all live in the same file.

Replacing the entire file whenever you switch would be unnecessarily risky.

Before each automated change, the current configuration is also copied to:

~/.codex/config.toml.switcher-backup

That's a rolling safety backup. It contains the state immediately before the most recent switch and is intentionally overwritten on later switches.

Switch to Amazon Bedrock

Once everything is installed and your configuration looks right, run:

codex-bedrock

The switcher will:

make a safety backup of your current config.toml;
add the managed Bedrock block;
launch the ChatGPT desktop app.

The rest of your Codex state remains where it was.

Switch back to your personal ChatGPT account

To go back:

codex-personal

The switcher removes only the Bedrock block it owns.

It does not insert some handcrafted OpenAI provider configuration in its place.

That's deliberate.

During testing, removing the Bedrock override was enough for the desktop app to return naturally to my personal ChatGPT-backed environment using its existing authentication and defaults.

So rather than trying to reproduce configuration that Codex already knows how to manage, the switcher simply gets out of the way.

In my tests, I didn't need to authenticate again either. My personal ChatGPT login was still available because we had never replaced or deleted the shared Codex authentication state.

What if ChatGPT is still running?

I didn't want the switcher modifying config.toml underneath a running desktop application.

So if ChatGPT is still open when you run either command, you'll get:

Answer y and the switcher asks macOS to quit ChatGPT normally, waits until the application has exited, performs the switch and launches it again.

Anything else cancels the operation.

The important part here is that it uses the application's normal quit behaviour rather than abruptly killing the process.

Skip the question

If you already know you want it to close ChatGPT, use -f or --force:

codex-bedrock -f

or:

codex-personal --force

That closes the app automatically and continues with the switch.

Do the conversations actually carry across?

This was the part I cared about most.

I created a test conversation while Codex was configured through Amazon Bedrock. In that conversation I had it create a small .NET console application that displayed the date.

I then switched the desktop app back to my personal ChatGPT environment.

The conversation was still in the app. I could open it and inspect the generated files in the preview panel.

I switched back to Bedrock and it remained there as well.

So at least for the local conversation and generated-file workflow I tested, this gives me what I wanted:

Personal ChatGPT
        │
        ▼
same local Codex workspace
        ▲
        │
Amazon Bedrock

The conversations aren't being recreated each time you switch providers. We're keeping the same local Codex state and changing which provider handles model requests.

That doesn't mean the underlying services suddenly share billing, authentication or infrastructure. They don't.

What we're preserving is the local working environment around them.

What if I already use another custom provider?

Codex can contain definitions for multiple model providers in the same configuration, and the switcher leaves unrelated provider definitions alone.

However, this utility is not intended to be a universal provider manager.

It specifically manages:

Personal ChatGPT / OpenAI
            ⇅
       Amazon Bedrock

If you also use another custom provider, you can continue switching to it using whatever method you already use.

There is one important behaviour to understand.

Running:

codex-bedrock

deliberately makes Bedrock active.

Running:

codex-personal

removes the Bedrock override and returns Codex to its normal personal ChatGPT/OpenAI behaviour.

It does not remember that you previously happened to be using some third provider and restore that provider instead.

Because of that, if the automatic installer finds an unrelated custom provider currently active, it stops instead of trying to guess what your configuration means.

You can still install the switcher manually alongside a more complex provider setup. The repository README contains the manual installation steps.

And if there's another provider you'd like the switcher to support directly, feel free to open an issue. Pull requests are welcome too.

Uninstalling the switcher

Run:

bash uninstall.sh

The slightly interesting part of uninstalling isn't removing the shell files. It's deciding which provider should remain configured afterward.

The uninstaller therefore asks:

Removing the switcher means ChatGPT will be left configured for a single provider.

Which provider would you like to keep?

1) Personal ChatGPT / OpenAI
2) Amazon Bedrock
3) Cancel

If you choose Personal ChatGPT / OpenAI, the switcher-managed Bedrock block is removed.

If you choose Amazon Bedrock, the Bedrock settings stay in config.toml, but the switcher's marker comments are removed. What remains is simply a normal Codex Bedrock configuration like the one from the first article.

And if you choose Cancel, nothing changes.

One thing the uninstaller deliberately does not do is restore some snapshot of config.toml from the day you installed the switcher.

Your Codex configuration may have legitimately evolved since then with new desktop settings, project permissions, plugins or other configuration. Restoring an old snapshot could wipe changes that have nothing to do with this tool.

Why `~/.config`?

You'll notice the utility lives under:

~/.config/codex-switcher/

rather than inside the Codex directory itself.

~/.config is a common convention in Unix-style command-line environments for user-specific configuration. macOS doesn't guarantee that the directory already exists, so the installer creates it when necessary.

I also deliberately keep the utility outside ~/.codex.

The switcher isn't part of Codex. It's a small shell tool that modifies one well-defined part of Codex configuration, and keeping its own code and settings separate makes that boundary clearer.

A provider switch, not a second account system

There's one distinction worth finishing on.

This doesn't turn Amazon Bedrock into another ChatGPT account.

Your personal ChatGPT environment and your Bedrock environment are still separate in the ways that matter: authentication, billing and the infrastructure processing the model requests are different.

What we've done is take advantage of the fact that Codex's local workspace doesn't need to be discarded just because the active model provider changes.

For my workflow, that's considerably more useful than maintaining two completely isolated desktop environments.

I can keep working in the same Codex setup and choose whether the next part of that work should run through my personal ChatGPT environment or through Amazon Bedrock.

Until the desktop app has a first-class way to handle that scenario, two shell commands are doing the job nicely.

Source code

The switcher, installer and uninstaller used in this article are available here:

techwithmatheus/codex-account-switcher

The repository also contains manual installation instructions, configuration details and notes for people already using other custom providers.

If Codex changes in a way that affects the switching mechanism, I'll maintain the implementation there rather than expecting readers to keep copying an old shell snippet.

How to Set Up the ChatGPT Desktop App with Amazon Bedrock

Matheus Guimaraes — Sun, 20 Sep 2026 06:40:10 +0000

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.

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

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

And the AWS profile:

codex-bedrock

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

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

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

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

us-west-2

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

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.

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

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

mkdir -p ~/.codex

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

cp ~/.codex/config.toml ~/.codex/config.toml.backup

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

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

nano ~/.codex/config.toml

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"

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]:

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

The model provider should be:

amazon-bedrock

I also confirm that Astra is 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.

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

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

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

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:

the AWS profile resolves to the identity you expected;
that identity has permission to invoke the model in Amazon Bedrock; and
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.

AI in Games: Are We Drawing the Line in the Wrong Place?

Matheus Guimaraes — Wed, 02 Sep 2026 14:10:01 +0000

The games industry is going through an uncomfortable transition. Studios see the productivity gains AI may offer, while many players see almost any use of it as inherently bad. As a lifelong gamer who started his career as a game developer, I see that divide from both sides.

I understand the reaction. People are worried about artists losing work, creative jobs being devalued and models being trained on work without permission. Those concerns certainly deserve careful consideration, but I also think the conversation has become far too binary with outright rejection often treated as the only acceptable position.

When any use becomes unacceptable

The example that crystallised this for me was Clair Obscur: Expedition 33. The Indie Game Awards withdrew its Game of the Year and Debut Game awards after it emerged that generative AI had been used during production. The material appears to have been placeholder artwork that accidentally shipped and was later patched out.

There is a disclosure issue. The awards had a clear rule, and the submission reportedly stated that no generative AI had been used so, ok, I understand it from the perspective of enforcing that rule.

What I disagree with is the rule itself. Declaring a game ineligible because generative AI touched any part of production, regardless of how it was used, feels very extreme and, dare I say, very naive and counterproductive to me. It turns “AI was involved” into the entire judgement and ignores context, scale and impact.

We have seen this pattern before

When Disney blended computer-generated environments with hand-drawn characters in Beauty and the Beast, audiences marvelled. CGI transformed visual effects, and computer animation became an art form of its own. We did not judge those works by how many people might have recreated every frame by hand. In fact, Toy Story, released in 1995 as the first fully computer-animated feature film, continues to be celebrated today.

To me, AI is just another step in that long history of automation. Game development already depends on IDEs, automated testing, procedural generation, motion capture, physics engines and infrastructure that scales itself. All allow teams to do more. If replacing manual effort is the line we object to, where does that line begin?

That is not to say that every use of AI is ethical, of course. Replacing an actor’s performance without consent is not the same as generating an environmental texture. Eliminating a creative team is not the same as helping one automate repetitive work. Training data, consent, attribution, disclosure and the treatment of workers matter.

That is why I find blanket rejection, at the very least, unhelpful. It removes the nuance needed to tell responsible use from exploitative use.

Judge the outcome, and ask better questions

As a gamer, I care most about the game: Is it good? Is it original? Does it move me?

If we want to examine how it was made then we should go deeper than just “AI was used.” What was it used for? Did it replace credited work? Was source material used with permission? Did the studio mislead anyone? Did the tool help creators realise their vision, or flatten it?

I know this is a topic that probably deserves a whole post in itself, but I also feel similarly about AI-generated art.

Art communicates, provokes or makes us feel.

The creation process can affect how we value a work. I personally struggle to appreciate works created by simply throwing paint at a canvas, for example, but my reaction to that process does not necessarily mean the result isn’t art. Similarly, I do not believe that using a prompt automatically prevents the result from being art, any more than using a camera, graphics tablet, image editor, particle system or CGI package does.

My bet is that AI will become another ordinary part of how games are made and the current backlash is just a transitional state of mind while society works out the boundaries of a disruptive technology and adjusts to a new world.

We should absolutely shape those boundaries, but I hope we shape them around consent, transparency and harm, not fear of the technology itself.

Of course, that's just my perspective, not a universal answer. Where would you draw the line? Which uses of AI in game development do you consider acceptable, and which do you not? I would genuinely like to hear how players and developers see it.

Agent Creation vs. Agent Engineering

Matheus Guimaraes — Tue, 18 Aug 2026 16:36:11 +0000

Recently, I was talking to a friend who, much like the rest of the world, has started using AI extensively at work to create agents even though she's not a software developer or from a technical background.

She has been experimenting with Claude a lot, building useful workflows for herself and her team, and getting increasingly excited about what these systems can do.

At some point, our conversation moved onto the work I've been doing around agentic systems: agent architectures, context engineering, memory, orchestration, sub-agents and frameworks such as Strands Agents.

And her reaction was:

Why do you need all of that? I'm already creating agents.

"Great question", I thought to myself.

And what made it particularly interesting was that I'd heard almost the same question from the opposite direction.

After giving a talk about agentic architecture and building harnesses with Strands Agents SDK, a junior developer came up to me and asked:

What's the point of all of this? Why can't we just use Claude for everything?

Two people approaching the subject from completely different directions had arrived at the same question.

And I think that question exposes something important about where we are with agents today. We are using the same word "agent" to describe two very different activities with very different use cases.

The way I see it, there is a big difference between creating agents and engineering agents.

Agent Creation vs. Agent Engineering

Applications such as Claude, ChatGPT, Amazon Quick and others increasingly allow people to create surprisingly sophisticated agentic workflows without building the underlying infrastructure themselves.

There is still a learning curve, though. You need to provide instructions and give the system knowledge and context in a way that produces results that are within expectation (and, hopefully, without hallucinations!). You may also need to learn about tools, set up integrations, schedule work or even create subagents so multiple pieces of functionality can work together.

From the user's perspective, they have created an agent. And indeed they have! But when a software engineer looks at the same system... they see something different.

They see an application providing a highly abstracted, opinionated agent runtime operating as a black box. You have little control over how execution happens, how context is assembled and maintained, how the system scales, or even where memory lives, among other architectural concerns.

As an application user, you are creating an agent inside somebody else's agentic architecture.

And that's not a problem. In fact, this could be exactly what you need!

Developers and software architects make trade-offs between abstraction and control all the time. We don't choose the lowest-level technology simply because it gives us the most control; we use abstractions because they remove decisions we don't want to make and complexity we don't need to own.

The same principle applies here. If Claude gives you everything you need to create an agent, why wouldn't you use it?

As usual with system design, the important thing is understanding the trade-offs. The abstraction works because somebody else has made a set of architectural decisions for you. If those decisions suit your requirements, then awesome. If they don't, you may need to take ownership of some of them yourself.

That's where I find the distinction between Agent Creation and Agent Engineering useful.

For me, three things make that distinction particularly clear.

Is the agent a feature or a component?

This is perhaps my favourite way of thinking about the distinction.

Let's say I create an agent in Claude to research holidays for me. It knows my preferences, researches destinations, compares options and perhaps uses tools to build an itinerary. It could be incredibly sophisticated... but Claude is still the application. I go to Claude, interact through Claude's interface and rely on Claude's infrastructure to make everything work.

My agent is a feature of an application I'm using.

Now imagine I want to offer that same experience through my own travel website. A customer comes to my application and asks for a holiday; somewhere behind the scenes an agent researches flights and hotels, applies their preferences, interacts with booking systems and returns the result.

The capability sounds almost identical, but architecturally something fundamental has changed. The agent is now a component of a system I'm building.

Suddenly I need to decide where it runs, how my application communicates with it, how it scales, how it authenticates against other systems, what happens when it fails, how it fits into traditional application flows, and how I observe what it's doing. The AI is no longer the destination; it's now part of the system I'm responsible for.

That's very clearly Agent Engineering.

The point is really about ownership. If an agent is a feature of Claude or another application, you're limited, quite deliberately, to what that application allows you to do. If your requirements fit inside those boundaries, great. When they don't... you need another abstraction.

Do you need control over the economics?

Another reason you might choose to engineer the agent is cost.

There is a lot of conversation right now about just how many tokens agentic systems can consume, particularly as we build long-running workflows with large context windows, tool calls and multiple agents.

Moving from Agent Creation to Agent Engineering doesn't automatically make any of this cheaper, by the way. Engineering has its own cost, and it would be rather ironic to spend £100,000 in developer time to save £500 in tokens.

What engineering gives you is control.

If you own the harness around your agents, architectural decisions become available that simply aren't exposed when you're operating inside somebody else's application.

You can decide that one task doesn't need the full conversation history, cache an expensive result, retrieve memory only when it's relevant, summarize context between steps, or route simpler tasks to cheaper models.

You can start treating context and tokens as resources that you deliberately engineer.

There's a much larger conversation here around context engineering, but that's a story for another post. For now, the important point is that the abstraction determines which levers are available to you.

If you don't need those levers, there's little value in taking responsibility for them. If the economics of your system mean you do, Agent Engineering gives you that control.

Do you need to own where your data goes?

Then there is a question that tends to become important very quickly in enterprise environments: where does everything actually live?

When I create an agent inside an application, I'm accepting that application's architecture and its mechanisms for handling context, state, memory, integrations and data. Again, that may be completely acceptable.

But what if particular data cannot leave a certain environment? What if I need to know exactly where long-term memory is persisted, control which model receives which information, maintain my own audit trail, or guarantee that certain data never crosses a particular boundary?

Now the black box really matters.

This is partly a compliance question, partly a data ownership question and, yes, partly a vendor lock-in question. The more behaviour, knowledge and state I build around one application's abstractions, the more dependent I become on that platform's capabilities and constraints.

But vendor lock-in isn't, by itself, a reason to engineer everything from scratch. We accept varying degrees of lock-in throughout modern software architecture because managed abstractions can provide enormous value.

The question is simply whether that trade-off is acceptable for the requirements in front of you.

So... Can't We Just Use Claude For Everything?

A useful spreadsheet can eventually become an application, but that doesn't mean the spreadsheet was a mistake. It may have been exactly the right abstraction for the problem at the time, and it may even have helped us understand the problem well enough to know what was worth engineering later.

I think Agent Creation and Agent Engineering should be seen in much the same way: not as levels on a maturity ladder, and certainly not as a journey where every agent should eventually become an engineered one, but as different architectural choices about how much of the underlying system we need to own. We might happily create an agent inside Claude for one task while engineering another from the ground up, perhaps even within the same system.

Sometimes an agent created inside Claude, ChatGPT, Amazon Quick or another application will remain there because it does everything we need. Sometimes our requirements will mean taking ownership of the architecture ourselves and we'll find ourselves reaching for Strands Agents SDK or another agent harness.

And perhaps the next time someone asks me, "Why can't we just use Claude for everything?", my answer will simply be...

You can! For as long as its decisions are compatible with yours.**

Understanding Async Programming

Matheus Guimaraes — Mon, 17 Aug 2026 16:01:25 +0000

Async programming, short for asynchronous programming, is one of those concepts that might sound intimidating at first but becomes surprisingly intuitive once you understand the problem it is trying to solve.

And that problem is mostly waiting.

Modern applications spend a lot of time waiting for things to happen. They wait for APIs to respond, databases to return queries, files to be read or written, and data to travel across a network. Async programming gives us a way to avoid blocking while that happens, allowing other useful work to make progress instead.

In this post, I’ll cover the basic concepts behind async programming rather than focusing on a particular language. The exact implementation differs between languages and runtimes, but the underlying ideas are largely the same. So if you’re new to async, or have used async and await without ever being completely sure what they’re doing, this is a good place to start.

What is Async Programming?

At its core, async programming allows your program to start an operation that may take some time and avoid blocking while it waits for that operation to complete.

This contrasts with synchronous programming, where execution waits for an operation to finish before continuing past that point.

Imagine you’re making an API call, a very common task in modern applications. Your application sends a request across the network and then has to wait for a response. Even if that response takes only a fraction of a second, that's a long time in computer terms.

The important thing is that your application isn't necessarily doing useful computation during all that time. A lot of it is simply waiting for something external to happen.

This is where async programming shines. Rather than blocking an execution resource while waiting for the API call to complete, asynchronous execution can allow other work to make progress and then continue the original operation when its result becomes available.

Async Doesn't Necessarily Mean Faster

One of the most common misconceptions about async programming is that it's about improving performance. A lot of people think that using async makes their code run faster. However...

Async does not necessarily make the operation itself any faster.

Your API call might take exactly the same amount of time to complete whether you call it synchronously or asynchronously. What async changes is what your application can do while it waits. Instead of being blocked by that wait, it can potentially make progress on other work.

When is Async Programming Useful?

There are three main benefits to using async programming:

Improved throughput: Because your application doesn't have to block on one operation before making progress on other work, it can often handle more work over the same period of time. This is particularly valuable in applications such as web servers that may be handling many requests concurrently.
Better resource utilization: Waiting for I/O doesn't necessarily require a thread to sit blocked until the operation completes. With asynchronous I/O, execution resources can potentially be used for other work while the application waits for the database, network, filesystem or another external resource.
Better responsiveness: Async programming can also help applications remain responsive while longer-running operations are taking place. In a user interface, for example, you generally don't want the entire application to freeze while it waits for a network request or file operation to complete.

The common thread between all three is the same: making better use of time that would otherwise be spent waiting.

Sync vs. Async: When to Use Each

Async programming sounds great, but that doesn't mean everything should be asynchronous.

The distinction becomes clearer when we think about I/O-bound and CPU-bound work.

I/O-bound operations spend a significant amount of their time waiting for something outside the CPU: network requests, database calls, file operations and similar tasks. These are often excellent candidates for async programming because there is useful time to reclaim while the application waits.

CPU-bound operations are different. If you're performing a heavy calculation, for example, the CPU is actively doing the work rather than waiting for something else to happen. Making that code asynchronous doesn't suddenly make the computation faster.

CPU-bound work may instead benefit from parallelism, where computation is divided so that multiple pieces of work can execute at the same time, potentially across multiple CPU cores.

Async programming can also introduce additional complexity and some runtime overhead, so there's little benefit in making code asynchronous simply for the sake of it. It is most useful when your application would otherwise spend meaningful time blocked waiting for I/O.

Async Isn't the Same as Parallelism

The distinction between async and parallelism is an important one. Async is primarily about allowing other work to make progress while something is waiting. Parallelism is about performing multiple pieces of work at the same time.

And async doesn't necessarily mean multithreaded either. Different languages and runtimes implement asynchronous execution in different ways, so you shouldn't assume that an async operation means another thread is somewhere doing the work.

This is why async can provide concurrency without necessarily providing parallelism: multiple operations can make progress over the same period of time without their code actually executing at the exact same moment.

How Does Async Work in Code?

The exact mechanics vary between programming languages, but many modern languages provide the familiar async and await keywords to make asynchronous code easier to write and reason about.

At a conceptual level, async identifies code that participates in asynchronous execution, while await marks a point where that code depends on the result of an asynchronous operation.

If that result is already available, execution may simply continue. If it isn't, the function can yield rather than blocking there, allowing other work to make progress. Once the awaited operation completes, execution can continue from that point.

You can think of await as saying: "I need the result of this operation before I can continue from here, but there's no reason to block everything else while I'm waiting for it."

The precise details of what happens underneath, whether that involves an event loop, tasks, promises, futures, state machines or something else, depend on the language and runtime. But you don't need to understand all of those implementation details to understand the basic async mental model.

Ready to Dive Deeper?

If async still feels a little abstract, I also explain the same ideas visually in the companion video below. Sometimes seeing the synchronous and asynchronous flows side by side is what finally makes the concept click.

Running Kiro Crew in Docker on Windows

Matheus Guimaraes — Wed, 12 Aug 2026 20:12:47 +0000

I've been playing with Kiro Crew recently, and when I went to get it running on my Windows machine I had a decision to make.

Kiro Crew doesn't currently have a Windows desktop app. You can still run it natively on Windows, but the documented route involves installing and running the Gateway from source.

But then, while looking through the Kiro Crew GitHub repository, I noticed another option that immediately caught my attention: there's an official Docker image!

Docker is already a familiar part of the development workflow for many of us, and a container felt like a nice, clean way to get Kiro Crew running without installing it from source.

So that's the route I took.

It worked, but along the way I ran into an interesting security detail that made the setup slightly less straightforward than simply running a container.

And, as it turns out, that's actually a good thing.

What we're going to do

By the end of this post, we'll have Kiro Crew running in Docker on Windows, with its agent sandbox enabled and without giving the container more privileges than it actually needs.

I'm using Docker Desktop with WSL 2, so you'll want to have those installed before following along.

You can check your WSL installation with:

wsl --version

With that out of the way, let's get Kiro Crew running.

Starting with the official container image

The Kiro Crew team publishes a public container image, so we don't need to build anything ourselves or even authenticate with a container registry. Nice and easy.

Before doing anything else, I created a directory to keep the files for this setup together:

mkdir kiro-crew
cd kiro-crew

Now, at first glance, running Kiro Crew looks like it should be as simple as starting the official image.

And technically, the Gateway itself will run.

But there's another security boundary inside that container that we need to understand before we can start it properly.

Wait... a sandbox inside a container?

This was the interesting part for me.

We're already putting Kiro Crew inside a Docker container, which gives us an isolation boundary between Kiro Crew and our Windows host.

But Kiro Crew adds another boundary of its own.

Agent commands aren't simply executed with access to everything available to the main Kiro Crew process. On Linux, Kiro Crew creates an internal user-namespace sandbox for those commands.

Conceptually, our setup looks something like this:

Windows
└── Docker container
    └── Kiro Crew
        └── Agent sandbox

Why sandbox an agent that's already inside a container?

Because the two boundaries are protecting different things.

The container isolates Kiro Crew from our host. The inner sandbox isolates agent commands from sensitive state available to Kiro Crew itself.

For example, Kiro Crew's sandbox hides credential directories such as ~/.aws and ~/.ssh from agent subprocesses by bind-mounting empty directories over them. So if an agent-executed command tries to access one of those directories, it simply sees an empty directory rather than our AWS credentials or SSH keys.

That means the Gateway can have the credentials it needs to do its job without automatically making those credentials readable by commands executed by an agent.

That's a pretty important distinction when we're giving an AI agent the ability to execute commands.

Where Docker gets in the way

There's one complication.

To create that inner sandbox, Kiro Crew needs Linux system calls including:

unshare(CLONE_NEWUSER)
unshare(CLONE_NEWNS)

Docker's default seccomp security policy blocks those operations.

So if the Kiro Crew container can't create its inner sandbox, it doesn't quietly shrug its shoulders and run agent commands without one.

It fails closed, meaning that when the security mechanism can't be established, access is denied rather than silently falling back to a less secure mode.

The Gateway and dashboard can still run, but agent command execution remains disabled.

I actually really like this design! What initially looks like an extra hurdle in getting the container running is Kiro Crew refusing to silently weaken its security model.

So how do we fix it?

The tempting solution and the better solution

There are a few ways we could approach this.

One option is to simply tell Kiro Crew that we accept running agent commands without the inner sandbox. Kiro Crew provides an environment variable for exactly that:

KIROCREW_ALLOW_UNSANDBOXED=1

We could pass that into our container and Kiro Crew would allow agent execution, leaving Docker itself as our only isolation boundary.

We could also reach for the rather large hammer:

--privileged

That would make the sandbox work, but it does so by granting the container extremely broad privileges and removing many of Docker's normal isolation restrictions.

That's a much bigger security concession than we actually need.

What we really want is much narrower:

Allow the operations Kiro Crew needs to create its sandbox while keeping the rest of Docker's security restrictions in place.

And this is another nice detail about the Kiro Crew implementation: the team already provides a seccomp profile specifically for this!

So we don't have to create one ourselves.

Downloading the Kiro Crew seccomp profile

From the kiro-crew directory we created earlier, download the official Kiro Crew seccomp profile:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o kirocrew-seccomp.json

You should now have:

kiro-crew/
└── kirocrew-seccomp.json

Having trouble downloading it from WSL?

I happened to be dealing with a DNS issue in my WSL environment when I did this, so curl couldn't resolve GitHub. If you happen to run into the same thing, there's nothing special about downloading the file through curl: you can download kirocrew-seccomp.json directly from the Kiro Crew GitHub repository in your browser and place it in this directory manually, which is what I did.

Now we can start the container using that profile.

Running Kiro Crew

Run:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  --security-opt seccomp=kirocrew-seccomp.json \
  ghcr.io/kirodotdev/kirocrew:stable

There are a couple of things worth noticing here.

We're only publishing port 5476 on the host's loopback interface, so the dashboard isn't being exposed to the rest of our network.

We're also creating a named Docker volume:

kirocrew-home

Kiro Crew keeps its persistent state under /home/kirocrew, including its configuration and Kiro CLI credentials. That means our state can survive replacing or upgrading the container.

And, most importantly for what we've just discussed, we're passing the Kiro Crew seccomp profile with:

--security-opt seccomp=kirocrew-seccomp.json

The container can now create the inner namespace sandbox while Docker's other default security restrictions remain in place.

Let's open it

At this point I did what I imagine most developers would do.

I opened:

http://localhost:5476

And instead of the Kiro Crew dashboard, I was greeted by a message telling me I was missing a token.

Another security measure!

Simply being able to reach port 5476 isn't enough to get access to the dashboard. Kiro Crew also requires a bearer token, so someone who can reach the Gateway still needs to authenticate before they can use it.

So, there's one more part of the setup we need to do.

Actually, two.

Authenticating Kiro CLI

Kiro Crew's agent runtime uses kiro-cli, so first we need to authenticate the CLI running inside our container.

We can do that without opening an interactive shell ourselves:

docker exec -it kirocrew kiro-cli login

Follow the authentication flow and log in with the identity you use for Kiro.

Once authentication succeeds, those credentials are stored in the kirocrew-home volume we created earlier, so they survive container upgrades.

But that authenticates the agent runtime.

We still need access to the dashboard.

Getting our dashboard token

Every request to the Kiro Crew dashboard requires a token.

We can mint a temporary login link from the running container:

docker exec kirocrew kirocrew token --ttl 2h

Kiro Crew will print a URL containing the token.

It will look roughly like:

http://localhost:5476/?token=...

Open that URL in your browser and...

We're in!

And with that, we have Kiro Crew running nicely inside Docker on Windows, without having to build it from source and without unnecessarily weakening either of its isolation boundaries.

Now I just need someone to explain why the Solarized theme is green instead of yellow. 😄

DEV Community: Matheus Guimaraes

Switching Between Your Personal ChatGPT Account and Amazon Bedrock

The problem with simply switching accounts

Why I decided not to separate the whole Codex environment

Back up your configuration first

Install the switcher

Configure your Bedrock settings

What if Bedrock is already configured?

What the switcher actually changes

Switch to Amazon Bedrock

Switch back to your personal ChatGPT account

What if ChatGPT is still running?

Skip the question

Do the conversations actually carry across?

What if I already use another custom provider?

Uninstalling the switcher

Why ~/.config?

A provider switch, not a second account system

Source code

How to Set Up the ChatGPT Desktop App with Amazon Bedrock

Before getting started

1. Giving Bedrock its own AWS profile

2. Checking the model is available in the right Region

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

4. Restarting the desktop app

5. Proving that Codex is actually using Bedrock

If it doesn't work...

aws is not found

The SSO session has expired

Codex cannot find the AWS profile

The model ID is rejected

You receive AccessDeniedException

The desktop app still uses the previous provider

An unexpected Bedrock API key is being used

What actually changes?

Not every feature is supported

Switching between different accounts

Further reading

AI in Games: Are We Drawing the Line in the Wrong Place?

When any use becomes unacceptable

We have seen this pattern before

Judge the outcome, and ask better questions

Agent Creation vs. Agent Engineering

Agent Creation vs. Agent Engineering

Is the agent a feature or a component?

Do you need control over the economics?

Do you need to own where your data goes?

So... Can't We Just Use Claude For Everything?

Understanding Async Programming

What is Async Programming?

Async Doesn't Necessarily Mean Faster

When is Async Programming Useful?

Sync vs. Async: When to Use Each

How Does Async Work in Code?

Ready to Dive Deeper?

Running Kiro Crew in Docker on Windows

What we're going to do

Starting with the official container image

Wait... a sandbox inside a container?

Where Docker gets in the way

The tempting solution and the better solution

Downloading the Kiro Crew seccomp profile

Running Kiro Crew

Let's open it

Authenticating Kiro CLI

Getting our dashboard token

References

Why `~/.config`?

`aws` is not found

You receive `AccessDeniedException`