Safer Codex Edits: Permissions, Branches, Diffs, Tests, and Code Review

💡 What this guide covers: keeping Codex from breaking your code, touching unrelated files, or saying “done” without testing. You’ll learn how to match permissions to a task, keep a way back, check diffs and test evidence, verify frontend changes in a browser, and use Codex for code review.

More Codex articles: Save Effort · Codex

Where things go wrong

• Three common worries with AI-written code: the work looks finished but misses edge cases; the scope grows to include unrelated files; or tests never run—or fail without anyone noticing.
• A summary can leave things out. The diff shows the changes. Don’t take “I only made a small change” at face value.
• Complex changes rarely come together in one try. Database migrations and end-to-end tests depend on data, environments, and edge cases. Check them in stages. A working screen doesn’t prove a migration is correct and cannot replace test evidence.
• Merge conflicts: tasks editing the same files can overwrite each other. Separate branches and check each change.
• Missing safety boundaries: skipping the diff, granting broad access in production, letting an agent use sensitive admin systems, or never looking at the actual frontend page.

1. Will Codex change things it shouldn’t?

That depends on three things:

1. Your permission settings.
2. How clearly you write the task. See prompts, context, and slash commands.
3. Whether you check /diff.

Keep this rule in mind: small tasks, limited permissions, thorough checks.

2. Match permissions to the task

Modes in the VS Code extension

Permission settings to check in the Codex App

• Whether automatic approval is enabled.
• Whether full access is allowed.
• When it needs your approval.
• Which workspace is active.
• Whether it can operate your computer.

Without permissions, AI can only talk you through a task. Give it too much access and skip the diff, and problems become more likely. Choose permissions per task rather than applying one setting to everything. As you learn its limits, you can gradually allow more and avoid wasting time on unnecessary confirmations.

Three permission levels for beginners

Labels vary slightly across versions, but the idea is similar:

• Default permissions: advice only, useful when you want to see a proposal first.
• Automatic approval: file edits can happen automatically, while important actions need approval.
• Full access: broader permissions and more actions without intervention.

For beginners:

• Use automatic approval for everyday work.
• Require manual approval for deleting files, installing dependencies, and pushing code.
• For large refactors, ask for a plan and approve it before implementation.
• Don’t grant full control on day one. Open things up gradually as you learn its behavior.

In the CLI, /permissions controls read-only access, file edits, and whether commands need approval. Be especially cautious with production projects, older projects, and projects without Git.

Default sandbox and approval settings

• Commands run in a sandbox designed to prevent changes outside the project. If something cannot run safely there, Codex asks for permission.
• The default approval policy is on-request: work continues until an action needs higher permissions.
• The default sandbox allows writes within the workspace, not arbitrary locations outside it.
• Both can be adjusted at startup. Keep the defaults for normal code edits. If a task needs more system access, define the approval policy and sandbox scope beforehand. If you don’t understand an action’s impact, require confirmation rather than opening everything up.

Want fewer approval prompts? Two approaches

Option 1: turn off approvals

# ~/.codex/config.toml
approval_policy = "never"
sandbox_mode = "workspace-write"

This lets Codex edit files and run commands within the project without asking. You are handing over those step-by-step decisions. On a company computer, requirements.toml may forbid never; see the configuration guide. This setup is not recommended for beginners or production projects.

Option 2: authorize a specific safe workflow

For a clearly safe local workflow, make the approval scope narrower. In AGENTS.md, explain why the workflow is safe—for example, local tests use disposable data and have no production access. Allow Codex to run tests, fix failures caused by the current change, and rerun affected tests without asking at every step. See the configuration guide for the settings and rules.

Computer-use agents: useful, but enable them carefully

An agent can operate applications such as browsers, admin consoles, and desktop software. Filling out cloud-server settings, App Store screenshot information, and repetitive web forms can be good uses. Keep it away from:

• Payment confirmations.
• Money transfers.
• Data deletion.
• Account security settings.
• Keys and tokens.
• Private conversations.
• Sensitive internal company systems.

If it must use an admin console, ask for a plan first and state your boundaries:

You are about to use a browser-based admin console.
Before clicking any Submit, Delete, Pay, or Confirm button, stop and wait for my approval.
If tokens, keys, phone numbers, or email addresses appear, do not read or repeat them.

These are basic safety boundaries. You wouldn’t let a human assistant click payment buttons freely either. Write down which actions need human approval instead of relying on the model to decide in the moment.

3. Keep a way back before editing

• Create a branch. Before asking Codex to edit code, Net Ninja used git switch -c feature/modal.
• Make a Git checkpoint before and after a task, as recommended in the official IDE guide. That gives you a way to revert.
• If the project has no Git repository, initialize one first: run git init, then make an initial commit. Write useful commit messages. If every message says update, your future self won’t thank you. For the full GitHub connection steps, see long tasks and cloud workflows.
• Plan high-risk work first. README edits, wording fixes, and comments are low risk and can usually go straight to implementation. Payments, sign-in, permissions, database migrations, user data, and production deployments need a plan and small steps. Move quickly on small tasks; slow down for large ones. Start large tasks with /plan; see prompts and commands.
• Keep human review for database migrations and production changes.

4. A copy-and-paste template for safe changes

Use this when changing an existing website without breaking unrelated features:

First read the project and understand its structure, tech stack, and existing features.
Task: [enter the requirement here]

Work in this order:
1. Find the relevant files. Explain which files you plan to change and why.
2. Check existing project rules, including AGENTS.md, README, and relevant configuration.
3. If the work involves databases, authentication, payments, production settings, or deletion, explain the risks and ask for approval first.
4. Edit only within the approved scope. Do not change unrelated files or add dependencies without a reason.
5. Run the project's existing tests, type checks, or build commands.
6. Check the Git diff for unintended changes.
7. Report what changed, which tests passed, what remains unverified, and any remaining risks.

Do not report unrun tests as passed. Clearly state anything you cannot verify.

This follows the staged development and verification approach in OpenAI’s official guidance.

5. A complete example: Net Ninja’s modal component

1. Create a branch: git switch -c feature/modal.
2. Switch modes: move from Chat to Agent so Codex can edit the project.
3. Describe the feature: build a reusable modal with a translucent backdrop, a white body, content passed through a slot, and a close button. Show a success message when the new-pair form submits without validation errors.
4. Inspect the result: Codex creates the modal and a test file, then updates the form and CSS. The extension lists the edits, affected files, and tests run. Submitting the form shows the selected model, with its details in the modal.
5. Be patient: the result was correct, but this was one of the author’s slowest Codex tasks. Complex edits take longer than quick questions or small changes. Model choice matters too; see long tasks and model selection.
6. Check it in a browser: submitting the form with sample data opens the modal, and the close button dismisses it.
7. Check validation: missing required fields should prevent the modal from opening. Fill them in and submit again: the modal should appear. That confirms the form and component are connected and the modal opens only after validation passes.

6. Check the diff afterward

Five things to check every time

1. Which files changed?
2. Did anything outside the task scope change?
3. Were dependencies added?
4. Did lint, tests, and the build run?
5. Is there leftover debug code, fake data, or sensitive information?

Ask for a file-by-file explanation

List this task's changes by file.
For each file, explain:
1. Why it changed
2. What changed
3. The risks
4. Which commands verified it

If it hasn’t run tests

You haven't run the tests yet.
Find the test command in the project documentation first.
If there is no test command, explain the smallest verification you can perform.

Use /diff to see the actual changes

/diff shows added files, removed content, and untracked files. Don’t rely on the summary. An AI summary can omit changes; the diff shows them.

Review in the IDE

• After editing, the extension provides a short summary and a focused diff, showing affected files and changed lines without opening another navigation panel.
• Each edit has an Undo option. Remove changes you don’t want and keep only what you need. The source and explanation appear side by side.
• You can request follow-up changes in the same conversation.

A useful combination: inspect /diff, then ask for /review.

Human-written code needs review. AI-written code needs it even more. AI removes repetitive work, but the final judgment is still yours.

7. Ask for test evidence, not “done”

• Put verification instructions in AGENTS.md so Codex can edit, check, and adjust on its own. See the configuration guide.
• Break complex work into stages. After each stage, ask it to run checks and report exactly what passed and what failed. For defining completion and evidence, see long tasks and Goals.
• Open the files to confirm the feature exists. If you asked it to generate agents.md through the Responses API, inspect the implementation, confirm the API is wired in, and run it. “Added” in a chat message is not proof.

8. Frontend work: look at the page

Crowded buttons, overlapping mobile layouts, modals covering content, and low-contrast colors aren’t always obvious from a diff. “The build passed” is not enough. Have Codex verify the page in a browser.

Start the project and open the local page.
Check:
1. Text overlap at a 375px mobile width
2. The first screen at a 1440px desktop width
3. Overflowing button labels
4. Clear form error states
If you find a problem, show a screenshot and explain it before changing anything.

The frontend workflow is: describe the goal → let Codex edit → open the page in a browser → check screenshots → adjust styles → verify again.

Add this to every frontend task to catch “correct code, wrong page” problems:

Verify the result with browser screenshots. Don't just say the code is finished.

9. Use Codex for code review

Review is a good place to start

If AI edits make you nervous, start by asking for a review without changes. It is lower risk and lets you judge the tool. Reliable findings show it understands the project; weak findings show where it misjudges things. This is a steady way to build trust.

Review a pull request:

Review this change.
Focus on:
1. Obvious bugs
2. Unhandled edge cases
3. Security risks
4. Gaps in tests
5. Opportunities to simplify
Provide review comments only. Do not edit code.

Review the local diff:

Review the current git diff.
Group findings by severity:
P0 Must fix
P1 Recommended fix
P2 Optional improvement
Be specific. Identify the file and explain the reason for each finding.

Built-in review options

• CLI: /review switches Codex to a reviewer’s perspective, focusing on bugs, regressions, missing tests, overlooked edge cases, and security risks. It supports four approaches: compare against a base branch, review all uncommitted local changes, review one commit, or add custom review instructions.
• IDE extension: click Code Review for the same four options. For uncommitted changes, select that option and Codex works through the diff before listing findings.

Custom instructions help because priorities vary. Feature work needs logic and edge-case checks. Security changes need permission, input-validation, and vulnerability checks. Code being released also needs sufficient tests and consistent style.

Put team review standards in a file

Create code-review-guidelines.md and reference it from AGENTS.md so the main file stays short. Include rules such as:

• Check logic and edge cases.
• Look closely at security when permissions or user input are involved.
• Check whether new features need additional tests.
• Keep the code style consistent with the project.

Reading the findings

• Codex prioritizes P0 and P1 findings that need urgent attention. It may also find P2 and P3 issues, but it won’t nitpick everything. Noisy reviews quickly become easy to ignore.
• A practical test for a finding: if we leave this unfixed, could it cause a problem after release?
• Findings return to the IDE extension with a Fix button. Click it to let Codex handle the issue without copying the comment into another request. The official team has used it to find and fix code issues too.
• Run /review before committing.

The same three steps after every change

/diff
/review
Run tests

Don’t just read the summary. This is also day four of the seven-day practice plan: “Review the current diff. Give feedback only; don’t edit code.” It trains you to judge the quality of the work.

For automatic reviews on every PR or private reviews in your own containers, see long tasks and cloud workflows. Enterprise administrators can also use the official enterprise administration and security guides linked there.

Official documentation to keep handy

• Codex IDE guide
• Codex configuration guide in Chinese
• Rethinking Skills and Prompts for GPT-6 Astra