Codex Team Training and Safety: Permissions, Sandboxing, and Review

What are the main safety controls in Codex?

OpenAI’s documentation groups permissions into sandboxing, auto-review, and agent approvals. The CLI’s /permissions command lets you choose when Codex can edit files or run commands without asking, and lets you inspect the active sandbox and its writable roots.

Learn the controls before you teach them. The goal is that every developer can answer three questions about their current session: what can the agent change, what can it run, and when will it ask me first?

How should you set the defaults?

Start conservative and relax with evidence.

1. Sandbox on. Keep the agent’s writable area to the project directory.
2. Ask before consequential actions. Network access, installing dependencies, and deleting files should prompt.
3. No production credentials. Do not make deployment secrets available in the working environment.
4. Version control always. Work in a branch with a clean tree so every change is visible and reversible.
5. Document the settings. Write the default and the exceptions in your AGENTS.md and policy.

What should training cover?

Run one hands-on session on your own repository.

• The loop. Plan, edit, test, review. Use the Codex guide for setup.
• A first AGENTS.md. Write it together. See the AGENTS.md guide.
• Permissions. Each developer inspects their own settings and explains them to a partner.
• Review. Read agent-authored diffs critically. Plant a bug in an exercise and see who catches it.
• Secrets and dependencies. What never goes into a prompt, and who approves a new package or MCP server.

Then hold office hours two weeks later. The valuable questions appear after real use.

What review rules should you adopt?

The person who merges owns the code, regardless of who or what wrote it. Add three rules: every agent-authored change is reviewed by a human, tests must pass in CI and not just locally, and security-sensitive areas, such as authentication or payments, get an additional reviewer.

Do not measure success by volume of generated code. Watch review cycles, defect rework, and developer-reported friction.

How do you pilot and measure?

Pick one team with solid tests and a supportive lead. Record baselines before you begin, such as time to a reviewed pull request. Run four to six weeks, hold a retrospective, and standardize what worked. Compare against the baseline and report what you measured and how.

For the engineering rollout framework on the Claude side, which applies equally here, see rolling out Claude Code to an engineering team. For the policy layer, see the AI acceptable use policy guide.

What safety controls should a Codex pilot start with?

Start narrow and expand. A cautious pilot looks like this:

1. Low-risk repository first. No production secrets, no deployment credentials in the environment.
2. Restrictive permissions. Use Codex’s permissions controls (/permissions in the CLI, per OpenAI’s documentation) so risky actions need approval.
3. A boundaries file. Put always, ask-first, and never rules in AGENTS.md.
4. Review everything. Every change goes through your normal pull request and CI.
5. Log lessons. Capture mistakes and fold them into the instructions.

Settings and sandboxing options evolve, so verify current controls in OpenAI’s documentation and with your security team. Training matters as much as settings: developers should know what the agent can reach, how to spot a risky suggestion, and when to stop and ask.

How should you train a team on an AI coding agent?

A good session runs on the team’s own repository. Show the setup, run a read-only task, then a small change with review. Practice a scenario where the agent proposes something risky and have people explain why they would reject it. Close with the shared rules and a place to ask questions. Compare with Claude Code rollout practices.

Frequently asked questions

Product features, plans, and limits change often. This guide reflects the vendor documentation listed above as of November 2026. Check the vendor’s current documentation before you make purchasing or policy decisions. TechStack Consulting is an independent training firm and is not affiliated with Anthropic or OpenAI.