Codex / Getting Started

Import the project into Codex

The key to letting Codex understand the project is not to stuff a lot of text at once, but to provide repositories, rules, task goals and verification methods.

View official source Docs index

Import the project into Codex key concepts infographic

Import the essence of the project

Importing the project into Codex does not mean feeding a lot of text at once, but allows Codex to read the real repository under the correct directory, correct permissions and correct rules.

Project rules, commands, design specifications, and testing requirements should be written into AGENTS.md or project documentation. The tasks are then supplemented with specific goals, relevant documents and acceptance criteria.

First time read recommendations

When you ask Codex to read the project for the first time, let it output the understanding first, and do not change the file.

Please don't change the file yet.
Output after reading the project root directory, package.json, routing and test configuration:
- Technology stack
- run command
- Main directory
- Risk boundaries
- Suggestions for follow-up tasks

Boundaries on import

Don’t give keys, cookies, and production data directly to Codex. When connecting to external systems, MCP or controlled commands with permission boundaries and logs are preferred.

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.

Correct posture for importing projects

When handing your project off to Codex, the most important thing is to make it work within a real repository and within the correct boundaries. Don't paste a lot of files into the chat, and don't let it blindly scan the entire repository. A better approach is to establish the initial context using the project root, AGENTS.md, README, package or configuration files.

First read: Codex is asked to first explain the project structure, how it is run, how it is tested, main directories and risk boundaries.
Rule import: Put team commands, design constraints, prohibitions, and submission formats into AGENTS.md.
Scope import: Clear relevant paths in the task, such as src/auth, routes/api, tests/auth.
Sensitive boundaries: Do not import keys, cookies, customer data, or production connection strings; use controlled tools when accessing external systems is required.

The best first step after importing is read-only analysis. Wait until Codex can tell you exactly how the project runs, which files need to be modified, and how to verify it before allowing it to edit.

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 "Import the project into Codex" 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 concept page, be specific about how it affects the real task: does it change context, permissions, execution paths, validation methods, or changes the team collaboration process.

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 belongs to the core concepts of Codex. When learning, connect concepts to real-world implementation: will it change context, permissions, task splitting, verification paths, or change the way teams collaborate.

When handling tasks related to "Import the project into Codex", 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.