TL;DR
Claude Code, Codex and Cursor each have a planning mode, yet users still report plans turning into code before anyone accepted them, and a mode is session state rather than a record of your decision. Ask for a plan you could reject, answer the questions that change scope before calling it ready, record approval against that exact plan, and make the edit tool check the record where your host can block edits. Where it cannot, restrict writes and review the diff against the plan.
Implementation that started before anyone said yes
In November 2025 a Cursor user reported on the Cursor forum that they had been designing a plan in Plan Mode, walked away from the laptop, and came back to find the agent implementing it. Asked why, the agent quoted an instruction to implement the plan that the user says they never wrote, and explained that it had received that text as a user message. A Cursor staff member called it a confirmed bug and restated the expected behaviour: Plan Mode should create a plan and wait for explicit approval before running anything. A second user added a similar report a few days later.
In June 2026 a Codex user asked on the OpenAI developer forum whether there is a recommended way to make Codex stop before patching, list the exact files it plans to change and wait for approval, because instructions such as "wait for approval before patching" were no longer reliably followed.
In both, the person believed the work was still a proposal, while the agent had already moved on to building it.
What plan modes actually hold back
All three tools document a planning mode, and the documentation (checked on 1 October 2026) describes different guarantees.
Comparison
| Claude Code plan mode | Codex Plan mode | Cursor Plan Mode | |
|---|---|---|---|
| During planning | Reads files, runs exploratory shell commands and writes a plan; source edits stay blocked until you approve | Gathers context, asks clarifying questions and builds a plan before implementation | Researches the codebase, asks clarifying questions and produces a plan you can edit |
| How building starts | You choose an approve option, which switches the session's permission mode | Not described on the pages checked; a user report mentions an offer to proceed with implementation | You click to build the plan |
| What holds edits back | The mode itself, except in interactive terminal sessions where bypass permissions are available | For planning with no changes at all, the docs point to the read-only sandbox via /permissions | Not described beyond the mode |
Two things follow. First, a mode is state inside one session, and none of these pages describes a stored record of which version of the plan you accepted; Claude Code lets you edit the plan before approving (permission modes) and Cursor saves plans as Markdown files (Plan Mode), but the approval itself is a click. Second, the boundary can slip. Open user reports describe Claude Code making edits without leaving plan mode and the Codex app switching from Plan to Default without an explicit change. They are unconfirmed reports, not measured failure rates, but they are a reason to keep a second check that does not depend on the mode.
Write the plan as something you can say no to
A plan earns approval only if it contains enough to reject. "Update the service and add tests" gives you nothing specific to object to. Ask for these parts, in a file you can read and comment on:
- Outcome and non-goals. What will be true afterwards, and what this change deliberately leaves alone.
- Files and modules. The ones it expects to change and any it will create, so scope can be checked later.
- Contracts it touches. Public interfaces, schemas, migrations, configuration and new dependencies, each named.
- Ordered steps. Each tied to the requirement it serves, so a step with no reason stands out.
- Risks and rollback. What could break, how each risk is handled and how the change would be undone.
- Proof. Which tests or checks will show each requirement is met.
- Open questions and assumptions. Listed separately, never silently answered inside a step.
The files and contracts lines do the most work at approval time, because they are what you will compare the diff against. The article on how much specification an AI coding agent needs goes further into what to settle before the agent starts.
Questions that have to be answered before the plan is ready
Codex and Cursor both describe their plan modes as asking clarifying questions. Some of those can be left to the agent; others are commitments that belong to you. A plan with an open question of the second kind is not ready, however complete the rest looks.
Decision guide
- If the answer changes what a user sees or is allowed to do, you answer it.
- If it changes stored data, a schema or a migration, you answer it.
- If it changes a public interface or behaviour other code depends on, you answer it.
- If it adds a dependency, service, credential or permission, you answer it.
- If it chooses between reusing existing code and writing new code, you answer it, or at least confirm the agent's choice.
- If it concerns private naming or the order of internal steps, the agent can decide, as long as the plan says what it decided.
The last line matters as much as the others. An agent that resolves an ambiguity by assumption should write the assumption down, so that approving the plan means approving the assumption too.
Record the approval, and say what voids it
An approval you can check later names four things: who approved, when, exactly which plan, and the scope it covers. The simplest form is a few lines committed next to the plan file. The example below is an illustrative format, not output from any tool:
The hash ties the record to one version of the plan, but it only shows that the plan has not changed since the record was written; it does not show who wrote the record. If the agent can write both the plan and the record, a matching hash proves nothing about approval. Keep the trusted record where the agent cannot write it, such as a commit you sign, a review approval you give yourself or a path its permissions deny, and decide who else may change it. Then decide in advance what voids it:
- The plan file changes after approval, for any reason.
- The work needs a file or contract the plan did not list.
- A new dependency, migration or permission appears.
- An answered question turns out to have a different answer.
A new session does not void the approval by itself, but it should recheck the record and the plan's hash before its first edit, because it never saw the approval happen. When one of the listed changes happens, the agent goes back to planning and you approve the amended plan, which is quicker than it sounds if you review only the diff between the two versions.
Make the edit tool check the record
Instructions and modes ask the agent to wait. A boundary is a check the host runs whatever the agent believes. Claude Code and Codex both run PreToolUse hooks before tool calls, including file edits (Edit and Write in Claude Code, apply_patch in Codex), and a hook can deny the call (Claude Code hooks, Codex hooks). A hook that refuses edits unless a trusted approval record exists and its hash matches the current plan file is a real boundary on those paths, provided the same hook or the permissions also refuse writes to the record itself. Three limits apply: shell commands are a separate path, so match Bash as well or restrict it through permissions; Codex notes that for MCP-based hooks an error or timeout lets the tool run, so test how your hook fails; and an open Codex report says the hook's permission_mode field does not report plan during Plan-mode turns, so key the check on the record rather than on the mode. The article on checking that an agent loaded the project instructions before editing uses the same pattern for a different record.
Where your host offers no blocking hook, use what it does enforce. In Codex, plan in the read-only sandbox. In Claude Code, choose "Yes, manually approve edits" when you accept a plan, so each edit still asks. Everywhere, compare the final diff with the files and contracts the plan listed before you keep it.
Paqad applies this pattern on Claude Code and Codex CLI. Its hooks refuse a covered source edit until planning has a compiled plan.json on record and, on its graduated and full lanes, until a specification has been frozen with a named sign-off; they also freeze edits while a decision waits for your answer, and a specification that changes mid-build reopens a decision. A recorded plan is not by itself your approval: the fast lane requires only the recorded plan, the sign-off name is recorded rather than authenticated, and shell writes and Paqad's other supported tools are not blocked. Paqad's guardrails page lists what each tool can stop and what it cannot.
Frequently Asked Questions
How do I keep an AI coding agent in planning until the implementation is actually approved?
Decide where approval lives before the session starts. If the only signal is a click inside the session, nobody can tell afterwards which plan was accepted. Making planning the default helps too: Claude Code, for example, can start every terminal session for a project in plan mode through defaultMode in .claude/settings.json.
What should the planning output contain so I can make an informed decision?
The seven parts in the checklist, in a file under version control so that comments and later amendments show up as diffs. If the plan will not fit on a page or two, treat that as a sign the change is too large to approve in one decision and ask for it to be split.
Which ambiguities require my answer before the plan is considered ready?
Anything that commits users, data, interfaces, dependencies or the reuse of existing code. Keep a short log of how you answered, so the next plan in the same area can cite your earlier decision instead of asking it again or, worse, guessing differently.
How should approval be recorded, and what changes should invalidate that approval?
Record who, when, the plan's hash and its scope, and commit the record with the plan so the pull request carries both. Any change to the plan, any edit outside its listed scope, or any new contract voids it; re-approve by reviewing the difference between plan versions rather than rereading the whole plan.
What protects the boundary between an approved plan and an unapproved action on my actual coding host?
Only checks your host actually runs: a blocking edit hook, a read-only sandbox or per-edit approval. Test it rather than trusting the configuration: attempt an edit before approval and confirm it is refused, and repeat after upgrades, since defaults move. Claude Code v2.1.283, for instance, made auto mode the starting permission mode for interactive sessions.