ChatGPT 桌面应用现可在 AWS GovCloud (US) 中使用 Amazon Bedrock，模型推理通过 Amazon Bedrock 上的 Responses API 进行路由。相关操作说明聚焦于一种受控的本地 Codex 部署：模型请求通过 us-gov-west-1 区域中的 Amazon Bedrock Mantle 发送，并使用 AWS GovCloud (US) 的身份、端点和区域控制。这一范围明确了请求经过的提供商与区域环境，也为后续检查身份来源、配置文件和网络边界提供了共同基础。

这套部署并不是简单地选择或替换一个服务地址。受控方案同时使用 API 模式登录、托管设备策略、命名的 AWS 配置文件、由管理员控制的强制规则、应用运行参数以及网络限制。网络只允许访问已经批准的 Amazon Bedrock 端点，同时禁用其他外部连接和需要网络的功能。因此，身份、应用规则、运行设置与可达的网络目标必须作为一个整体进行准备和验证，不能只检查其中一个部分。

开始前需要准备的条件

部署前需要具备兼容版本的 ChatGPT 桌面应用，以及已经批准的 AWS GovCloud (US) 账户。还需要获得授权的 IAM 身份和相应凭证，并能够访问已经批准的模型、区域和端点。配置材料中必须包括 requirements.toml 与 config.toml。这些条件分别覆盖应用版本、云环境、身份权限、目标资源和本地控制文件，任何一项缺失都会使完整配置无法按照说明建立。

两个 TOML 文件承担不同职责。requirements.toml 是由管理员控制的规则文件，用于施加用户无法覆盖的安全限制。它表达的是本地应用必须遵守的边界，而不是可由最终用户随意修改的偏好。config.toml 则描述运行设置，其中包括 amazon-bedrock 提供商、所用模型、权限和上下文限制。将强制规则与运行参数分开，有助于在审核时区分不可变的控制要求和应用在这些要求内采用的具体设置。

配置由三个主要阶段组成

整个过程可以分为三个主要阶段：首先配置身份验证；然后创建 ChatGPT 桌面应用所需的配置文件；最后启动并初始化应用，再对部署结果进行验证。这三个阶段具有先后关系，因为 requirements.toml 和 config.toml 都必须在应用启动之前安装。这样，应用第一次进入运行状态时，管理员规则与运行设置就已经存在，而不是在启动后才补充。

这一顺序也使检查点更清楚。身份验证阶段确定应用从何处获得凭证；文件阶段确定哪些安全边界不可被用户覆盖，以及应用选择哪个提供商和哪些运行参数；启动与验证阶段则确认运行中的应用是否呈现预期的提供商。网络限制贯穿这些阶段，确保批准的 Amazon Bedrock 端点是允许访问的目标，并使其他外部连接与网络功能保持禁用。

第一阶段：选择并检查身份验证路径

ChatGPT 桌面应用支持两种 Amazon Bedrock 身份验证路径。一种是 Amazon Bedrock API 密钥，另一种是 AWS SDK 标准凭证链。AWS IAM Identity Center SSO 通过凭证链路径获得支持。这两种选择决定应用到哪里寻找凭证，以及哪些已有的 AWS 凭证机制能够参与认证。部署人员不仅要知道计划使用哪一种方式，还要理解应用实际检查凭证来源时采用的优先顺序。

应用首先检查 AWS_BEARER_TOKEN_BEDROCK。如果在平台对应的 .codex/.env 文件中提供了 bearer token，该令牌的优先级高于基于 AWS 配置文件的身份验证。这意味着，即使设备上已经准备了命名的 AWS 配置文件，也不能仅凭该文件存在就断定应用正在使用它。当更高优先级的 bearer token 同时存在时，实际采用的身份来源可能是这个令牌。

如果没有可用的 bearer token，应用才会回退到标准 AWS SDK 凭证链。该凭证链可以使用 AWS 凭证文件和配置文件，也可以使用 SSO 配置文件以及已经缓存的 SSO 会话。通过凭证链还可使用 AWS IAM Identity Center SSO。因此，检查工作应覆盖应用按照顺序实际能够看到的凭证来源，而不能只查看部署计划中写明的命名配置文件。凭证来源的可用性与优先级共同决定最终使用的身份验证路径。

这种优先级关系也是故障排查的重要依据。如果预期使用命名配置文件，但应用环境中存在 AWS_BEARER_TOKEN_BEDROCK，验证人员需要认识到令牌会先被采用。反过来，如果令牌不存在，则应从标准凭证链能够读取的 AWS 文件、SSO 配置文件和缓存的 SSO 会话来理解认证行为。这里的重点不是增加新的认证方式，而是准确核对操作说明已经定义的两条路径及其选择顺序。

第二阶段：安装强制规则与运行配置

身份验证准备好之后，需要创建并安装 requirements.toml 和 config.toml。前者由管理员控制，设置用户不能覆盖的安全限制；后者指定 amazon-bedrock 提供商、模型、权限与上下文限制。两个文件都必须在应用启动前就位。这样可以避免应用先以另一组规则或另一提供商设置启动，再进入预期配置的情况，并使启动后的状态更容易与预先批准的内容进行比对。

文件配置还要与网络控制保持一致。受控本地部署只允许批准的 Amazon Bedrock 端点，同时关闭其他外部连接和所有其他需要网络的能力。从审核角度看，requirements.toml 回答哪些本地安全边界不能被用户改变，config.toml 回答应用使用哪个提供商和哪些运行参数，而网络限制回答哪个外部目标仍然可以到达。三个方面彼此关联，但各自承担清晰而不同的职责。

命名的 AWS 配置文件、API 模式登录和托管设备策略也是该受控设计的一部分。它们应与凭证优先级、两个 TOML 文件以及网络限制一起理解。仅看到 amazon-bedrock 的配置项，并不足以代表全部控制已经建立；同样，只看到批准端点可以连接，也不能替代对身份来源和管理员规则的检查。完整验证需要把操作说明列出的这些组成部分放在同一个部署状态中核对。

第三阶段：启动、初始化并验证

在两个配置文件安装完成后，才启动并初始化 ChatGPT 桌面应用。成功设置可以通过提供商显示来检查：在 Codex CLI 状态视图或 ChatGPT 桌面应用设置中，应当看到 amazon-bedrock 作为模型提供商。该检查把磁盘上的预期配置与运行中应用呈现的提供商联系起来，是部署说明中明确给出的成功验证方式。

验证时可以围绕同一条逻辑链进行核对：应用是否在配置文件安装后启动；显示的模型提供商是否为 amazon-bedrock；身份验证是否按照令牌优先、没有令牌时再使用 AWS SDK 凭证链的顺序工作；网络是否只允许批准的 Amazon Bedrock 端点，并保持其他外部连接与网络功能关闭。这些检查均来自该受控配置的既定组成，不需要把单一界面状态扩大解释为组织层面的批准。

验证失败时必须停止推进

如果验证失败，部署推进应当停止。受影响的设备需要恢复到此前已经批准的策略和提供商设置，而不是保留在部分完成或来源不明的状态。临时 AWS 凭证或 API 密钥应当撤销，并且需要确认设备已经失去与 Amazon Bedrock 的连接。撤销临时凭证与确认连接消失分别处理身份材料和网络可达性，使失败后的状态能够回到先前批准的边界。

在再次尝试之前，还应记录这次失败。记录失败与恢复动作能够避免下一次尝试建立在不明确的部分配置之上。操作说明给出的失败处理顺序包括停止推出、恢复原有策略和提供商设置、撤销临时凭证或 API 密钥、确认 Amazon Bedrock 连接已经丢失，以及在重试前完成记录。这些步骤共同构成部署流程的一部分，而不是可在验证失败后忽略的附加事项。

技术验证不等于工作负载授权

使用 AWS GovCloud (US) 并按照这份说明完成配置，本身并不会授权某个工作负载。组织仍然负责依据自己的安全计划和授权流程审查该部署。这一边界十分重要：确认提供商为 amazon-bedrock、确认凭证路径符合预期、确认两个配置文件已经在启动前安装，以及确认网络只允许批准端点，都属于技术配置与验证，但不能替代组织自身的安全审查和正式授权过程。

因此，这份操作说明最适合作为受控本地部署的技术结构来理解。它说明了请求如何通过 Amazon Bedrock Mantle 在 us-gov-west-1 中路由，说明了 API 密钥与 AWS SDK 凭证链的认证选择和优先级，也说明了管理员规则、运行配置、网络限制、启动验证与失败恢复之间的关系。最终是否允许工作负载运行，仍由组织根据其安全计划和授权流程作出判断，不能从使用 AWS GovCloud (US) 或完成这些技术步骤中自动推导。