Set up the ChatGPT desktop application using Amazon Bedrock in AWS GovCloud (US)
ChatGPT desktop app can run on Amazon Bedrock in AWS GovCloud for Codex with IAM controls, data residency, per-token billing, and zero data retention.
Key Takeaways
- The ChatGPT desktop app can now run through Amazon Bedrock in AWS GovCloud (US), allowing security-sensitive organizations to use OpenAI models under GovCloud identities, endpoints, and regional controls.
- The setup supports two main components: Work for complex multi-step tasks and Codex for software development, with Codex inference routed through Amazon Bedrock Mantle in us-gov-west-1.
- Organizations can apply data-residency controls, token-based billing, and optional zero data retention, while a managed deployment can restrict network access to the approved Amazon Bedrock endpoint.
- Authentication can use an Amazon Bedrock API key or the AWS SDK credential chain, including AWS SSO through IAM Identity Center, with bearer tokens taking precedence when configured.
- Local deployment requires config.toml and admin-controlled requirements.toml before launch, enforcing login, sandbox, approval, feature, and network restrictions; following the guide alone does not authorize a workload.
The ChatGPT desktop app is now available on Amazon Bedrock in AWS GovCloud (US), giving organizations with strict security architectures a way to run OpenAI's frontier models through GovCloud identities, endpoints, and Regional controls. The deployment covers two components: Work, which handles complex, multi-step tasks and produces review-ready results, and Codex, a coding agent for developing, testing, and reviewing software.
The arrangement matters most for agencies and contractors whose system security plans require model inference to stay inside AWS GovCloud (US). A newly published walkthrough shows how to configure Codex so its model requests route through Amazon Bedrock Mantle in us-gov-west-1, where access can be governed with AWS Identity and Access Management (IAM) and existing GovCloud network controls. Using GovCloud and following the guide does not by itself authorize a workload; each organization must still review the model, services, Region, endpoint, workstation controls, repositories, credentials, and data flows against its own authorization process.
What the deployment actually includes
Codex is OpenAI's coding agent for AI-powered software development, with GPT models powering inference. Teams can reach it through the ChatGPT desktop app, the Codex CLI, and IDE integrations with Visual Studio Code, JetBrains, and Xcode. Model inference is routed through the Responses API on Amazon Bedrock.
For customers with data residency requirements, processing stays within the Amazon Bedrock AWS Region they select. Billing is per token, with no seat licenses and no per-developer commitments. Zero data retention (ZDR) is also supported: in that configurable mode, prompts and responses are processed without being written to durable storage by AWS or shared with model providers, which helps organizations protect sensitive information and meet data-governance, privacy, and security requirements.
The walkthrough describes a controlled local deployment of the ChatGPT desktop app that sends inference to Amazon Bedrock in AWS GovCloud (US-West). It relies on API-mode sign-in, a managed device policy, a named AWS profile, and network restrictions that permit only the approved Amazon Bedrock endpoint while disabling other external connections and network-enabled capabilities. The stated goal is a deployment an agency security team can test and document before approving broader use.
Two components, two kinds of work
The desktop app serves two purposes. Work targets larger tasks that need planning, research, files, and a finished result. Codex targets technical work such as editing code, running tests, and reviewing pull requests.
Because the setup talks to AWS directly, ChatGPT workspace rules and user roles do not control it. The primary security controls are the computer's policies and the AWS identity and permissions in use—a distinction administrators should understand before rollout.
Authentication: two supported pathways
Administrators first select the approved AWS GovCloud (US) account and an IAM identity or role with access to the approved model in us-gov-west-1, then obtain credentials through the organization's approved mechanism. The walkthrough uses a named profile, codex-il5. Credentials, bearer tokens, session tokens, and other secrets should stay out of TOML files, and the profile configuration, credential source, SSO token cache, and any credential helper should be protected from app task writes while approved authentication tools maintain and refresh them.
The app supports an Amazon Bedrock API key or the AWS SDK credential chain, with AWS SSO through AWS IAM Identity Center supported inside the credential-chain pathway. The app checks first for AWS_BEARER_TOKEN_BEDROCK in its environment, which desktop users can supply through %USERPROFILE%\.codex\.env on Windows or ~/.codex/.env on Linux and macOS; when present, the bearer token takes precedence over profile-based authentication. Without a bearer token, the app falls back to the standard AWS SDK credential chain, which can read credentials from ~/.aws/credentials and profile settings from ~/.aws/config—or %USERPROFILE%\.aws\credentials and %USERPROFILE%\.aws\config on Windows. For SSO, the chain uses profile settings in the AWS config file plus the cached SSO session to obtain temporary role credentials that need not be stored manually in the credentials file.
Configuration files must exist before first launch
Two files drive the setup: config.toml and requirements.toml. Both must be in place before the application launches, or the app will prompt for an OpenAI account instead of using the Bedrock path.
| Operating system | User config.toml | Admin requirements.toml |
|---|---|---|
| Windows | %USERPROFILE%\.codex\config.toml | %ProgramData%\OpenAI\Codex\requirements.toml |
| Linux | ~/.codex/config.toml | /etc/codex/requirements.toml |
| macOS | ~/.codex/config.toml | /etc/codex/requirements.toml |
requirements.toml is the administrator-controlled rules file. It sets security limits users cannot override—restricting permitted login methods, sandbox modes, approval policies, and features. The published baseline allows only API login, permits read-only and workspace-write sandbox modes, restricts approvals to the user, disables browser and computer use, appshots, remote control, login shells, and managed hooks beyond the managed-only setting, turns off update checks and feedback, and empties the MCP server list. A features block disables in-app chat, dictation, browser, image generation, memories, plugins, and standalone web search while enabling the network proxy. An experimental network block enables managed allowed domains only, with no upstream proxy, no local binding, and no Unix sockets. The application network domain list allows exactly one destination—bedrock-mantle.us-gov-west-1.api.aws—and explicitly denies api.openai.com, chat.openai.com, chatgpt.com, ab.chatgpt.com, platform.openai.com, auth.openai.com, gov.api.openai.com, gov.chatgpt.com, sdfedpreastus2.oaiusercontent.com, o33249.ingest.us.sentry.io, persistent.oaistatic.com, and oaisidekickupdates.blob.core.windows.net. A Windows section requires the elevated sandbox implementation and sandbox_private_desktop.
config.toml tells the app how to operate: which provider (amazon-bedrock), which model, and settings such as permissions and context limits. The model ID and named profile are placeholders to replace with approved values. The sample sets forced_login_method to api, sandbox_mode to workspace-write, web_search to cached, disables login shell and startup update checks, and defines the amazon-bedrock provider with base_url https://bedrock-mantle.us-gov-west-1.api.aws/openai/v1, wire_api responses, requires_openai_auth false, no WebSocket support, and no standalone web search. The provider's AWS block sets region us-gov-west-1 and profile codex-il5. Sandbox workspace write disables network access; analytics, feedback, and all OpenTelemetry exporters are off, with log_user_prompt false; memories generation and use are off; bundled skills, default apps, and the Windows elevated sandbox are configured.
Launch and verification
Teams download the app from the ChatGPT site, install it, and leave it closed—fully exiting ChatGPT and ending lingering ChatGPT or Codex processes if it opened automatically or ran before. After confirming both files are in place, they start the app and check that amazon-bedrock appears as the model provider, both in the Codex CLI /status tab and in the desktop app settings.
Troubleshooting and rollback
Four failure modes are documented. If the app prompts for an OpenAI account, the files are likely in the wrong location or named incorrectly, or processes were not fully terminated before relaunch. If the GovCloud endpoint is reported unsupported, confirm the exact desktop or app-server release, endpoint, and model with OpenAI—changing the URL alone does not establish support. If the wrong AWS identity is used, inspect the effective credential source and named profile, and check whether an Amazon Bedrock API key is taking precedence. If capability restrictions appear missing, inspect the full effective requirements after restart, because the API-only sign-in setting does not apply the capability policy by itself.
If a validation check fails, the guidance is to stop the rollout, return affected devices to the previously approved policy and provider settings, restart the app, revoke any temporary AWS credentials or API keys, and confirm those devices can no longer connect to Amazon Bedrock.
What to watch
The practical takeaway for security teams is that the hard boundary here is network and identity configuration, not the ChatGPT workspace. The allow-list of a single GovCloud endpoint, combined with API-only login and an administrator rules file, is what keeps inference inside the approved Region. Organizations evaluating the setup should verify app version support for GovCloud before installing, treat the model ID and profile name as approval-gated values, and plan the rollback steps into the pilot itself. Broader adoption will depend on how each agency documents this deployment against its own system security plan.
Comments (0)