Codex core workflow tutorial: entry points, execution env, context, permissions, and deliverables

Codex isn’t “a chat box that can write code”; it’s an agent workflow that can enter a real project and execute tasks. The key to understanding it is to get five stages clear.

1. Entry point: four places, one brain

Entry point	Best for
App	quickly assign work without opening a terminal; visually review diffs
CLI	batch ops, scripting, can go into CI
IDE extension	edit while you write, can see cursor context
Cloud	scheduled/background tasks, doesn’t occupy your local machine

They differ not in capability but in where you see the results. Pick one that overlaps with how you work; you don’t have to use them all.

2. Execution environment: where it actually runs

This is the easiest to overlook, and the easiest to break.

• Local mode: reads and writes your working directory directly; fast, but touches your files
• Cloud sandbox: isolated environment; safe, but can’t reach uncommitted local code

The criterion: does the task need access to local changes that haven’t been pushed? If yes, local; if no, cloud.

3. Context: what it “sees”

An agent’s ceiling is set by context quality. Three ways to supply it:

# Explicitly specify a directory
codex --add-dir ./src

# Let it find on its own (slow, but broad coverage)
codex "Find all code that handles payments"

# Structured context (recommended)
# Keep an ARCHITECTURE.md and have it read it first each time

The third is the least effort. Spend half an hour writing a project-structure note and you save dozens of repeated explanations later.

4. Permission boundary: let go of what you should

Codex permissions usually come in three tiers: read-only / needs confirmation / auto-execute.

Recommended practice:

• Read, search, run tests → auto-execute
• Edit files → needs confirmation
• Delete, force-push, install global packages → never automatic

The essence of permission config is writing out explicitly “what I don’t trust it to do,” not clicking confirm by feel.

5. Delivery: how to accept it

What an agent delivers isn’t an “answer” but a set of changes. Acceptance checks three things:

1. diff: which files did it actually change; did it touch anything unrelated on the side
2. runnability: were tests run, was it built
3. rollback-ability: can this change be reverted with one command

git diff --stat     # check the scope first
git stash           # revert if wrong

Putting it together: a complete loop

clarify goal → scope context → assign task → review diff → accept/rollback → distill into memory

Most people get stuck at step 2 and step 4. Context given too casually and the agent guesses; commit without reviewing the diff and errors accumulate.

Final advice

First use Codex for things you were going to do anyway, but that don’t matter much. Once it runs smoothly, hand it the important stuff.

Get this order backwards and you’ll get a pile of output that looks industrious but is actually unusable.