Best Codex Prompts for Planning, Building, Reviewing, and Automating Software in 2026

Codex can do much more than generate a code snippet from a short instruction.

It can explore a repository, edit files, run terminal commands, execute tests, review changes, work in isolated environments, delegate independent tasks to subagents, and automate repeated development workflows.

However, giving an AI coding agent access to a repository does not automatically give it a complete understanding of your product, architecture, or intended result.

Prompts such as:

• Build this feature.
• Fix the authentication.
• Use multiple agents to refactor the project.
• Review the code.
• Automate this workflow.

leave important decisions undefined.

Codex still needs to determine:

• Which files and systems are relevant.
• What the current behavior is.
• What should happen instead.
• Which existing patterns should be reused.
• What it may change.
• What must remain unchanged.
• Whether the work should run locally, in a worktree, or in the cloud.
• Which tasks can safely run in parallel.
• How different agent results should be integrated.
• What evidence proves that the task is complete.

A strong Codex prompt gives the agent enough context, boundaries, and verification requirements to work independently without giving it unlimited freedom.

This guide contains reusable Codex prompts for repository exploration, feature planning, implementation, debugging, code review, pull-request preparation, AGENTS.md, Skills, subagents, worktrees, cloud tasks, Hooks, Automations, and non-interactive workflows.

Quick Answer

The best Codex prompts clearly define the task, product context, repository context, current behavior, expected behavior, scope, constraints, agent strategy, environment, acceptance criteria, and verification process.

For complex development work, use this sequence:

1. Ask Codex to inspect the repository before editing.
2. Clarify missing requirements and assumptions.
3. Create a reviewable implementation plan.
4. Choose the appropriate Local, Worktree, or Cloud environment.
5. Separate independent tasks from dependent tasks.
6. Delegate only work that can safely run in parallel.
7. Implement changes in controlled units.
8. Run tests and required checks.
9. Review the final diff and agent outputs.
10. Integrate results in a defined order.
11. Save reusable instructions in AGENTS.md or Skills.
12. Automate stable workflows with Hooks, Automations, or codex exec.

The goal is not to make every prompt extremely long. The goal is to communicate the decisions Codex cannot safely infer from the repository alone.

Key Takeaways

• Begin unfamiliar tasks with repository exploration rather than immediate editing.
• Describe the desired product behavior, not only the expected code change.
• Use Local for direct work, Worktree for isolated parallel work, and Cloud for configured remote execution.
• Delegate only independent tasks to subagents.
• Define file ownership and integration order before running parallel implementation work.
• Use AGENTS.md for persistent repository instructions.
• Use Skills for reusable procedures that require multiple steps or supporting resources.
• Use Hooks for deterministic actions at defined lifecycle events.
• Use /review or a dedicated review prompt before accepting broad changes.
• Use codex exec for CI, scheduled jobs, scripts, and machine-readable output.
• Grant the minimum sandbox and command permissions required for the task.
• Review all generated changes before committing, merging, or deploying them.

Table of Contents

• What Are Codex Prompts?
• Codex Prompts vs. General ChatGPT Coding Prompts
• Where You Can Use Codex
• Local, Worktree, and Cloud Environments
• How Codex Works With a Repository
• Codex Prompt Structure
• How to Write Better Codex Prompts
• Best Codex Prompts
• AGENTS.md Instructions
• Codex Skills
• Subagents and Parallel Worktrees
• Codex Hooks
• Code Review With Codex
• Codex Automations and Non-Interactive Workflows
• Weak vs. Strong Codex Prompts
• A Reliable Codex Workflow
• Common Codex Prompting Mistakes
• Using PrompTessor for Codex Prompts
• Codex Prompt Checklist
• Official Codex Resources
• FAQ

What Are Codex Prompts?

Codex prompts are natural-language instructions used to guide OpenAI Codex through understanding, planning, modifying, testing, reviewing, or automating work inside a software project.

A Codex prompt may ask the agent to:

• Explain an unfamiliar repository.
• Trace a feature through several modules.
• Plan a multi-file change.
• Implement an approved feature.
• Investigate a reproducible bug.
• Refactor a system without changing behavior.
• Write and run tests.
• Review a branch or working-tree diff.
• Prepare a pull request.
• Create persistent repository instructions.
• Create a reusable Skill.
• Delegate independent investigations to subagents.
• Run several tasks in isolated worktrees.
• Continue a task in a cloud environment.
• Run an automated review in CI.

Unlike a general chatbot prompt, a Codex prompt operates inside a development environment where the agent may have access to files, Git state, terminal commands, tests, tools, and external integrations.

This means a strong prompt should define both:

• The result Codex should produce.
• The process, boundaries, and evidence that should guide the work.

Codex Prompts vs. General ChatGPT Coding Prompts

A general ChatGPT coding prompt often includes the code directly:

Review this function and identify possible bugs.

[PASTE FUNCTION]

A Codex prompt can ask the agent to locate and inspect the implementation inside the repository:

Inspect the current workspace invitation workflow.

Do not modify files yet.

Locate the interface, API routes, validation, authorization checks, database model, email service, and tests.

Explain the workflow in execution order and identify any missing expiration or duplication handling.

The difference is not that Codex prompts always need to be longer.

The difference is that repository-aware work often requires additional instructions about:

• Which part of the project should be investigated.
• Which product behavior is important.
• Which architectural patterns should be reused.
• Which files or APIs must remain compatible.
• Whether parallel agents should be used.
• Which commands are safe to run.
• How the result should be verified.

For tool-independent templates covering debugging, testing, APIs, databases, security, and code review, see the guide to AI coding prompts for software development.

Where You Can Use Codex

Codex can be used through several development surfaces.

Desktop

The desktop experience is useful for coordinating projects, reviewing diffs, working with local repositories, creating isolated worktrees, running cloud chats, and supervising multiple agent threads.

CLI

Codex CLI is useful for interactive terminal work, repository exploration, local implementation, scripted workflows, and non-interactive automation.

IDE Extension

The IDE extension keeps Codex close to the files and code currently being edited. It is useful for targeted implementation, repository-aware questions, diff review, and iterative development.

Cloud

Cloud environments allow Codex to check out a repository in a configured container, install dependencies, run setup scripts, edit files, execute checks, and return a diff for review.

The best surface depends on the task. A small change may be easiest in the IDE or CLI, while a long-running or parallel task may benefit from worktrees, subagents, or cloud execution.

Local, Worktree, and Cloud Environments

Choosing the correct environment is part of writing a good Codex task.

Local

Local chats operate directly in the current project directory.

Use Local when:

• You are actively supervising the task.
• The change is limited and well understood.
• You want immediate access to local dependencies and tools.
• You do not need isolation from the current working tree.

Worktree

A worktree creates an isolated Git working copy for the conversation.

Use a Worktree when:

• You want to run several implementation tasks in parallel.
• You want to protect the current working directory from experimental changes.
• Different agents need independent branches or file states.
• You want to compare alternative implementations.

Cloud

Cloud execution runs the task remotely inside a configured environment.

Use Cloud when:

• The task may continue while you work elsewhere.
• The repository needs a reproducible environment.
• You need configured runtimes, dependencies, linters, or environment variables.
• You want Codex to return a reviewable diff from an isolated container.

A strong prompt may explicitly state the preferred environment and explain why it is appropriate.

Run this task in an isolated worktree because another agent is modifying the billing module in parallel.

Do not change files outside the notification module.

How Codex Works With a Repository

A typical Codex development loop looks like this:

1. Interpret the requested result.
2. Load applicable repository instructions.
3. Search for relevant files and symbols.
4. Inspect the current implementation.
5. Create or refine a plan.
6. Edit the necessary files.
7. Run commands and tests.
8. Interpret failures.
9. Correct the implementation.
10. Present the final explanation and diff.

Codex performs better when the repository provides clear feedback.

Useful feedback mechanisms include:

• Fast unit tests.
• Reliable integration tests.
• Type checking.
• Linting.
• Production build commands.
• Static analysis.
• Reproduction scripts.
• Screenshot or browser checks.
• Explicit acceptance criteria.

If the agent has no way to evaluate its own result, it may stop after producing code that looks plausible but has not been demonstrated to work.

Codex Prompt Structure

A reliable Codex prompt can include the following components.

1. Task

Define the specific result you need.

Task:
Add expiration and resend functionality to workspace invitations.

2. Product Context

Explain why the change matters and who it affects.

Product context:
Workspace owners need to identify expired invitations and resend them without creating duplicate memberships.

3. Repository Context

Reference known areas or ask Codex to locate the current implementation.

Repository context:
- Authentication already exists.
- Invitations are stored in PostgreSQL.
- Locate the invitation model, API handlers, email service, dashboard interface, and tests.
- Reuse existing validation and error-response patterns.

4. Current Behavior

Describe what currently happens.

Current behavior:
Invitations remain valid indefinitely.
Owners cannot distinguish valid and expired invitations.
Resending can create duplicate invitation records.

5. Expected Behavior

Describe the desired user-visible and system behavior.

Expected behavior:
- Invitations expire seven days after creation.
- Expired invitations cannot be accepted.
- Owners can resend expired invitations.
- Resending does not create duplicate active invitations.
- The dashboard displays pending, accepted, and expired states.

6. Scope and Non-Goals

Define what is included and excluded.

Scope:
- Invitation expiration
- Resend action
- Dashboard status
- Authorization and regression tests

Non-goals:
- Custom expiration periods
- Bulk invitations
- Invitation analytics
- Redesigning workspace settings

7. Constraints

State technical, architectural, product, and compatibility boundaries.

Constraints:
- Preserve existing accepted invitations.
- Do not replace the email provider.
- Do not change the authentication provider.
- Preserve the current API error format.
- Do not add a new dependency unless necessary.

8. Agent Strategy

Explain whether the task should remain single-agent or be divided into independent investigations.

Agent strategy:
Use subagents only for independent read-only investigation.

Delegate:
1. Current invitation data flow
2. Existing test coverage
3. Authorization boundaries

Do not allow subagents to edit files.

The main agent must combine the reports into one plan before implementation.

9. Environment

Specify where the task should run.

Environment:
Use a Worktree because another task is modifying the account settings module.

Do not touch the account settings files.

10. Acceptance Criteria

Define observable completion conditions.

Acceptance criteria:
- New invitations expire after seven days.
- Expired invitations cannot create memberships.
- Only authorized owners can resend.
- Resending does not create duplicate active invitations.
- Existing accepted invitations continue to work.
- The interface displays the correct invitation state.
- Required tests and checks pass.

11. Verification

Tell Codex which evidence must be produced.

Verification:
- Add regression tests for expiration and resend behavior.
- Run invitation-related unit and integration tests.
- Run type checking.
- Run linting.
- Run the production build.
- Report any check that cannot be completed.

12. Output Format

Define how Codex should communicate before and after implementation.

Before implementation:
1. Explain the current workflow.
2. List relevant files and symbols.
3. Identify unanswered questions.
4. Identify compatibility and migration risks.
5. Propose a step-by-step plan.
6. Wait for approval.

After implementation:
1. Summarize the behavior added.
2. List modified files.
3. Report tests and commands.
4. Confirm each acceptance criterion.
5. Explain remaining risks.

How to Write Better Codex Prompts

Describe the Result Before the Implementation

Weak:

Add an expiresAt column.

Stronger:

Prevent expired workspace invitations from creating memberships and allow authorized owners to resend them safely.

The stronger prompt gives Codex the product outcome and allows it to inspect whether a new column is sufficient.

Ask for Exploration Before Broad Changes

Do not modify files.

Trace the complete implementation of this workflow and identify the relevant files, symbols, dependencies, permissions, and tests.

Separate Current and Expected Behavior

This helps Codex identify the exact gap instead of guessing what “broken” means.

Define What Must Remain Unchanged

Preserve:
- Existing public API contracts
- Current authentication behavior
- Stored user and workspace records
- Existing analytics events
- Mobile interface behavior
- Unrelated project workflows

Use Parallel Agents Only for Independent Work

Good parallel tasks include:

• Researching separate modules.
• Reviewing different risk categories.
• Comparing independent implementation options.
• Running isolated test or documentation analysis.

Poor parallel tasks include:

• Several agents modifying the same files.
• One task depending on uncommitted output from another.
• Database and API changes without an agreed contract.
• Broad refactoring without clear ownership.

Require Integration Instructions

When several agents are involved, define:

• Agent responsibilities.
• File or module ownership.
• Dependencies between tasks.
• Required output from each agent.
• The order in which results should be reviewed and integrated.

Ask for Evidence, Not Confidence

Do not ask Codex to say that the feature is correct.

Ask it to report:

• Commands executed.
• Tests passed and failed.
• Acceptance criteria confirmed.
• Files changed.
• Known limitations.
• Checks that could not be performed.

Best Codex Prompts

1. Explore an Unfamiliar Repository

Help me understand this repository before making any changes.

Do not modify files or run destructive commands.

Inspect:

- Repository structure
- Application entry points
- Main modules
- Shared libraries
- Data-access layer
- API boundaries
- Authentication and authorization
- Background jobs
- External integrations
- Testing structure
- Build and deployment configuration
- AGENTS.md files
- Available Skills, Hooks, rules, and MCP configuration

Return:

1. High-level architecture summary
2. Purpose of each major directory
3. Primary application workflows
4. Important files and symbols
5. Data flow between major components
6. Existing architectural conventions
7. Development, testing, linting, and build commands
8. Security-sensitive boundaries
9. Areas that appear incomplete, duplicated, or risky
10. Questions I should answer before changing the project

Reference specific file paths and symbols.

Separate confirmed findings from assumptions.

2. Trace a Feature Through the Codebase

Trace the complete implementation of the following feature.

Feature:
[DESCRIBE THE FEATURE]

Do not modify files.

Identify:

- User interface entry point
- Client-side state
- Input validation
- API or server handler
- Authentication checks
- Authorization checks
- Business logic
- Database operations
- Background processing
- External services
- Error handling
- Logging and analytics
- Relevant tests

Return:

1. Workflow in execution order
2. Relevant file paths and symbols
3. Inputs and outputs at each stage
4. Important data transformations
5. Edge cases already handled
6. Edge cases that appear missing
7. Security and data-integrity boundaries
8. A diagram of the workflow
9. Areas requiring confirmation

Do not infer behavior when it can be verified from the repository.

3. Plan a Feature Before Coding

Research and plan the following feature before editing files.

Feature:
[DESCRIBE THE FEATURE]

User value:
[WHY IT IS NEEDED]

Current behavior:
[CURRENT BEHAVIOR]

Expected behavior:
[EXPECTED BEHAVIOR]

Requirements:
[LIST REQUIREMENTS]

Constraints:
[LIST CONSTRAINTS]

Non-goals:
[LIST NON-GOALS]

First:

1. Inspect the existing implementation.
2. Locate similar features and canonical project patterns.
3. Identify affected files, symbols, APIs, and data models.
4. Identify missing or conflicting requirements.
5. Ask focused clarification questions.
6. Propose the smallest maintainable solution.
7. Explain database, API, interface, and testing changes.
8. Identify security, migration, compatibility, and rollback risks.
9. Divide implementation into independently verifiable steps.
10. Define acceptance criteria for each step.
11. Recommend Local, Worktree, or Cloud execution.
12. Identify whether any investigation can safely be delegated.

Return a detailed plan with file paths.

Wait for approval before implementation.

4. Implement an Approved Plan

Implement the approved plan for the following task.

Task:
[TASK]

Approved plan:
[PASTE OR REFERENCE THE PLAN]

Requirements:
[REQUIREMENTS]

Constraints:
[CONSTRAINTS]

Acceptance criteria:
[ACCEPTANCE CRITERIA]

Required checks:
[TESTS AND COMMANDS]

Follow these rules:

- Inspect every relevant file before editing it.
- Follow applicable AGENTS.md instructions.
- Reuse existing components, utilities, services, schemas, and tests.
- Avoid unrelated refactoring.
- Do not replace dependencies without approval.
- Preserve public behavior outside the approved scope.
- Add appropriate validation, authorization, and error handling.
- Add or update relevant tests.
- Do not hide unfinished functionality behind placeholders.
- Do not commit, push, merge, or deploy without approval.

After implementation:

1. Summarize the user-visible behavior.
2. List every modified file and its purpose.
3. Explain important implementation decisions.
4. Report every command executed.
5. Confirm each acceptance criterion.
6. Identify assumptions, limitations, and remaining risks.
7. Review the final diff for unintended changes.

5. Investigate and Fix a Reproducible Bug

Investigate the following bug using repository and runtime evidence.

Bug:
[DESCRIBE THE BUG]

Current behavior:
[WHAT HAPPENS]

Expected behavior:
[WHAT SHOULD HAPPEN]

Steps to reproduce:
1. [STEP]
2. [STEP]
3. [STEP]

Environment:
[LOCAL, CLOUD, BROWSER, OPERATING SYSTEM, RUNTIME, ETC.]

Observed evidence:
[ERROR, LOG, STACK TRACE, SCREENSHOT, OR TEST FAILURE]

Do not immediately guess a fix.

Follow this process:

1. Reproduce or trace the failure.
2. Locate the relevant execution path.
3. Identify the files and symbols involved.
4. List plausible root-cause hypotheses.
5. Compare each hypothesis with the evidence.
6. Add temporary safe instrumentation if necessary.
7. Identify the most likely root cause.
8. Propose the smallest safe correction.
9. Add a regression test.
10. Verify the correction.
11. Remove temporary instrumentation.

Do not:

- Suppress the error
- Disable validation
- Weaken types without justification
- Remove failing tests
- Modify unrelated code
- Claim the issue is fixed without evidence

Return:

- Root cause
- Supporting evidence
- Fix
- Modified files
- Regression coverage
- Validation results
- Remaining uncertainty

6. Review the Current Diff

Review the current Git changes as a senior software engineer.

Do not modify files during the first review.

Review the relevant diff and surrounding code for:

- Incorrect behavior
- Missing requirements
- Edge cases
- Authentication and authorization
- Input validation
- Data integrity
- Error handling
- Security risks
- Performance regressions
- Race conditions
- Backward compatibility
- Unnecessary complexity
- Duplicate logic
- Missing interface states
- Accessibility
- Test quality
- Accidental or unrelated changes
- Missing migration or deployment steps

For every issue, provide:

- Severity
- File and location
- Evidence
- User or system impact
- Recommended correction
- Verification method

Also provide:

- What was implemented well
- Missing tests
- Assumptions requiring confirmation
- Risks requiring human review
- Overall merge-readiness verdict

Separate confirmed defects from possible concerns.

7. Prepare a Pull Request

Prepare the current branch for a pull request.

Do not push or open the pull request yet.

First:

1. Inspect staged and unstaged changes.
2. Compare the branch with the target branch.
3. Identify unrelated or suspicious modifications.
4. Review generated files and dependency changes.
5. Run required tests, type checking, linting, and build.
6. Stop if required validation fails.

Then provide:

- User-visible summary
- Technical implementation summary
- Modified areas
- Tests and checks performed
- Migration requirements
- Configuration or environment variable changes
- Deployment considerations
- Known limitations
- Required screenshots or verification artifacts
- Suggested commit message
- Suggested pull request title
- Suggested pull request description
- Reviewer checklist

Wait for approval before committing, pushing, or opening the pull request.

8. Create an AGENTS.md File

Create a concise AGENTS.md file for this repository.

First inspect:

- Repository structure
- Package scripts
- Current architecture
- Code conventions
- Testing tools
- Existing documentation
- Existing nested AGENTS.md or AGENTS.override.md files
- Canonical implementation examples
- Current Git workflow

Include only stable instructions that Codex should use across tasks:

- Product purpose
- Technical stack
- Important architecture rules
- Directory responsibilities
- Build, test, lint, and type-check commands
- Coding conventions not already enforced automatically
- Authentication and authorization requirements
- Database migration practices
- Error-handling standards
- Files that must not be modified manually
- Dependency rules
- Expected reporting after completing a task
- Code review rules that cannot be enforced through CI

Avoid:

- Copying the entire README
- Repeating formatter or linter configuration
- Temporary feature requirements
- Large copied code examples
- Vague instructions such as "write clean code"
- Unsupported assumptions

Return:

1. Complete AGENTS.md content
2. Information sourced from the repository
3. Decisions requiring human confirmation
4. Instructions that belong in a nested override
5. Instructions better suited to a Skill, Hook, or CI check

9. Create a Reusable Codex Skill

Create a reusable Codex Skill for the following workflow.

Skill name:
[NAME]

Workflow:
[DESCRIBE THE WORKFLOW]

When it should be used:
[TRIGGER OR SITUATION]

Required steps:
[LIST STEPS]

Required tools:
[LIST TOOLS]

Constraints:
[LIST CONSTRAINTS]

The Skill should:

- Have a clear name and description.
- Package a repeatable multi-step procedure.
- Reference repository files instead of copying large content.
- Ask for missing information when necessary.
- Include verification and a final report.
- Avoid destructive actions without approval.
- Keep stable repository facts in AGENTS.md rather than duplicating them.
- Include scripts or references only when they improve reliability.

Return:

1. Recommended path inside .agents/skills/
2. Complete SKILL.md content
3. Optional scripts, references, or assets
4. Example invocation
5. Expected output
6. Safety considerations
7. Information that should remain in AGENTS.md

10. Delegate Independent Research to Subagents

Investigate the following broad task using specialized subagents.

Task:
[DESCRIBE THE TASK]

Do not modify files during the investigation.

Delegate these independent questions:

Agent 1:
Trace the current architecture and data flow.

Agent 2:
Review authentication, authorization, and sensitive data boundaries.

Agent 3:
Review current test coverage and identify missing cases.

Agent 4:
Locate similar implementations and reusable project patterns.

Each subagent must:

- Receive the complete relevant objective and constraints.
- Work on one isolated question.
- Avoid editing files.
- Reference exact file paths and symbols.
- Separate confirmed evidence from assumptions.
- Return a concise structured report.

After all reports are returned:

1. Combine the findings.
2. Resolve conflicts between reports.
3. Identify unanswered questions.
4. Propose one implementation plan.
5. Identify tasks that can run in parallel.
6. Identify tasks that must run sequentially.
7. Wait for approval before implementation.

11. Divide a Large Change Across Worktrees

Design a parallel implementation strategy for the following project change.

Change:
[DESCRIBE THE CHANGE]

Repository:
[DESCRIBE THE REPOSITORY]

Requirements:
[LIST REQUIREMENTS]

Constraints:
[LIST CONSTRAINTS]

Do not begin implementation yet.

Divide the work into isolated worktree tasks.

For each task, define:

- Objective
- Owned files or modules
- Files that must not be changed
- Inputs or contracts it depends on
- Expected output
- Acceptance criteria
- Tests to run
- Integration dependencies
- Recommended branch name

Rules:

- Do not assign the same file to multiple agents unless one task is read-only.
- Separate shared contract changes from dependent implementation.
- Schedule dependent tasks after the contract is approved.
- Identify migrations or generated files that require centralized ownership.
- Define the order in which branches should be reviewed and integrated.
- Include an integration and regression-testing task.

Return:

1. Worktree plan
2. File-ownership map
3. Dependency graph
4. Parallel task groups
5. Sequential task groups
6. Integration order
7. Main risks
8. Final verification plan

Wait for approval before creating or modifying worktrees.

12. Compare Competing Agent Solutions

Evaluate the implementation proposals produced by multiple Codex agents.

Original task:
[DESCRIBE THE TASK]

Requirements:
[LIST REQUIREMENTS]

Constraints:
[LIST CONSTRAINTS]

Acceptance criteria:
[LIST ACCEPTANCE CRITERIA]

Candidate outputs:
[REFERENCE THE AGENT THREADS, BRANCHES, OR REPORTS]

Compare each candidate for:

- Requirement coverage
- Correctness
- Architectural consistency
- Scope control
- Security
- Compatibility
- Maintainability
- Test quality
- Performance
- Migration risk
- Unnecessary complexity

Return:

1. Summary of each approach
2. Strengths
3. Weaknesses
4. Missing requirements
5. Integration risks
6. Test evidence
7. Recommended approach
8. Useful elements worth combining
9. Changes required before integration

Do not merge or modify files until the recommendation is approved.

13. Configure a Safe Codex Environment

Recommend a safe Codex execution environment for the following task.

Task:
[DESCRIBE THE TASK]

Repository sensitivity:
[PUBLIC, PRIVATE, CUSTOMER DATA, INFRASTRUCTURE, ETC.]

Required operations:
[READ FILES, EDIT FILES, RUN TESTS, NETWORK ACCESS, ETC.]

External systems:
[LIST SERVICES]

Evaluate:

- Local vs. Worktree vs. Cloud
- Read-only vs. workspace-write access
- Required network access
- Environment variables
- Secrets
- Setup scripts
- Dependency installation
- Commands that require approval
- Destructive operations to block
- Logging and output risks

Return:

1. Recommended environment
2. Required permissions
3. Prohibited operations
4. Setup requirements
5. Secret-handling requirements
6. Network-access recommendation
7. Approval checkpoints
8. Recovery and cleanup plan

Prefer the least privilege that can complete the task.

14. Create a Repeated Maintenance Automation

Design a repeatable Codex automation for the following maintenance workflow.

Workflow:
[DESCRIBE THE WORKFLOW]

Frequency:
[DAILY, WEEKLY, AFTER MERGE, ETC.]

Input:
[REPOSITORY, ISSUES, LOGS, DEPENDENCIES, ETC.]

Desired output:
[REPORT, PATCH, PULL REQUEST DRAFT, ALERT, ETC.]

Requirements:

- Define exactly what the automation may read.
- Define whether it may edit files.
- Use the minimum required permissions.
- Keep destructive operations disabled.
- Produce a reviewable report or diff.
- Stop when required validation fails.
- Avoid exposing secrets or customer data.
- Require human approval before pushing, merging, deploying, or writing to external systems.

Return:

1. Automation objective
2. Trigger
3. Prompt
4. Required environment
5. Required tools and permissions
6. Expected output
7. Validation steps
8. Failure handling
9. Human approval checkpoints
10. Recommended monitoring

15. Run a Non-Interactive Review With codex exec

Create a non-interactive Codex workflow that reviews the current branch against main.

Requirements:

- Do not modify files.
- Inspect the Git diff and relevant surrounding code.
- Identify correctness, security, compatibility, and testing concerns.
- Return machine-readable output.
- Use only the tools required for read-only review.
- Exit or fail clearly when critical findings are present.
- Avoid exposing secrets in output.

Return:

1. Recommended codex exec command
2. Sandbox setting
3. Required rules or AGENTS.md behavior
4. JSON Schema for the final output
5. Example shell script
6. Method for parsing the result
7. CI integration notes
8. Failure and timeout behavior
9. Security considerations

A basic command may look like:

codex exec \
  "Review the current branch against main without modifying files. Return prioritized findings with file paths, evidence, impact, and recommended verification." \
  --json

16. Complete Codex Master Prompt

You are working as a careful senior software engineer inside an existing repository.

Task:
[DESCRIBE THE TASK]

Product context:
[WHY THE TASK MATTERS]

Current behavior:
[CURRENT BEHAVIOR]

Expected behavior:
[EXPECTED BEHAVIOR]

Known relevant areas:
[FILES, MODULES, SERVICES, OR ASK CODEX TO LOCATE THEM]

Requirements:
[LIST REQUIREMENTS]

Scope:
[LIST INCLUDED WORK]

Non-goals:
[LIST EXCLUDED WORK]

Constraints:
[LIST WHAT MUST BE PRESERVED]

Environment:
[LOCAL, WORKTREE, OR CLOUD]

Agent strategy:
[SINGLE AGENT OR DELEGATED TASKS]

Acceptance criteria:
[LIST OBSERVABLE COMPLETION CONDITIONS]

Allowed operations:
[LIST ALLOWED TOOLS AND ACTIONS]

Prohibited operations:
[LIST PROHIBITED ACTIONS]

Required verification:
[TESTS, TYPE CHECKING, LINTING, BUILD, MANUAL CHECKS]

Follow this process:

Phase 1: Explore

- Do not modify files.
- Load applicable AGENTS.md instructions.
- Inspect relevant repository areas.
- Explain the current implementation.
- Identify files, symbols, dependencies, tools, and tests.
- Separate confirmed facts from assumptions.

Phase 2: Clarify

- Identify missing requirements and conflicts.
- Ask focused questions when a decision cannot be inferred safely.
- Identify security, migration, compatibility, and data-integrity risks.

Phase 3: Plan

- Propose the smallest maintainable solution.
- List expected file changes and their purpose.
- Explain data, API, interface, background job, and test changes.
- Identify independent and dependent tasks.
- Recommend whether subagents or worktrees should be used.
- Define file ownership and integration order.
- Wait for approval before major edits.

Phase 4: Implement

- Follow AGENTS.md, Skills, and existing project conventions.
- Reuse existing components, utilities, services, and patterns.
- Avoid unrelated refactoring.
- Preserve behavior outside the approved scope.
- Add validation, authorization, error handling, and relevant tests.
- Do not run prohibited operations.

Phase 5: Verify

- Run all required checks.
- Investigate failures instead of ignoring them.
- Confirm every acceptance criterion.
- Review the final diff for accidental changes.
- Do not claim a check passed if it was not performed.

Phase 6: Integrate

- Compare outputs from delegated tasks.
- Resolve contract or file conflicts.
- Apply changes in the approved order.
- Run integration and regression tests.
- Do not merge or push without approval.

Phase 7: Report

Return:

- Summary of changes
- User-visible behavior
- Modified files
- Agent tasks completed
- Important implementation decisions
- Tests and commands executed
- Acceptance criteria results
- Assumptions
- Known limitations
- Remaining risks
- Recommended follow-up work

AGENTS.md Instructions

AGENTS.md provides persistent project instructions that Codex can load when working inside a repository.

It is appropriate for stable information such as:

• Product purpose.
• Architecture rules.
• Build and test commands.
• Directory responsibilities.
• Dependency policies.
• Authentication and authorization standards.
• Database migration practices.
• Required validation.
• Code review rules.

Example:

# Repository Instructions

## Product

This is a multi-tenant SaaS application for creating, optimizing, and organizing AI prompts.

## Stack

- Next.js
- TypeScript
- PostgreSQL
- Prisma
- Tailwind CSS
- Vitest
- Playwright

## Architecture

- Keep route handlers thin.
- Place reusable business logic in service modules.
- Validate external input at system boundaries.
- Enforce user and workspace ownership on the server.
- Reuse existing interface components before creating new ones.
- Preserve current public API response formats.

## Database

- Do not run destructive migrations.
- Include a migration and rollback plan for schema changes.
- Preserve compatibility with existing records.
- Do not modify generated migration files after they have been applied.

## Dependencies

- Ask before adding a production dependency.
- Reuse existing libraries when practical.
- Explain why a new dependency is required.

## Verification

Before reporting completion:

1. Run affected tests.
2. Run type checking.
3. Run linting.
4. Run the production build when relevant.
5. Report any check that could not be completed.

## Safety

- Do not push, merge, or deploy without approval.
- Do not expose secrets or customer data.
- Do not edit unrelated files.

Keep repository instructions concise. Long task-specific procedures belong in Skills rather than being loaded into every session.

Codex Skills

Skills package reusable instructions, resources, and optional scripts into workflows Codex can load when relevant.

Possible Skills include:

• Preparing a pull request.
• Reviewing a migration.
• Running a release checklist.
• Investigating production errors.
• Generating API documentation.
• Auditing authorization boundaries.

A Skill is preferable to repeatedly pasting the same long procedure into a prompt.

Keep stable repository facts in AGENTS.md, and keep task procedures in Skills.

Subagents and Parallel Worktrees

Subagents can investigate or execute independent parts of a larger task while keeping intermediate output out of the main conversation.

They work well for:

• Parallel repository exploration.
• Separate security and testing reviews.
• Independent implementation tasks with clear file ownership.
• Comparing several technical approaches.

Worktrees provide isolated working copies that reduce interference between parallel tasks.

Before using several agents, define:

• What each agent owns.
• Which files each agent may change.
• Which tasks depend on shared contracts.
• Which task must finish first.
• How outputs will be reviewed.
• How branches or diffs will be integrated.

More agents do not automatically produce a better result. Parallelism is most useful when the tasks are genuinely independent.

Codex Hooks

Hooks run deterministic scripts at defined points in the Codex lifecycle.

They can be used to:

• Block unsafe commands.
• Detect accidentally pasted secrets.
• Run validation after edits.
• Collect analytics or audit events.
• Add context when a session starts.
• Summarize completed work.

Hooks are useful when a rule must be enforced consistently rather than relying on the agent to remember it.

Keep frequently triggered Hooks fast and review project-local scripts before trusting them.

Code Review With Codex

Codex can review uncommitted changes, a commit, or a branch diff.

A useful review prompt should specify:

• The exact review scope.
• The original requirements.
• Important security or compatibility concerns.
• The expected severity format.
• Whether Codex may apply fixes.

Reviewing code and fixing code should usually be separate stages.

First ask Codex to report evidence and prioritized findings. Then approve the corrections you want it to implement.

Codex Automations and Non-Interactive Workflows

Stable, repeatable development work can be automated after the workflow has been tested interactively.

Possible examples include:

• Daily bug triage.
• Dependency review.
• Release-note generation.
• Automated branch review.
• Build-log analysis.
• Documentation checks.
• Periodic maintenance reports.

codex exec is designed for pipelines, scheduled jobs, shell workflows, and machine-readable output.

A safe automation should define:

• The allowed repository scope.
• The sandbox permission level.
• The commands Codex may run.
• The output format.
• How failures are reported.
• Which actions still require human approval.

Use read-only execution unless the workflow genuinely needs to edit files.

Weak vs. Strong Codex Prompts

Weak Codex Prompt

Use multiple agents to build the new subscription feature.

This prompt does not explain:

• The expected subscription behavior.
• The existing billing implementation.
• Which agent owns each part.
• Which files may be changed.
• Which tasks depend on shared contracts.
• How database and webhook changes should be coordinated.
• How branches should be integrated.
• What tests prove the feature works.

Strong Codex Prompt

Plan a multi-agent implementation for subscription billing in this existing SaaS application.

Do not modify files yet.

Product behavior:

- Free users receive 20 monthly usages.
- Pro users receive 1,000 monthly usages.
- Max users receive 5,000 monthly usages.
- Users can upgrade from the pricing page.
- Users can manage active subscriptions from account settings.
- Plan access changes only after a verified provider webhook.

Repository context:

- Inspect the existing authentication, user model, usage tracking, pricing page, account settings, API conventions, and test setup.
- Reuse an existing payment integration if one is present.
- Preserve current free users and usage records.

Constraints:

- Do not replace the authentication provider.
- Do not grant access from client-provided values.
- Do not redesign unrelated pages.
- Do not execute destructive migrations.
- Do not allow multiple agents to edit the same files.

Before delegation:

1. Explain the current architecture.
2. Identify missing product decisions.
3. Define the shared subscription contract and data model.
4. Identify security, webhook, migration, and compatibility risks.
5. Wait for approval of the shared contract.

After approval, propose isolated tasks:

Agent 1:
Database schema and migration plan.

Agent 2:
Checkout and customer-management flow.

Agent 3:
Webhook processing and idempotency.

Agent 4:
Server-side usage enforcement.

Agent 5:
Interface states and account management.

Agent 6:
Test strategy and integration review.

For every task, define:

- Owned files
- Required inputs
- Prohibited files
- Expected output
- Acceptance criteria
- Tests
- Dependencies

Integration rules:

- Approve the data contract before implementation.
- Integrate database and webhook changes before dependent interface work.
- Resolve conflicts in the main agent.
- Run complete integration and regression tests after combining results.
- Do not commit, push, or merge without approval.

Final acceptance criteria:

- Checkout creates the correct subscription.
- Verified webhooks update the correct account.
- Duplicate webhook delivery is safe.
- Server-side limits match the active plan.
- Canceled or expired subscriptions lose access according to policy.
- Existing users continue to work.
- Required tests, type checking, linting, and build validation pass.

The strong version defines what can run in parallel and what must remain sequential.

A Reliable Codex Workflow

Step 1: Explore

Do not modify files.

Explain the current implementation and identify relevant files, symbols, dependencies, permissions, tests, and project instructions.

Step 2: Clarify

List missing requirements, assumptions, and conflicts.

Separate blocking questions from optional product decisions.

Step 3: Plan

Create a detailed implementation plan with affected files, contracts, risks, acceptance criteria, and validation steps.

Step 4: Choose the Environment

Recommend Local, Worktree, or Cloud execution and explain the required permissions.

Step 5: Delegate

Identify only the independent tasks that can safely run in parallel. Define ownership, dependencies, and expected output.

Step 6: Build

Implement the approved scope using existing repository patterns and applicable AGENTS.md instructions.

Step 7: Verify

Run the required tests and checks. Confirm each acceptance criterion and investigate failures.

Step 8: Review

Review the complete diff and delegated outputs for correctness, security, compatibility, accidental changes, and missing tests.

Step 9: Integrate

Combine approved changes in dependency order and run integration and regression validation.

Step 10: Reuse and Automate

Move repeated knowledge and workflows into:

• AGENTS.md for persistent repository guidance.
• Skills for reusable procedures.
• Hooks for deterministic lifecycle actions.
• Automations or codex exec for stable repeated work.

Common Codex Prompting Mistakes

Asking Codex to Edit Before Understanding the Repository

Codex may duplicate logic or modify the wrong layer.

Better approach: Begin with read-only exploration and planning.

Using More Agents Than the Task Needs

Parallel agents create additional coordination, context, and integration work.

Better approach: Use subagents only when tasks are genuinely independent.

Allowing Several Agents to Edit the Same Files

This creates merge conflicts and inconsistent implementations.

Better approach: Define explicit file or module ownership.

Parallelizing Dependent Tasks

An interface agent cannot safely implement against an API contract that has not been approved.

Better approach: Finalize shared contracts before starting dependent work.

Leaving the Environment Undefined

The agent may work directly in the current directory when isolation would be safer.

Better approach: Select Local, Worktree, or Cloud deliberately.

Giving Automation Excessive Permissions

A recurring workflow may perform unintended writes or commands.

Better approach: Use the minimum sandbox and tool permissions required.

Putting Every Procedure in AGENTS.md

Large instruction files consume context and become difficult to maintain.

Better approach: Keep stable facts in AGENTS.md and move long procedures into Skills.

Accepting Agent Summaries Without Reviewing the Diff

A correct-sounding summary does not prove that the implementation is safe.

Better approach: Inspect the complete diff and run objective validation.

Using PrompTessor for Codex Prompts

A Codex task often begins as a short instruction:

Use several agents to build subscription billing.

This communicates the general objective but does not define the product behavior, repository structure, task boundaries, ownership, dependencies, integration order, acceptance criteria, or testing requirements.

PrompTessor can help transform rough Codex instructions into clearer prompts before development begins.

A practical workflow is:

1. Start with the feature, bug, codebase question, or automation goal.
2. Add the product outcome and affected user.
3. Describe the current and expected behavior.
4. Add known repository context.
5. Define scope, constraints, and non-goals.
6. Choose the execution environment.
7. Define whether the task is single-agent or multi-agent.
8. Define agent responsibilities and dependencies.
9. Add acceptance criteria and verification commands.
10. Analyze the prompt for missing context or ambiguous boundaries.
11. Refine the prompt based on Codex questions or its implementation plan.
12. Save successful prompts for planning, delegation, review, and automation.

The purpose is not to manually explain information Codex can discover from the repository.

The purpose is to communicate the product decisions, constraints, responsibilities, and completion criteria that the codebase alone cannot provide.

Codex Prompt Checklist

Before sending a complex task to Codex, check whether the prompt explains:

• The exact task or desired outcome.
• Why the task matters.
• The current behavior.
• The expected behavior.
• Known relevant repository areas.
• Existing patterns that should be reused.
• The scope and non-goals.
• Behavior that must remain unchanged.
• The appropriate Local, Worktree, or Cloud environment.
• Whether subagents are necessary.
• Which tasks are independent.
• Which tasks are dependent.
• File or module ownership.
• The integration order.
• Allowed tools and operations.
• Prohibited operations.
• Authentication and authorization requirements.
• Migration and compatibility constraints.
• Observable acceptance criteria.
• Tests and validation commands.
• The required output format.
• Approval checkpoints before Git or deployment actions.

If several items are missing, begin with exploration and planning rather than immediate implementation.

Official Codex Resources

• Codex Prompting
• AGENTS.md Instructions
• Codex Subagents
• Build Codex Skills
• Codex Hooks
• Codex Environments
• Codex Worktrees
• Codex Cloud Environments
• Code Review With Codex
• Codex Non-Interactive Mode

FAQ About Codex Prompts

What are Codex prompts?

Codex prompts are natural-language instructions that guide OpenAI Codex through understanding, planning, modifying, testing, reviewing, or automating work inside a software project.

What makes a good Codex prompt?

A good Codex prompt defines the task, product context, repository context, current and expected behavior, scope, constraints, environment, agent strategy, acceptance criteria, verification requirements, and output format.

Should Codex inspect the repository before editing?

For unfamiliar, broad, or risky tasks, yes. Repository exploration helps Codex locate existing patterns, identify affected systems, and expose missing requirements before changing files.

When should I use multiple Codex agents?

Use multiple agents when the task can be divided into genuinely independent investigations or implementations with clear ownership. Avoid parallel work when agents need to modify the same files or depend on an unapproved shared contract.

What is the difference between subagents and worktrees?

Subagents divide reasoning and tool work between specialized agent threads. Worktrees create isolated Git working copies so separate tasks can change files without sharing the same working tree.

What should go in AGENTS.md?

AGENTS.md should contain stable repository instructions such as architecture rules, commands, directory responsibilities, dependency policies, validation requirements, and safety boundaries.

What is a Codex Skill?

A Skill packages reusable instructions, resources, and optional scripts into a workflow that Codex can load when the task matches its purpose.

What are Codex Hooks?

Hooks are deterministic scripts that run at defined lifecycle events, such as before a tool call, after an edit, when a subagent stops, or when a session ends.

Can Codex review code without modifying it?

Yes. Codex can review working-tree changes, commits, or branch diffs and report prioritized findings without changing the files during the review.

Can Codex be used in CI?

Yes. codex exec supports non-interactive execution, explicit sandbox settings, machine-readable output, structured schemas, and pipeline workflows.

Can Codex run tasks in the cloud?

Yes. A cloud environment can check out the repository, run setup scripts, install dependencies, execute commands, modify files, run checks, and return a diff for review.

Can Codex build an entire application?

Codex can help plan and implement substantial parts of an application, but product decisions, security review, validation, integration, deployment preparation, and maintenance still require human oversight.

Conclusion

Codex becomes more useful when it is treated as a repository-aware development system rather than only a code generator.

The best results come from combining a clear prompt with a controlled workflow:

1. Explore the repository.
2. Clarify the required behavior.
3. Create an implementation plan.
4. Choose the correct execution environment.
5. Delegate only independent work.
6. Define responsibilities and dependencies.
7. Implement the approved scope.
8. Run objective verification.
9. Review every change.
10. Integrate results in the correct order.
11. Save stable instructions and reusable workflows.
12. Automate only after the process is reliable.

A strong Codex prompt does not need to dictate every line of code.

It needs to define the product outcome, repository boundaries, agent responsibilities, execution environment, and evidence that determine whether the task was completed correctly.

That gives Codex enough autonomy to investigate and build while keeping the developer in control of what changes, how parallel work is coordinated, and what ultimately ships.