Codex for teams and enterprises

Rolling Codex out to a team means four decisions, in order: which ChatGPT workspace people sign in to, what the repository commits, which limits requirements.toml enforces, and how you check the result. Defaults live in config.toml, limits in requirements.toml; a rollout needs both.

This page is for the tech lead taking Codex from one enthusiast to a whole team, and the developer asked to make every setup match. The usual symptom: one person runs with full access, another approves every command by hand, and nobody knows whether a bad result came from the prompt or the configuration. Checked against Codex CLI 0.157.1 on 2026-09-26.

Which Codex team page answers your question?

Your question	Page
How do we share AGENTS.md, .codex/config.toml, rules and skills through the repository?	Team collaboration and shared configuration
How do we enforce limits developers cannot override, and get audit data?	Enterprise governance and compliance
How do we keep usage and credit spend predictable?	Codex cost management
How do we configure cloud tasks for the team?	Codex cloud environments

Running Claude Code or Cursor as well? Use one managed policy across every coding agent. Deciding where the model may run at all? Start with where the model runs.

In what order should you roll Codex out to a team?

A constraint file is useless while half the team signs in to the wrong workspace.

1. Settle sign-in and plan. Codex is included in the Plus, Pro, Business, Edu and Enterprise plans (OpenAI’s Codex README, checked 2026-09-26). Put the team in one Business or Enterprise workspace, then have each person run codex login status. It confirms a ChatGPT sign-in, not an API key, but does not name the workspace; the pin in step 3 enforces that.

2. Commit the project layer. Commit AGENTS.md, .codex/config.toml (sandbox, approval policy, MCP servers), team rules and skills, all under CODEOWNERS. Codex loads .codex/config.toml only from a trusted directory, so a developer who marks it untrusted silently falls back to personal settings.

3. Enforce the floor with requirements.toml. It constrains every layer below it. Codex reads it from /etc/codex/requirements.toml on macOS and Linux, from the platform’s system config directory on Windows, from MDM managed preferences, or from an enterprise-managed cloud bundle (config_requirements.rs, checked 2026-09-26).

   /etc/codex/requirements.toml

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["YOUR_WORKSPACE_ID"]
   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]
   allowed_web_search_modes = ["disabled", "cached"]
   allow_managed_hooks_only = true

   Replace YOUR_WORKSPACE_ID with your workspace ID. Other sign-ins fail with “Login is restricted to workspace id(s)…”. Set the committed approval_policy to an allowed value; /debug-config shows which one won.

   This snippet uses the legacy sandbox modes. Permission profiles (default_permissions, beta) are OpenAI’s preferred control and a second route to full access; the two systems do not compose. If your team uses profiles, constrain that route with allowed_permission_profiles. Unlike the other allowed_* keys it is a table of profile names, not a list, so an array is rejected:

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

   Never allow :danger-full-access. In 0.157.1, requirements.toml must also set default_permissions unless both of those built-ins are allowed.

4. Prove the floor on a clean machine. Run codex doctor, then /debug-config in the TUI, which shows each config layer and the source of every requirement. Then try both spellings of full access: codex --sandbox danger-full-access and codex -c default_permissions=":danger-full-access". Each passes when Codex refuses to start or /status shows read-only or workspace-write access.

5. Gate the output like human work. Agent pull requests pass the same CI, tests and CODEOWNERS review as everyone else’s. Add openai/codex-action@v1 or codex exec review for a second pass, as set out in Codex in CI/CD.

Copy-paste prompt: audit this repository's shared Codex config

Audit this repository's shared Codex configuration for a team rollout. Do not edit any
files. Read every AGENTS.md, .codex/config.toml, any .rules files, the shared skills
directory and CODEOWNERS. Report:
1. Every setting that grants danger-full-access, approval_policy "never", or live web
   search, with the file and line.
2. Every MCP server: transport, what it can reach, and any credential that is not read
   from an environment variable.
3. Settings that only work on one machine: absolute paths, personal tokens, tools the
   README does not install.
4. Commands in AGENTS.md that no longer exist in package.json, Makefile or the CI files.
5. Which of these files CODEOWNERS does not protect.
End with a table: finding, risk (high, medium, low), and the one-line fix.

Copy-paste prompt: draft the team's requirements.toml

Draft a requirements.toml proposal for our Codex rollout. Do not write it to any system
path; print it and explain each line. Base it on .codex/config.toml in this repository
and propose only:
1. allowed_approval_policies and allowed_sandbox_modes that exclude "never" and
   danger-full-access. allowed_sandbox_modes must include "read-only".
2. allowed_web_search_modes without "live".
3. allow_managed_hooks_only = true, with the hooks we would then need to manage centrally.
4. The MCP servers we already use, listed as [mcp_servers.<name>.identity] with their
   command or url.
For each line, name the developer workflow it would break and how to test that it holds.

How do you know the Codex rollout holds?

Check	Evidence	Who signs off
Everyone signs in to the right workspace	/debug-config shows the allowed_chatgpt_workspaces pin; codex login status shows a ChatGPT login; workspace members match the team	Workspace admin
The floor is loaded	/debug-config names the requirements source; both full-access starts in step 4 end in a refusal or in read-only or workspace-write access in /status	Platform or security owner
The project layer is shared	Two developers’ /status shows the same model, sandbox and approval policy	Tech lead
Agent changes pass the same gates	CI and CODEOWNERS required on the default branch; no direct pushes	Repository owner

What breaks when Codex goes team-wide?

• One developer’s results differ from everyone else’s. Check project trust first (an untrusted directory drops .codex/config.toml), then -c overrides and --profile.
• requirements.toml is rejected or ignored. allowed_sandbox_modes without "read-only" is an error in 0.157.1. An empty allowed_approval_policies list is an error too, while an empty allowed_web_search_modes silently restricts search to disabled. /debug-config shows which source Codex read; a cloud-managed or MDM layer can win over the local file.
• Hooks stop firing after allow_managed_hooks_only. That setting ignores every hook that is not managed — user, project, session and plugin hooks — by design. Move the team’s hooks into the managed layer first.
• Spend jumps after rollout. Unused MCP servers and oversized AGENTS.md files cost context every session. Trim them, then see Codex cost management.

Where to go next with a Codex team rollout

• Start with the shared files: team collaboration and shared configuration.
• Take the controls organization-wide: enterprise governance and compliance.
• Keep agent credentials out of the agent’s context: agent identity, credentials and secrets.
• Lead the people side of the change: leading a team that ships with agents.
• Compare the other tools’ team setups: Claude Code for teams and Cursor for teams.