Start Codex in your repository root, run /init to create an AGENTS.md, explore in read-only mode before changing anything, then describe one specific task naming the files and the constraint. Review with /diff and /review before you accept, commit in small pieces, and use /new between unrelated tasks. Escalate reasoning effort on evidence rather than by default.
- Run
/initfirst in any new repository. It pays for itself in the first session. - Start in read-only while you do not know the codebase yet.
- Every strong prompt has three parts: the symptom, the file, and the constraint.
/diffbefore you accept anything./reviewbefore you push.- Commit in small pieces, not at the end of a long session.
/newbetween unrelated tasks. Context you did not clear is context you are paying for.- Escalate
model_reasoning_efforton evidence, not by default.
The first fifteen minutes
Start in the repository root
cd ~/code/your-project
codexThe launch directory is the workspace root and the sandbox is scoped to it, so this is not merely a convention. Outside a git repository Codex refuses to start unless you pass --skip-git-repo-check, because git is the undo button for everything that follows.
Generate an AGENTS.md
/initCodex reads the project and drafts one. Edit it down hard: keep the commands and the traps, delete anything it could have inferred, then commit it. Every future session in this repository starts better because of it.
Explore before you change anything
codex -s read-only -a neverAsk it to explain the architecture, find where a feature lives, or trace a request from handler to database. It cannot break anything and it will not interrupt you to ask permission for a grep. This is the highest value-per-token session you will run all week.
Then make one small change
Something you could do yourself in twenty minutes, so you can review the output properly. The goal of the first real task is calibration, not output: you are learning what this model does well in this codebase, and that is not knowable from a benchmark.
Prompting for Codex
The difference is the same as anywhere, and the cost is higher here because effort multiplies it.
| Weak | Strong |
|---|---|
| "Fix the auth bug" | "Sessions expire an hour early. Look at internal/auth/token.go, I think the TTL is applied twice. Do not change the public signature." |
| "Add caching" | "Add an in-memory cache to GetUser in internal/store/user.go. 60s TTL. Do not change the signature and do not add a dependency." |
| "Clean this up" | "Extract the validation from handler.go into validate.go. Behaviour identical; the existing tests must pass unchanged." |
Give it the failure, not your theory
Paste the actual test output, the actual stack trace, the actual log line. A model given a symptom investigates; a model given your diagnosis implements your diagnosis, including the part where you were wrong. If you do have a theory, say so as a theory: "I think the TTL is applied twice" is useful, "the TTL is applied twice, fix it" is not.
Reviewing before you accept
/diff- Read the diff, not the explanation. The explanation was written by the same thing that wrote any bug in it.
- Check the deletions. Removed lines get less scrutiny than added ones and are where regressions hide.
- Run the tests yourself. "Tests pass" is a claim, and a cheap one to verify.
- Watch for scope creep. Files touched that had nothing to do with what you asked are the signal that the constraint was missing.
Codex has a second review surface worth using once you are past the diff. /review in a session, or codex review outside one, runs a dedicated review pass over the changes and reports what it finds.
codex review --uncommitted # staged, unstaged, untracked
codex review --base main # everything on this branch
codex review --base main "focus on error handling and missing tests"Managing context, model, and effort
Three dials, and knowing which one to turn is most of what experienced use looks like.
| Situation | Do |
|---|---|
| Starting an unrelated task | /clear or a fresh session |
| Long session, still on the same task | /compact |
| Task is harder than expected | /model, raise effort one step |
| Task turned mechanical | /model, drop to gpt-5.6-luna |
| Unsure what is actually configured | /status |
| A command needs the network | Enable it deliberately, then turn it back off |
The escalation ladder
- Try it at the default.
gpt-5.6-solships atloweffort and is strong there. - If the first attempt misunderstood the problem, add context rather than effort. Usually it was missing a file.
- If it understood and still got it wrong, raise effort one step to
mediumorhigh. - If it is still wrong, the task is underspecified. Rewrite the prompt; do not reach for
xhighto compensate.
The Codex-specific surprises
| What you see | What it is |
|---|---|
npm install fails with a network error | The sandbox blocks network in workspace-write by design |
| It refuses to start in a folder | Not a git repository. That guard is deliberate. |
| Suddenly billed per token | OPENAI_API_KEY is set and overrides the subscription |
--full-auto is not recognised | Removed. Use -s workspace-write -a never. |
| A profile block stopped working | Profiles are separate <name>.config.toml files now |
Running more than one thing
Once the single-session rhythm is comfortable, the constraint stops being the model and becomes you: one agent finishes and waits while you read. The fix is more than one working tree, not more than one terminal in the same directory.
git worktree add ../proj-auth -b fix/auth-ttl
git worktree add ../proj-cache -b feat/user-cache
( cd ../proj-auth && codex "sessions expire an hour early; see internal/auth/token.go" )
( cd ../proj-cache && codex "add a 60s in-memory cache to GetUser" )git diff --cached | codex exec -m gpt-5.6-luna -
codex exec -s read-only -a never "which files changed most in the last 30 days?"Questions people ask
Install it, run codex in your repository root, sign in with ChatGPT, then run /init to generate an AGENTS.md. Explore in read-only mode before you let it change anything.
Something small you could do yourself in twenty minutes, so you can review the output properly. The first task is for calibration, not output.
Run /diff in the session, which includes untracked files. Read the diff itself rather than the explanation, and pay particular attention to deletions.
/diff shows you the changes. /review runs a dedicated review pass over them and reports issues it finds, focusing on behaviour changes and missing tests. Use /diff while working and /review before you push.
The workspace-write sandbox disables network access by default. Install dependencies before the session, or set network_access = true under [sandbox_workspace_write] when you genuinely need it.
When the model understood the problem and still got it wrong. If it misunderstood, add context instead. Running high by default costs several times more for work the default completes identically.
Yes, in small pieces. One commit containing four unrelated agent changes cannot be reviewed or reverted cleanly, and you will eventually want to revert exactly one of them.
Yes, with one git worktree per session so two agents never edit the same files. Running two sessions in the same directory produces conflicting edits that neither of them knows about.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.