---
title: "做企业管理员初始化"
description: "为 Enterprise workspace 推出 Codex 前，先确定 owner、入口范围、RBAC、managed configuration 和治理边界。"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

企业管理员初始化 Codex，不是简单打开一个开关。你需要先确定谁拥有配置权、哪些入口开放、哪些用户可以使用、哪些策略必须强制、以及如何审计和回滚。

> [!IMPORTANT]
> 企业 rollout 的顺序应是 owner 和策略先行，然后再开放 Cloud、local、MCP、internet access、automations 和 code review 等能力。

<Cards>
  <Card title="Enterprise admin setup" href="https://developers.openai.com/codex/enterprise/admin-setup">
    查看企业初始化 Codex 的官方 rollout guide。
  </Card>
  <Card title="Managed configuration" href="/docs/codex/official/06-team-integration/55-managed-config">
    统一下发 sandbox、approval、MCP、feature flags 和 requirements。
  </Card>
  <Card title="Governance" href="/docs/codex/official/06-team-integration/56-governance-observability">
    做 analytics、audit logging、compliance 和可观测。
  </Card>
</Cards>

## Rollout 先分责任

企业环境至少需要三类 owner：

- Workspace owner：负责 ChatGPT workspace 中的 Codex 开关和访问控制。
- Security owner：负责权限、网络、secrets、sandbox、approval 和风险策略。
- Platform / analytics owner：负责 managed configuration、analytics、audit logging 和运维集成。

不要把所有权限给一个泛泛的“管理员组”。Codex Admin 应只给少数负责 rollout、policy 和 governance 的人员。

## 先决定开放哪些入口

```mermaid
flowchart TB
    Codex["Enterprise Codex rollout"]
    Local["Local<br/>App / CLI / IDE"]
    Cloud["Cloud<br/>Web / integrations / remote tasks"]
    Both["Both<br/>统一治理"]

    Codex --> Local
    Codex --> Cloud
    Codex --> Both
```

Local 入口：

- 运行在开发者机器或本地 workspace。
- 更接近个人开发环境。
- 重点治理 sandbox、approval、local config、MCP 和凭据。

Cloud 入口：

- 运行在 hosted environment。
- 需要 GitHub、environment、secrets、internet access 和 integration 权限。
- 重点治理 repo 访问、环境隔离、网络和任务触发。

同时开放两者时，必须解释两套运行位置和数据边界的差异。

## RBAC 和最小权限

建议建立两类组：

- Codex Users：可以使用 Codex 的普通用户。
- Codex Admins：可以管理 policies、analytics、environment 和治理设置的少数管理员。

原则：

- 默认用户不需要管理权限。
- 管理权限要可审计。
- 通过身份提供商和 SCIM 管理组成员。
- 不同团队可以有不同 policy。
- group rule 顺序要明确，避免权限意外扩大。

RBAC 的目标是把“谁能用”和“谁能管理”分开。

## Managed configuration

Managed configuration 用来统一下发要求，而不是依赖每个开发者手动配置。

适合强制：

- 允许的 approval policies。
- 允许的 sandbox modes。
- web search 和 network behavior。
- MCP allowlist。
- feature flags。
- command rules。
- automatic reviewer policy。

先给大多数用户设置 baseline policy，再为高风险团队或特殊 workflow 建立更严格或更宽松的变体。

## Cloud 设置的额外边界

启用 Codex Cloud 前确认：

- GitHub repositories 是否托管在支持的环境里。
- 谁有权连接 repositories。
- environment setup 是否最小化。
- secrets 是否只在必要阶段可用。
- 是否需要 internet access。
- 允许哪些域名和 HTTP methods。
- task 完成通知是否会把敏感内容发回 Slack 或其他系统。

Cloud 的便利性来自异步执行，但风险也来自远程自动化。默认先保守开放。

## Local 设置的额外边界

启用 local 入口前确认：

- 开发者能否安装 App、CLI、IDE extension。
- 是否允许 device code authentication。
- 是否限制登录方式和 workspace。
- 是否允许项目级 `.codex/`。
- 是否允许本地 MCP。
- 是否限制 browser use、computer use 或 plugins。

Local 入口更靠近开发者机器，必须让默认 sandbox 和 approval 合理。

## 治理和可观测

企业 rollout 不能只看启用人数。还要建立可观测指标：

- 使用量和活跃用户。
- Cloud tasks 成功率。
- review 触发和反馈质量。
- policy 命中情况。
- MCP 和 tool 使用。
- 失败原因和阻塞点。
- 安全事件和审计日志。

这些数据用于改进 policy、培训和 workflow，而不是只做报表。

## 推荐上线顺序

1. 明确 owner、用户组和管理组。
2. 先开放小范围 pilot。
3. 配置 baseline managed policy。
4. 开放 local 入口。
5. 配置 Cloud environment 和 GitHub access。
6. 逐步接入 integrations、MCP、automations。
7. 打开 analytics、audit 和 compliance 流程。
8. 根据真实 usage 调整 policy。

每一步都应有回滚方案和联系人。

## 管理员检查清单

上线前确认：

- 用户是否知道 local 与 cloud 的区别。
- Admin 权限是否最小化。
- managed configuration 是否生效。
- secrets 和 internet access 是否受控。
- MCP 是否有 allowlist。
- 自动 review 是否有质量标准。
- 日志、审计、合规是否能查询。
- 有无明确支持和升级路径。

企业版 Codex 的目标不是“让所有人马上自动化”，而是把 agent 能力放进可治理的工程系统里。
