Usage Policies and Controls

Lesson updated November 3, 2026 based on the Workspace model availability, ChatGPT usage limits and spend controls, and Pricing pages in the Codex documentation: model routing in GPT-5.6 is replaced by the GPT-6 family; workspace starting values are presented as defaults rather than permissions; and restrictions by “task type,” which do not exist in the product, are presented as a policy enforced by CI, the sandbox, and GitHub. Sources: Workspace model availability · Usage limits.

Define Codex Usage Rules

Once you deploy Codex in your organization, you must establish clear policies: who can do what, on which projects, with which models, and under what conditions. Without this framework, every developer sets their own limits based on their temperament. You will only discover the gap when an agent-generated pull request modifies an authentication routine without anyone thinking to question it.

What to Allow, What to Govern, What to Forbid

Structure your internal policy document around three circles. The first covers low-risk uses where standard code review is sufficient. The second covers domains where mistakes are costly and therefore require prior approval. The third lists hard prohibitions—rules you do not negotiate case by case on a Friday night.

## Recommended Uses
- Generating unit and integration tests
- Refactoring existing code (with human review)
- Auto-generating documentation (JSDoc, README, API)
- First-pass code review
- Debugging from logs and stack traces
- Migrating libraries and frameworks

## Uses Requiring Approval
- Changes to security-related code (auth, crypto)
- Database schema changes
- Infrastructure changes (Dockerfile, CI/CD)
- Code handling financial or medical data

## Prohibited Uses
- Deploying generated code to production without human review
- Accessing repositories containing raw customer data
- Using Codex to bypass review processes

State the final prohibition with absolute clarity because it describes a natural, gradual drift: a rushed developer will eventually convince themselves that an agent-performed review equals a colleague’s review. Writing in black and white that this reasoning is forbidden ends the debate.

Who Approves What

Approval remains vague until you name names. A responsibility matrix resolves this by mapping each change type to an authorized initiator and an approval level. It protects the code while keeping work flowing: without it, every decision escalates to the tech lead, who becomes the bottleneck.

Translate Policy into Technical Controls

A policy with no enforcement is just another wiki page. Three levers make it effective, provided you know which belong to the product and which belong to your organization.

The first concerns models. Your policy can steer usage:

Routine development → GPT-6.1 Sol
Most demanding work → GPT-6 Astra (team decision required)
Simple, repetitive tasks → GPT-6 Luna
Writing, visual work → GPT-6.1 Terra

On the product side, workspace owners and admins can set separate starting values for Chat versus Work and Codex: model, reasoning level, and speed. These are defaults, not permissions: the models actually available depend on the seat, role, identity (ChatGPT account or API key), imposed requirements, and the surface in use. A model setting in the ChatGPT workspace does not automatically apply to Codex in the CLI, extension, cloud, or API, and Codex Cloud does not allow changing its default model. With an API key, model access follows the platform organization and project associated with the key.

The second lever restricts what you automate per repository. There is no “by task type” button: you enforce this policy with the repository’s actual tools—which CI workflows call Codex, with what sandbox, what command rules, and what GitHub branch protections:

repo: production-api
  - PR review: ✅ (automated review, read-only sandbox)
  - code generation: ⚠️ proposed as patch, never pushed
  - automatic CI fix: ❌ diagnostics only

repo: internal-tools
  - PR review: ✅
  - code generation: ✅
  - CI fix: ⚠️ in separate PR, reviewed

The third lever concerns budget. Workspace spend controls allow, depending on your plan, per-user guardrails, workspace-level caps, and notifications; API billing is managed separately. Set your thresholds in the policy, then configure them:

Notification at 80% of monthly budget
Cap at 100% of monthly budget
Review unusual usage with team lead
Monthly report from workspace analytics

Intellectual Property and Liability

Under OpenAI’s Terms of Use, you own the content the tool produces: OpenAI claims no ownership rights over outputs. This legal clarity does not excuse you from stating it in your internal policy, because the real question teams face is not ownership but liability. Who answers for a line of code no one wrote by hand?

## Intellectual Property
- Code generated by Codex belongs to [your company]
- Developers are responsible for the code they approve
- Codex is a tool—final liability is human
- Codex PRs must be reviewed like any developer PR

The answer lies in the second line: the approver assumes responsibility. This formulation closes the gray zone where a developer might, after a production incident, claim the code came from the tool, not them.

Review the Policy Quarterly

A policy written at launch becomes outdated within months simply because usage evolves faster than the documents that govern it. Schedule a quarterly review in five steps:

1. Analyze usage metrics (who uses what, and how much)
2. Review incidents (Codex errors, security issues)
3. Collect developer feedback
4. Adjust quotas and permissions
5. Update internal documentation

Expect to relax rules as often as you tighten them. Many restrictions put in place as a precaution at launch prove unnecessary once you observe real usage, and keeping them without reason only encourages workarounds.

Key Takeaways

• Write a clear usage policy and share it with the entire team
• Define a responsibility matrix for each change type
• Configure technical controls: models, repositories, costs
• You own the generated code, but human liability remains
• Review your policy quarterly