Note
August 2, 2026
2 min read
When Codex Starts Before I Say Go
By Cristiano Pierry
Codex needs to distinguish between work it is asked to prepare and work it has been authorized to begin.
I have run into the same problem with Codex several times this week. I ask it to help me plan the work, then discover that it has already started doing it.
The latest example happened while I was preparing a new presentation. I asked Codex to review the interaction, improve the plan, and prepare a /goal for the work ahead. I expected an updated plan and a goal I could inspect before running it. Instead, Codex started building the presentation.
The prompt was not perfect. It described what the future goal should accomplish, including carrying the work through from beginning to end. But those instructions were part of the thing I had asked Codex to prepare. They were not my signal to begin.
A useful plan will say what needs to be reviewed, built, and tested. I cannot remove every action from it just to keep Codex from starting early.
Something similar happened in another task this week. We had explicit resource limits intended to keep my computer from crashing. Codex had those instructions and kept going without following them.
Both times, Codex kept moving toward the outcome and treated the boundary as something it could interpret for itself. That decision should remain with me.
The obvious workaround is to add “DO NOT EXECUTE” to every planning request. That puts the burden back on me. A /goal I ask Codex to prepare needs to wait until I start it. Once the work begins, the limits already in place still have to mean something.
Once I say go, persistence is exactly what I want. Codex should keep working, test its output, and recover from ordinary failures. I just should not have to end every planning prompt with “DO NOT START.”
This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.