TL;DR
OpenAI's Codex CLI puts a coding agent in your terminal: it reads your repo, edits files, and runs your tools without leaving the command line. Most people stall at the first prompt and never come back. Here is the afternoon setup that makes it useful — install, prompt with a shape, teach it your repo once, trust it in stages, and automate what repeats.
Install it and sign in
On Mac or Linux, run `curl -fsSL https://chatgpt.com/codex/install.sh | sh`. On Windows, open PowerShell and run `powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"`. Prefer a package manager? `npm install -g @openai/codex` works anywhere Node does, and Mac users can `brew install --cask codex`. Then just run `codex` to start it.
Sign in with your ChatGPT account — Plus, Pro, Business, Edu, and Enterprise plans all cover Codex. An API key works too, but that needs extra setup, so start with the ChatGPT sign-in. One habit from the beginning: always launch it inside the project with `cd ~/your-project && codex`. It works against your local repo — reading files, making edits, running the tools you already have installed.
Prompt with a shape, not a sentence
Codex is useful even with a sloppy prompt, but a little structure makes it far more reliable, especially in a big codebase. Give every task four parts: the goal (what are you building or changing), the context (which files, folders, docs, or errors matter — you can @-mention files), the constraints (standards and conventions it must follow), and done-when (what must be true before it stops: tests pass, the bug no longer reproduces). That keeps it scoped and easier to review.
For anything complex or fuzzy, plan before it codes. Hit `/plan` or Shift+Tab for Plan mode and it will gather context, ask clarifying questions, and build a stronger plan first. Or just tell it to interview you: describe the rough idea and have it challenge your assumptions until the task is concrete. Match the reasoning effort to the job — Low for fast, well-scoped tasks, Medium or High for harder changes and debugging, Extra High for long agentic runs.
Teach it your repo once with AGENTS.md
The highest-leverage file in the whole setup is AGENTS.md — an open-format README for agents that loads into context automatically. Run `/init` in your repo and Codex scaffolds a starter one, then edit it to match how you actually build: repo layout and important directories, build/test/lint commands, engineering conventions, do-not rules, and what “done” means with how to verify it. A short, accurate file beats a long vague one.
You can layer these: personal defaults in a global AGENTS.md under `~/.codex`, shared standards at the repo root, tighter rules in subdirectories — the closest file to your working directory wins. And keep it alive: when Codex makes the same mistake twice, ask it for a retrospective and add the rule. Only add guidance after real friction, not before.
Trust it in stages
Codex ships with two knobs that matter: approval mode (when it must ask before running a command) and sandbox mode (what it can read or write). Start with the defaults — tight — and only loosen permissions for trusted repos once the workflow is clear. Use `/permissions` to set the boundaries for each run and inspect what sandbox is active before you continue.
Build review into the loop. The `/review` command checks your work without modifying it: against a base branch for PR-style review, against uncommitted changes, against a specific commit, or with your own custom instructions. Tell it to write or update tests, run the checks, and confirm the behavior matches the request before you accept anything. Two mistakes to skip from day one: never grant full machine permissions before you understand the workflow, and don't run live tasks on the same files without git worktrees.
Automate what repeats
Once the interactive loop works, take it off your hands. `codex exec "your task here"` runs the same agent non-interactively — built for scripts, cron jobs, and CI pipelines. Keep chats organized: `codex resume` reopens a recent session, `/compact` summarizes a long one, and the standing rule is one chat per coherent unit of work. A whole project crammed into one chat bloats context and gets steadily worse results.
When you catch yourself retyping the same prompt, package it as a skill: a SKILL.md file that says what it does and when to use it. The `$skill-creator` skill scaffolds one for you. Personal skills live in `$HOME/.agents/skills`; team skills get checked into `.agents/skills` in the repo so new teammates inherit them. The docs' rule of thumb is worth memorizing: skills define the method, scheduled tasks define the schedule — and only schedule a workflow once it is reliable by hand.