Skip to main content
Lesson 16 of 20 · Codex: AI-Assisted Development

Manage Codex in an organization

Lesson 16 of 20 Updated November 3, 2026 Developer
On this page
  1. Deploy Codex for a development team
  2. Choose your plan
  3. Assign owners
  4. Open access without opening it too wide
  5. Govern local execution
  6. Control consumption
  7. Spread standards with a template repository
  8. Onboard a new developer
  9. Key takeaways

Lesson rewritten on November 3, 2026 based on the Admin rollout guide, the Pricing page, and ChatGPT usage limits and spend controls in the Codex documentation. The previous version described an admin console at codex.openai.com, “Admin, Developer, Viewer” roles, and daily task quotas that no longer match the product; administration now happens through the ChatGPT workspace. Interface labels evolve; the OpenAI Help Center is the source of truth for procedures. Sources: Admin rollout guide · Pricing · Usage limits.

Deploy Codex for a development team

Moving from individual use of Codex to an organization-wide deployment requires planning. What works for one curious developer becomes unmanageable with thirty people if no one defines who accesses what or who pays. OpenAI’s deployment guide breaks the topic into distinct administrative boundaries: workspace access, local execution policy, Codex Cloud, API access, plugins and connectors, and permissions in connected systems.

Choose your plan

The choice isn’t just about headcount; centralized authentication requirements and traceability are what push you toward Enterprise.

PlanWhat it brings to the organization
BusinessDedicated workspace, essential admin controls, SAML SSO and MFA; no training on company data by default; $20 per user per month with annual billing (2-user minimum), $25 monthly
Enterprise and EduEverything in Business, plus SCIM, EKM, per-user analytics, domain verification, role-based access control (RBAC), audit logs via the Compliance API, and data retention and residency controls
API KeyCodex in the CLI, SDK, or extension, billed at API rates; no cloud features (GitHub code review, Slack, etc.)

Check the Codex pricing page for current rates and plan contents when you decide; they change.

Assign owners

Before you touch any settings, designate an owner for each boundary: workspace access (members, seats, roles), local execution policy (approvals, permission profiles, file and network access), Codex Cloud (environments, repository connections), connected systems (GitHub app installation, accounts, permissions), and reporting (analytics, audit exports). Then decide, audience by audience, whether they need Codex locally, in the cloud, or both; API key access belongs to a separate boundary, that of the API platform organization and projects.

Open access without opening it too wide

Access is managed in the ChatGPT workspace: membership, seats, groups, and RBAC permissions where your plan offers them. Don’t assume a single role controls all surfaces; verify local access and cloud access separately, using a test member who has exactly the intended permissions. Reserve built-in admin roles for people who actually administer the workspace.

Two settings deserve special attention. Local usage is controlled by a dedicated permission—depending on your workspace layout, Allow members to use Codex and Work Locally, or separate sections Codex Local and Work Local. And Codex Cloud is disabled by default in Enterprise workspaces: an administrator grants Use Codex in the cloud to the target audience and, separately, Manage workspace environments to the people who create and modify shared environments.

The most structural control remains repository access. Codex Cloud respects the permissions and protections of the source system: so on GitHub, limit the integration’s access to only the repositories each audience needs. Workspace access does not bypass these controls. A secrets repository must never be connected, no matter how convenient it might seem during a crunch.

Govern local execution

For the desktop app, CLI, and extension, the local policy is distributed via a requirements.toml file, deployed through a managed channel (cloud, device management, or system). It enforces constraints that users cannot override, such as allowed permission profiles:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

Cloud environments do not inherit this local policy or device management settings; their requirements are configured separately.

Control consumption

Workspace usage limits and spend controls apply to eligible activity under your plan, including some Codex activity when your contract uses shared or purchased ChatGPT credits: per-user guardrails, workspace-level caps, and notifications. They do not cover all Codex usage, nor API platform billing, which is managed separately. GPT-6 Astra’s Ultrafast mode, disabled by default in eligible Enterprise workspaces, consumes credits faster: revisit per-user caps before enabling it.

To see where consumption goes, use workspace analytics and the Analytics API, not the Compliance API, which is reserved for audit and investigation use cases (Lesson 17).

Spread standards with a template repository

Nothing guarantees a new project starts with the right configuration unless you bake it into the starting point. Repository-specific configuration—default settings, command rules, skills—is versioned in .codex or .agents, depending on the documented location for each feature; it provides defaults and reusable workflows but cannot grant any access.

# Your organization's template repository
my-org/project-template/
  AGENTS.md           → Organization standards, including ## Code Review Rules
  .codex/             → Shared configuration and rules
  .github/
    workflows/
      codex-review.yml → Automated review (Lesson 14)

Every project created from this template inherits the standards without a kickoff meeting or a reminder three months later.

Onboard a new developer

  1. Add them to the ChatGPT workspace, in the group that carries the right permissions.
  2. Verify their local access and, if your audience needs it, their access to Codex Cloud and environments.
  3. On GitHub, verify they see the intended repositories, and only those.
  4. Share the internal usage guide and the template repository.
  5. Have them explore the project with Codex: “Explain this repository’s architecture and useful commands,” from the root, so they also read AGENTS.md.

This last step produces a tailored project discovery that the newcomer reads before bothering colleagues.

Key takeaways

  • Codex administration happens through the ChatGPT workspace, split into boundaries: access, local execution, cloud, API, plugins, connected systems
  • Business brings SAML SSO and MFA; Enterprise and Edu add SCIM, RBAC, Compliance API, and data controls
  • Codex Cloud is disabled by default in Enterprise; repository access is limited on GitHub
  • requirements.toml enforces local policy; repository configuration only proposes defaults
  • Workspace spend controls cover neither all of Codex nor API billing