Codex · Practical walkthrough

Ask Codex for a plan before it changes your files

"Tidy this up and delete the old stuff" leaves a lot to guess, and one of the guesses involves deleting things. Get a plan that names what changes and what stays before anything disappears.

Task by Task12 min read + practice

What you'll make

a reviewed Codex plan for one new summary file, with a vague “delete the old stuff” instruction resolved before anything changes.

What you'll need

Codex (in the ChatGPT desktop app or the CLI), a small folder you’re allowed to work in, and about 15 minutes. The enquiry practice folder (ZIP) works as a first input. This is part 1 of the Codex practice series: 1. ask for a plan, 2. build a small CSV helper, 3. understand the files Codex changed.

Example result.

Plan (nothing changed yet)
Read:     enquiries.csv, definitions.txt
Create:   summary-practice-v1.md
Leave:    summary.json (owner unknown) and all source files
Unclear:  "delete the old stuff" could mean summary.json. Not doing this without a decision.
Checks:   5 enquiries; email 2, phone 2, web 1; 4 recorded minute values totalling 25;
          1 missing value, so the full total stays unresolved

1. Prepare one folder, then start Codex read-only

Make a new folder for this job only and copy in just the files it needs. For the practice ZIP, extract its three files (enquiries.csv, definitions.txt and README.txt) into that folder. Don’t point Codex at your whole Documents folder to find three small files. In the ChatGPT desktop app, open that folder and choose Codex; in the CLI, start Codex from inside it.

The setting is the control; the words in your prompt are a backstop. In the CLI, start with codex --sandbox read-only --ask-for-approval on-request, so Codex can read the folder but has to stop and ask before doing more. If you use a config file, the built-in :read-only permissions profile does the same. In the app, the composer’s /plan command asks for a plan first; check the session’s permissions before you start.

Why this works: a prompt that says “don’t change files” is an instruction the model should follow. A read-only sandbox is a limit it can’t cross.

What you should see: Codex open on a folder containing only the job’s files, unable to write without asking.

2. Describe the result and ask for a plan

Name what you want at the end, the source files and anything that must stay as it is. Keep the result small enough to check: one new summary is easier to review than a reorganised folder.

Inspect this folder and propose a plan before making changes. The
result should be [output and purpose], using [source files]. Keep
[files that must not change] as they are.

List each file you would read, create, edit, rename or delete, and why.
Point out vague instructions, possible overwrites, missing sources and
any decision I need to make. Propose checks using [expected answers].
Do not change, delete, install, commit, push or deploy anything yet.

[output and purpose] is the file you want; [source files] are the inputs; [files that must not change] protects existing work; [expected answers] are a few results you already know are right.

Why this works: splitting read, create, edit, rename and delete exposes a big change hiding inside a small-sounding request.

What you should see: a plan like the example result, with a separate line for anything unclear.

3. Approve only the next concrete step

When the plan passes the checks below, say exactly what Codex may now do, and nothing more.

Proceed with the reviewed plan: create only [new file]. Keep all source
files and existing outputs unchanged. Run the agreed checks and report
the output path, what changed, the check results and any gaps. Do not
rename, delete, commit, push or deploy anything.

[new file] is the one output the plan agreed.

Then open the new file and compare it with the sources yourself. A plan is a proposal; it doesn’t prove the work was done or the checks passed.

Why this works: approval for one named file is easy to check afterwards. Approval for “the plan” isn’t.

What you should see: one new file, an unchanged folder otherwise, and a report you can check.

Check the result

Every file the plan will delete or overwrite is named, with a reason you agree with.
The new file’s name doesn’t already exist in the folder. If it does, pick a new name rather than replacing a colleague’s file.
Vague instructions (“old”, “tidy”, “clean up”) are listed as decisions, not actions.
The checks use answers you worked out yourself, not ones Codex will calculate.
After step 3, only the agreed file is new; nothing else has changed.

The usual failure: the plan treats a vague word as permission. “Old” becomes a list of files to delete, and “update the summary” becomes an overwrite of someone else’s file. Spot it by reading the delete and edit lines first and asking, for each one, who said so.

Change the plan: keep all existing sources and outputs. Create only
[new file]. Do not act on the instruction [vague instruction]. Update
the plan and checks to match, and stay read-only.

[new file] is the new output’s name; [vague instruction] is the phrase Codex treated as permission, quoted.

Worked example: “delete the old stuff”

Fictional example. The request is “Make an enquiry summary and delete the old stuff.” The folder holds enquiries.csv, definitions.txt and an existing summary.json that nobody remembers creating.

Codex’s first plan included:

Delete:     summary.json (older output, superseded by the new summary)
Overwrite:  summary.json with the full duration total of 25 minutes

The failure. Nothing says summary.json is disposable; its owner is unknown. And “the full duration total of 25 minutes” ignores the one missing value in the data, so 25 is the recorded total, not the full one.
The repair. The repair prompt, with summary-practice-v1.md and “delete the old stuff”, produced the plan in the example result: a new file, summary.json left alone, and the full total marked unresolved.
The outcome. After clarification, nothing needed deleting for this job. Step 3 then created only the new file, and its counts matched the checks.

Task kit for this job: Download (ZIP) · Reusable instructions

Go deeper

Write the checks before the code

Work out the expected answer from a small source by hand before reviewing anything Codex produces: here, five enquiries and a recorded total of 25 minutes with one value missing. Don’t change the answer key to make the output pass. If the definition itself needs to change, that’s a separate decision for whoever owns it.

Keep the instruction and the permission separate

A plan request is a task instruction. The sandbox and approval settings decide what Codex can actually do. Check both before you start, and widen permissions only for the step that needs them, such as --sandbox workspace-write when you’ve approved creating a file. The permissions guide lists the built-in profiles.