Codex·4 min read

Writing instructions for Codex: it asks nothing, so say it up front

Codex asks no questions along the way. It fills in missing details itself and delivers something. Here is how to write an instruction that makes those assumptions land the right way.

Add a contact form to the Contact page with name, email address, phone and
message. Send it to info@mysite.com, with a thank you page after submitting.
Spam protection without an external service. Do not invent fields I did not
mention and do not touch the rest of the page.

That last sentence is the whole article. In our assistant, Codex works in one mode: it carries out your instruction and then shows you what changed. It does not stop halfway to ask which email address you meant. If something is missing, it fills it in itself and carries on. That makes it fast, and it means the quality of your result largely sits in your instruction.

With Claude Code you can decide per change. See Claude Code or Codex for that difference. This article is about the other path: you give Codex everything up front.

What carrying on with assumptions means

Three things we see happen in practice:

It invents a plausible detail. Ask for a form that sends email without naming an address, and it picks one that fits your domain. That is almost right, and therefore easy to miss.

It switches nothing off. If a key or a setting is missing, it builds the feature anyway, assuming you will fill in the rest later. So you do not get a "this was not possible" message, you get something that looks finished.

It works around a blockage. If a tool hits the edges of its sandbox, it does the work by hand. That often works, but the result looks different from what our own tooling would have produced. That is exactly what happens in the sandbox; see The Codex sandbox: what workspace-write means.

None of the three is bad behaviour. It is the price of an assistant that does not ask a question every two minutes.

Four things that belong in every instruction

1. The details, literally. Addresses, phone numbers, prices, opening hours, the company name. Anything it cannot know, you put in. Add a line if you like: "use exactly these details, do not invent any".

2. The boundary. Say what it must not touch. "Only the Contact page." "The rest of the theme stays as it is." "Change nothing in the database." This is the most important rule, because an instruction without a boundary often turns into a renovation.

3. What you expect if it cannot be done. "If you cannot do this without an external service, stop and explain why." Without that sentence it will pick a way forward itself.

4. How you are going to check. "Take a screenshot of the page on mobile and desktop when you are done." Then you do not have to go and look first.

A plan first, then the work

The trick that helps most on a big job: ask it to do it in two instructions.

Look at the Contact page and the rest of the theme. Write down what you
would do to put a working contact form in it: which files, which choices,
what you are unsure about. Do not change anything yet.

You read the plan, you fill in the open points, and only then do you give the build instruction. It costs two minutes and removes exactly the assumptions you would otherwise be repairing afterwards.

You can always roll back

Every instruction gets a snapshot before it starts. If the result turns out wrong, you roll the whole instruction back in one go. That works even when it touched many files.

Also read the card that appears after the instruction. It shows the differences per file, including changes it made from the command line. Large bulk actions, such as installing a package with hundreds of files, are summarised as a list instead of file by file. If you find something you did not expect, you know it before your site has been live for a day.

Common mistakes

"I was waiting for a question that never came." Codex asks nothing along the way. If you would rather be asked at each step, pick Claude Code in the bar above the chat.

"The form emails an address that does not exist." A classic assumption. Name the address in your instruction and have it send a test message after building.

"It rewrote my entire page." The instruction had no boundary. Roll the instruction back, add the line about what must not change, and try again.

"It says it is done, but half of it does not work." It finishes when it believes the instruction is complete. Ask for a check in the same instruction: a screenshot, a test message, a list of what it verified.

"I gave a ten line instruction with five different wishes." That works worst of all. It will pick its own order and its own interpretation. Cut it into steps, or ask for the plan first.

MK
Maarten Keizer

Founder of Invoker. Over twenty years in hosting, system administration and web development; builds the Claude hosting himself and tests everything on our own servers first.

about maarten