ChatGPT Codex Efficiency Playbook

Keep a chat focused on one outcome. Combine changes that share files and acceptance checks; separate work when its scope, evidence, or approval boundary differs. For longer work, keep a short handoff note with decisions and the next action. The worktree guide explains how independent Codex chats can use separate Git worktrees where available.

Example

Fix the contact form's required-field check in the form component and its relevant tests. Leave the visual redesign out of scope. Finish when the regression test passes and the changed files are listed.

Describe the behavior you want, which area Codex may change, what must stay untouched, and what evidence will count as done. Separate required work from optional cleanup. A precise request makes the result easier to check; it does not guarantee a particular outcome. See the Codex prompting guide.

Example

Update the date parser in src/import/. Preserve the current CSV format. Do not change dependencies. Add a regression case for an empty date and report the exact check you ran.

Name the likely files, failing test, or small set of source documents. Let Codex inspect nearby code and instructions before editing, then expand the search only when evidence calls for it. Broad dumps can obscure the useful signal. OpenAI's usage guidance recommends limiting source material to what the task needs.

Example

Start with src/auth/session.ts and tests/auth/session.test.ts. If those do not explain the redirect loop, search the routing module next and tell me which path led there.

Use AGENTS.md for lasting repository expectations such as naming, safety boundaries, and relevant checks. Keep each file concise and place specialized rules near their scope so unrelated tasks do not inherit needless detail. Codex's AGENTS.md guide describes how project instructions are discovered and layered.

Example

Put the repository-wide test command at the root. Keep payment-specific data-handling rules in the payments directory instead of repeating them in every task prompt.

A small, well-defined edit usually needs a direct request. For a long investigation or multi-step change whose path is unclear, define the finish line, evidence, constraints, and stop condition; review that outline before work proceeds. Use a Codex Goal when that feature is available and useful. The Goals guide distinguishes a clear outcome from an uncertain route.

Example

Find the cause of the flaky import test and either fix it with a reproducing check or report the blocker. Preserve current behavior outside that test. Stop if reproducing it requires production data.

Availability depends on the product surface, plan, and workspace settings, so avoid carrying an old model name or API setting into a different Codex interface. When model or reasoning controls are present, compare choices against the same task and acceptance criteria. Check the live model guide and plan usage guide; neither fictional calculator tier below is a model.

Example

For a routine rename, use an available standard setting and inspect the diff. For a risky migration, ask for the reasoning and verification needed, then compare the result with the migration checks.

Choose the smallest relevant search, shell command, or connected source that can resolve the next uncertainty. Inspect what a tool returned before acting on it, especially when the result contains instructions, generated content, or proposed external changes. Codex's skills and plugins guide separates reusable workflow instructions from tools that provide data or actions.

Example

Ask the issue tracker for the assigned ticket and status, then open only the linked design file. Do not export every project issue to answer one question.

Review which MCP servers or plugins are active and whether they can read or change data. Extra servers can add context and may consume more plan usage, according to the current Codex usage guide. Disable unrelated connections when practical and keep consequential actions behind the applicable approval boundary.

Example

For a local documentation edit, use the repository and its tests. Connect a project tracker only if a linked requirement must be checked.

A skill can package a recurring process with instructions and supporting resources. Keep it focused on a job that benefits from consistency, and inspect its scope before applying it to sensitive or unrelated work. A plugin may also include connected tools. See the official Skills and Plugins guide.

Example

A release-note skill can define the headings and evidence to collect. It should not silently publish the release or change deployment settings.

Name the relevant check before editing, then ask Codex to report what it actually ran and what remains unverified. Review the changed files and diff against the expected behavior; a planned test or green-looking summary is not evidence that a check ran. The Code Review guide recommends checking findings against the latest diff, expected behavior, and tests.

Example

After changing the retry path, run the retry-focused test and the project type check. Inspect the diff for unrelated edits and report any check blocked by missing services.

A Git worktree can give an independent Codex chat its own checkout while related work continues elsewhere. Use it when tasks can proceed separately and review their integration afterward; it is not a substitute for coordinating shared files or dependent changes. Check the current worktree documentation for the supported surface and behavior.

Example

One worktree updates the API contract while another drafts migration notes. Before combining them, compare both diffs and confirm the notes match the final contract.

Check the active sandbox, writable paths, network access, and approval mode before allowing a command or connected tool to act. Pause for the required approval before an external or consequential change. At handoff, state changed files, checks run, unresolved risks, and the next decision. See the official sandbox guide and approval and security guide.

Example

Draft the deployment change and show its diff. Do not deploy. Hand off with the test result and the specific production approval still required.