The Ultimate Guide to Codex.

I'm new to OpenAI's Codex and deciding which surfaces to set up. Interview me, one question at a time, about:

1. My computer (Mac/Windows/Linux) and phone.
2. Whether I live in a terminal, an IDE, or neither.
3. The kind of work I want an AI agent for (coding, writing, file wrangling, automation).
4. My ChatGPT plan, if I know it.

Then recommend which Codex surfaces to set up this week (desktop app, CLI, IDE extension, cloud, mobile), in order, with one sentence on why each earns its spot. Keep the whole answer under 250 words.

I'm working through the Unlock AI guide to Codex at https://unlock-ai.natebjones.com/guides/codex — fetch it if you can browse.

Ask me three quick questions to locate me:
1. Is Codex installed and signed in yet?
2. Have I run a real task in one of my own folders?
3. What's the next thing I'm trying to get out of it?

Based on my answers, point me to the next one or two sections of the guide to do today, and give me a single concrete task to try in my own project that proves the section worked.

Help me sanity-check my ChatGPT plan for Codex usage. Facts as of June 2026: every plan includes Codex; Plus ($20/mo) allows roughly 15-80 GPT-5.5 messages or 20-100 GPT-5.4 messages per rolling 5-hour window; Pro ($100+/mo) raises that 5x-20x; an OpenAI API key is an alternative with usage-based pricing.

Interview me briefly:
1. What plan am I on now?
2. How many hours a week do I expect to use a coding agent?
3. Do I tend to run long autonomous tasks or short bursts?

Then tell me: does my plan fit, what usage pattern would make me hit the window limits, and what the first sign of needing an upgrade will look like. Verify current pricing at https://developers.openai.com/codex/pricing if you can browse, and flag anything that changed.

You are freshly installed. Run a first-launch audit and report back in a table:

1. Your app version and the model you're currently set to use.
2. Which account I'm signed in with (name the workspace/plan if visible to you, never paste tokens or keys).
3. Your current permission/approval mode and what it means for what you can touch.
4. Your current working directory (run pwd) and whether it's a generated scratch workspace or a folder I chose.
5. Whether the codex CLI is also installed (run: which codex && codex --version).

Make no changes. End with the one default you'd recommend I change first, and why.

Install the Codex CLI on this machine and verify it works.

1. Check if it's already present: which codex && codex --version.
2. If missing, install using the official method that fits this system best — curl -fsSL https://chatgpt.com/codex/install.sh | sh on Mac/Linux, or npm install -g @openai/codex if I clearly use npm for global tools. Tell me which you chose and why before running it.
3. Verify: codex --version, and confirm it shares my existing sign-in.
4. Finish by teaching me, in five lines: how to start an interactive session, how to run a one-shot task with codex exec, and how to switch models with /model.

If anything fails, show me the exact error and fix it before moving on.

This is a read-only reconnaissance task. Change nothing on disk.

1. Confirm your working directory and that you're in read-only mode.
2. Map this folder: what kind of project is it, what are the key files and entry points, what's generated vs hand-written?
3. Tell me three things about this codebase you'd want to know if you were about to work in it (conventions, traps, oddities).
4. Propose three small improvements, each one sentence, ranked by value. Do NOT implement any of them.

Format: a short overview paragraph, then the three findings, then the three proposals. If anything in the folder looks like a secret or credential file, name the path but never print its contents.

Give me a guided tour of this app, one element at a time. For each: what it's called, what it's for, and — where you can — demonstrate with a harmless action that changes nothing in my files.

Cover in order:
1. The composer and its three built-in controls: permission picker, model picker, project selector.
2. The sidebar: New chat, Search, Plugins, Automations, Pinned, Projects, Chats.
3. The side panel and each of its tabs (Files, Side chat, Review, Terminal, Browser) — one sentence each; we'll go deep later.
4. Settings: the three settings a new user should actually look at first.

Pause after each numbered group and wait for me to say "next". Keep each explanation under four sentences.

Help me set a model policy for this app. Current lineup as of June 2026: GPT-5.5 (frontier, complex coding and agentic workflows), GPT-5.4 (flagship for everyday professional work), GPT-5.4-mini (fast/cheap, good for subagents and chores). Reasoning effort can be low, medium, or high.

1. Tell me which model and reasoning level you're set to right now.
2. Ask me what my three most common task types are.
3. Give me a policy table: task type → model → reasoning level → one-line why.
4. Show me exactly how to switch (the picker in the composer, and /model in the CLI).

If the lineup has changed since June 2026, say so and use the current one instead.

Audit my permission settings against my actual usage.

1. State your current approval mode in this thread and what it permits.
2. Look back over our recent threads in this project: list the last five actions that required (or would have required) approval — file edits, commands, deletions.
3. For each, tell me which mode would have blocked it, allowed it with a prompt, or allowed it silently.
4. Recommend a mode for THIS project specifically, and name the one category of action I should always keep behind an approval, regardless of mode.

Don't change any settings yourself — tell me what to click.

Create an AGENTS.md for this project. Process:

1. Inspect the repo first: stack, structure, test setup, anything that looks like a convention.
2. Interview me, max six questions, about what you couldn't infer: commands to run and verify, code style I care about, files/folders that are off-limits, how I want changes proposed, anything that has burned me before.
3. Draft AGENTS.md with sections: Project overview · Commands that matter (build/test/lint) · Conventions · Boundaries (never touch) · How to verify your work before telling me it's done.
4. Show me the draft. After I approve, save it to the repo root.

Keep it under 60 lines. Rules an agent can act on, not aspirations — every line should change behavior.

Walk me through my Codex configuration.

1. Read ~/.codex/config.toml (if it doesn't exist, say so and explain what defaults are in effect).
2. Explain every key that's set, in plain language: what it does, whether it's a default or something custom.
3. Propose at most TWO changes that would genuinely help based on how I've been using you — e.g., a saner default model or reasoning level. For each: the exact line, what it changes, the risk if any.
4. Wait for my approval, then apply changes one at a time, adding a dated comment above each. Show me the diff.

Never print anything from the file that looks like a key, token, or credential — refer to those as [redacted].

This is your induction into a project I intend to use you in regularly. In order:

1. Map the codebase: structure, stack, entry points, how it builds/tests/ships. Narrate your understanding in plain language and flag anything confusing — I'll correct you, and the corrections matter.
2. Read any existing docs (README, AGENTS.md, docs/). Tell me where docs disagree with the code.
3. If there's no AGENTS.md, draft one (interview me briefly first). If there is one, propose improvements based on what you just learned.
4. End with three concrete first tasks you'd recommend, ranked: one quick win, one cleanup that lowers future friction, one thing that's wrong and should be fixed soon.

Change nothing without approval. The deliverable is shared understanding, not edits.

I want to run parallel work lanes in this repo. Set it up safely.

1. Ask me what the two (or three) workstreams are.
2. Judge honestly: which can run in parallel without touching the same files, and which should stay sequential. Tell me if my split is a bad idea.
3. For each parallel lane, create a Git worktree on its own branch (name them clearly), and tell me which thread should own which worktree.
4. Give me the rules of the road in five lines: where each lane works, how changes merge back, and the one command to clean up a finished worktree (git worktree remove, never rm -rf).

Confirm the worktree locations with me before creating anything.

Run a side-panel drill so I learn all five tools in one pass. Do a deliberately small task — create a single self-contained HTML page in this folder called hello-panel.html with a heading and one button — and as you work, tell me when to look at each panel:

1. Files: show me where the new file appears and what changed.
2. Terminal: run a harmless command (like listing the folder) so I see command output streaming.
3. Review: walk me through the diff of what you created before I accept it.
4. Browser: open hello-panel.html so I can see and click the result.
5. Side chat: tell me to ask you "why did you structure the HTML that way?" in the side chat, and answer it there.

Narrate each step in one or two sentences. The task is trivial on purpose — the panels are the lesson.

I'm about to do my first annotation pass on the page that's open in your browser panel. Help me make it a clean rep:

1. Confirm you can see the page and tell me its URL or file path.
2. After I send a batch of annotations, restate each one back to me: the element, what I asked for, and what you'll change in the code.
3. Make the changes, then reload the page and summarize what's visibly different.
4. If any annotation was ambiguous, say what you assumed instead of guessing silently.

When we're done, tell me one way to write sharper annotations next time.

I want to see goal-and-child-thread orchestration on a real but small piece of work.

1. Ask me for a goal that has 2-3 separable steps (if I don't have one, propose one for this project that touches nothing risky).
2. Create the goal with concrete success criteria — what done looks like, verifiable.
3. Draft the plan as numbered steps. Keep this parent thread for plan, coordination, and review only.
4. Execute step one by creating a child thread for it. Tell me when the child starts and summarize its result here when it finishes.
5. End by telling me the status of the goal: what's done, what's next, what you need from me.

Narrate the mechanics as you go — I'm learning the pattern, not just shipping the task.

Help me create my first Codex skill using $skill-creator (or manually if that's unavailable).

1. Ask me: what instruction do I keep repeating to you? That's the skill.
2. Ask whether it's personal (install to ~/.codex/skills) or project-wide (install to .agents/skills in this repo).
3. Write the SKILL.md: frontmatter with a kebab-case name and a description that says exactly when the skill SHOULD and SHOULD NOT trigger, then the instructions as numbered steps with any guardrails.
4. Install it, then prove it works: invoke it by name ($skillname) on a tiny example and show me the result.
5. Tell me how to edit it later and how to tell whether it's actually triggering when it should. No secrets in the skill file, ever — reference environment variables or local config instead.