Codex / Configuration

Codex configuration

Configuration lets Codex know the project's default commands, permission preferences, and working methods.

Configuration file

Codex local default behavior is usually written in config.toml. Common configurations include model, reasoning, sandbox_mode, approval_policy, profiles, MCP, hooks, and web_search.

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"
web_search = "cached"

Configuration principles

Team shared configurations should be conservative, and personal configurations can be more consistent with habits. Configurations involving permissions, networking, automatic approvals, and full access should be reviewed explicitly.

Use read-only or workspace-write + on-request when you are not familiar with the repository.
Tighten the sandbox when using never in automated scripts.
Network access is turned off by default and allowed by domain name when needed.

Complete usage points

Supplement the core concepts, operation sequences, permission boundaries and verification requirements that are easily compressed and missed in official documents, making it easier for English readers to learn completely by page.

Configuration affects default behavior

Codex configuration is used to set default behaviors such as model, inference strength, sandbox, approval policy, profiles, MCP, hooks, and network search. The closer the configuration is to automation, the more conservative it needs to be.

Personal configuration: suitable for your own model preferences, output habits, and commonly used profiles.
Project configuration: Conservative permissions, MCPs, hooks and rules suitable for team sharing.
Automated configuration: write scope, network, timeout and approval policies must be explicitly restricted.

Don’t put keys in committable configurations; don’t make danger-full-access the team default; don’t enable silent high privileges when you’re unfamiliar with the repository. Configuration should make good behavior the default, rather than relying on prompting every time.

Study Checklist

Put the content on this page into real tasks and use the five dimensions of entry, context, permissions, verification and team rules to check whether you have truly mastered it.

Study Checklist

After reading this page, do not just remember the concept name. You should be able to place "Codex configuration" back into a real Codex engineering workflow: where the task starts, what context the system loads, which actions need approval, how the result is verified, and how to roll back when it fails.

If this is a configuration or reference page, be specific about where the configuration is placed, whether it will be submitted, whether it contains sensitive information, whether it will extend the default permissions, and how to troubleshoot the settings that actually took effect in the event of a failure.

Be able to describe in your own words the specific problem this page solves, rather than just reciting the title.
Able to write a minimal example task with goals, scope, prohibitions, and acceptance criteria.
Be able to determine which information should be put into the current prompt and which should be captured as project rules or configurations.
Be able to explain which long-term rules should go into AGENTS.md, and which runtime behavior should be handled by config.toml, permission profile, skills and MCP.
Ability to check diffs, command output, test results, screenshots or PR notes after a task is completed instead of just trusting the natural language summary.

If this page is used for team training, ask learners to complete a small task with Codex: read and explain first, submit a plan, make the smallest useful change, and close with real verification commands plus human diff review.

Codex practical notes

Fill in the most overlooked execution details of Codex usage around local environments, privilege escalation, remote entry, automation failures, and rollbacks.

Codex Practical Notes

This page affects the default behavior of Codex. Before configuring, determine whether it will expand file writing, network access, tool invocation, or silent execution capabilities, and retain audit and rollback methods for the team.

When handling tasks related to "Codex configuration", always confirm the current Git status and working directory first. Codex can make changes quickly, but it does not automatically know which uncommitted edits came from the user, which files are off limits, or which commands may affect production.

Prioritize using low-risk branches or working trees for local tasks, and review them with git diff after completion.
When it comes to installation dependencies, networking, databases, deployment, push, deletion, and reset, Codex must first be asked to explain the impact before approval.
Results generated by remote or collaborative portals must also be confirmed back to PR, CI, build logs and test evidence.
Automated tasks must define failure output and exit conditions in advance to avoid Codex repeatedly trying in the wrong direction.

Think of Codex as an engineering teammate who can execute commands, rather than an assistant who can only write text. The closer you get to a real system, the greater the need for clear boundaries, evidence, and rollbacks.