Build
Create a feature, app, website or internal tool from a clear description.
Codex
Ask for working software, not just code
Give Codex a focused project and a clear outcome. Let it inspect, edit, run and test—then review the real result before calling the work finished.
BuildDebugReview
A trustworthy coding loop
InspectUnderstand the project first
→EditChange only what matters
→TestRun the software or checks
→ReviewVerify the outcome
✓Use Codex when software is the output
Debug
Inspect the actual project, identify the likely cause, fix it and run relevant tests.
Review
Use Codex as a second pair of eyes before important software is shipped.
A useful first request
Review this project first. Explain simply how it is structured and which files matter. Then build [feature]. Keep the current design, change nothing unrelated, test the result and tell me exactly what changed.
Choose the right surface
You want…
Use
Example
An explanation
Chat
Why might this error occur?
A business deliverable
Work
Research and build a deck
Software changed
Codex
Add login and test it
What makes a Codex request easier to complete
Codex is strongest when it can inspect the actual project, run the relevant software or tests and determine whether the requested outcome works.
Keep the scope focused
Give Codex the project or folder that matters and explicitly protect unrelated areas. Unnecessary files create more context and more opportunities for confusion.
Define a verifiable finish line
Name the tests, expected behavior or visual result that prove the change works. If success cannot be checked, a confident explanation may hide an incomplete implementation.
Review consequential changes
Codex can edit real files and execute commands. Production systems, security-sensitive code and important customer data require deliberate human review.
Codex
Give Codex the right boundaries
Where Codex runs determines the files, tools and permissions it can use. Choose the environment deliberately and read approval requests before accepting them.
SandboxApprovalsProject rules
Three working environments
💻LocalYour project and installed tools
🌿WorktreeIsolated local Git copy
☁️CloudConfigured remote environment
📱RemoteCoordinate work from mobile
Environment changes what is possible
Environment
What it means
When it helps
Local
Works in a project on your computer
Needs local files and tools
Worktree
Uses an isolated Git working copy
Keeps changes separate
Cloud
Runs in a remote environment
Delegated work away from your machine
Make the operating rules visible
Project instructions
Use AGENTS.md for test commands, naming conventions, files not to change and completion checks.
Sandbox
The workspace boundary controls what Codex can technically read, edit and run.
Approvals
When Codex asks to cross a boundary, read the exact action and impact before approving it.
A confident explanation is not a test result
Ask Codex to run the software or relevant checks, then inspect the result yourself—especially for production or security-sensitive work.
Reasoning, speed and ongoing project guidance
Model strength is only one part of the setup. Persistent instructions and an appropriate reasoning level often matter just as much.
Match reasoning to the coding task
A small, familiar change may need less reasoning. An unfamiliar codebase, difficult bug or architectural decision benefits more from deeper reasoning, even though it takes longer.
Use faster modes deliberately
Fast modes can prioritize speed for supported models, but they may consume allowance differently. Choose them when a quick iteration is more valuable than the deepest possible analysis.
Use AGENTS.md for standing rules
Project instructions can record test commands, naming conventions, files that must not change and the checks required before completion. This prevents you from repeating the operating rules in every request.