Do We Still Need Plan Mode? Planning vs. Autopilot in Codex, Claude Code, and GitHub Copilot

Plan Mode used to solve an obvious problem: coding agents were too eager to edit. Ask for a feature, and the agent might start changing the first plausible file before it understood the architecture, the edge cases, or even what “done” meant. A separate planning phase forced it to slow down.

That argument is less convincing now. Modern coding agents already inspect repositories, decompose work, run tests, revise hypotheses, and choose their next action during ordinary execution. GitHub Copilot has an explicit Autopilot mode. Claude Code has Auto mode and several ways to approve a plan into more autonomous execution. Codex can turn an uncertain request into a plan and then track a durable goal through long-running work.

If agents can plan for themselves, do we still need a Plan Mode button?

The short answer is yes—but not for the reason we used to.

Plan Mode is no longer necessary to make the agent think. It is useful when the human needs to inspect and influence that thinking before implementation begins.

For a small, reversible, well-specified change, forcing a separate planning ceremony often wastes time and context. For an ambiguous migration, a cross-system feature, or a change with a large blast radius, an explicit plan remains one of the cheapest places to catch a wrong assumption.

The useful question is therefore not “Should I always use Plan Mode?” It is “Is there a decision here that I need to review before the agent acts?”

Planning, Plan Mode, permissions, and autonomy are different controls

The terminology becomes confusing because agent products mix four separate concepts.

Planning is a reasoning activity

Any capable agent may form a sequence of intended actions: inspect the request path, identify the responsible module, change the schema, regenerate types, update tests, and verify the result. That plan may remain internal, appear as a short checklist, or change continuously as the agent learns.

Autonomous execution does not mean execution without planning. It means the agent is allowed to create, revise, and follow that plan without stopping for human agreement at every boundary.

Plan Mode is a product workflow

Plan Mode makes planning a visible phase. The agent explores, asks questions, and proposes an approach before implementation. Depending on the product, source edits may be blocked by the interface or permission system until the plan is approved.

The important output is not merely a list of steps. It is an alignment checkpoint: assumptions, scope, architecture, risks, and verification become reviewable before they turn into code.

Permission modes control actions

A permission mode answers questions such as: Can the agent edit files automatically? Can it run shell commands? Which paths or tools require approval? Is a safety classifier reviewing actions in the background?

An agent can have a detailed plan and restrictive permissions. It can also have no human-reviewed plan but broad permission to act. Planning quality and execution authority are related, but they are not the same setting.

Autonomy controls continuation

Autonomy determines whether the agent can keep taking model-driven steps without waiting for another user message. GitHub calls this Autopilot in Copilot CLI. Claude and Codex expose different combinations of long-running work, automatic permissions, goals, and agent behavior rather than sharing one cross-vendor “autopilot” standard.

Treating every automatic mode as equivalent hides meaningful safety and workflow differences.

How the three products draw the boundary

The closest thing to a literal Plan Mode versus Autopilot comparison exists in Copilot CLI. GitHub also supports plan-then-autopilot with --plan --mode autopilot. In that configuration Copilot begins by producing a plan, then automatically progresses into autonomous execution without waiting for human approval.

That feature reveals the central issue. A planning phase and a review gate are separable. The agent can plan first without the human ever reviewing the plan.

Codex: plan an unclear outcome, then turn it into a goal

In Codex, /plan switches the active chat into Plan Mode. It can also take an inline request:

/plan Propose a migration from session cookies to rotating access tokens

The official command reference describes this as asking Codex to propose an execution plan before implementation begins. Once the objective is clear, /goal provides a different contract: the goal text becomes both the initial prompt and the completion criteria for longer-running work.

OpenAI's long-running work guidance explicitly recommends starting with /plan when the outcome is unclear, asking Codex to identify constraints and measurable success criteria, and then using the refined result as a goal. A good goal includes the outcome, constraints, and verification:

/goal Replace session cookies with rotating access and refresh tokens. Preserve existing clients during the transition, add replay protection, document the migration path, and make the authentication test suite pass.

Goal Mode does not grant broader access. The existing sandbox and approval policy still applies, and the work can pause when a decision is required. The practical split is:

• use Plan Mode to negotiate what the work should be;
• use Goal Mode when Codex can independently pursue a sufficiently precise definition of done;
• keep normal interactive execution for short tasks that do not need either ceremony.

OpenAI's Codex command reference documents /plan and /goal, while the long-running work guide explains how to move from an unclear request to a verifiable goal.

Claude Code: Plan Mode and Auto answer different questions

Claude Code makes the distinction between planning and permissions especially visible. Its Plan Mode tells Claude to explore and propose changes without editing the source. You can enter it with Shift+Tab, a single /plan request, or at startup:

claude --permission-mode plan

When the plan is ready, Claude can offer several exits:

• approve and start in Auto mode;
• approve and accept file edits automatically;
• approve but review each edit manually;
• continue planning with feedback;
• refine the proposal through a deeper planning workflow where available.

This is a useful product design because plan approval does not silently decide the permission policy. You may agree with the architecture while still wanting command-by-command approval. Or you may approve the plan and let Claude execute with fewer interruptions.

Claude's Auto mode is not an autonomous planner in the narrow sense. It is a permission mode that lets actions proceed without ordinary approval prompts while background safety checks evaluate alignment and block certain risky actions. Claude will still reason and revise its approach during execution, but “Auto” principally describes how tool calls are authorized.

Bypass permissions is broader and removes that protection. Anthropic recommends it only in isolated environments. This is another reason not to collapse “autonomous,” “automatic permissions,” and “has a plan” into one concept.

The current modes and their transition behavior are documented in Claude Code's permission mode guide .

GitHub Copilot: Plan Mode, Autopilot, and the missing approval

Copilot CLI provides the cleanest experiment for this article because users can cycle between standard, plan, and autopilot modes with Shift+Tab.

In Plan Mode, Copilot can explore the codebase and create a structured plan while direct attempts to edit project files are blocked. The restriction extends to delegated helpers. GitHub describes this as a practical safety net rather than an airtight security boundary: connected external tools and commands whose effects cannot be determined perfectly may still require judgment.

After approval, Copilot can implement the plan. Autopilot goes further by allowing the agent to continue through successive model-driven steps without waiting for user input after every step. It stops when the task is complete, progress is blocked, the user cancels, or an optional continuation limit is reached.

The ordinary high-control workflow is:

1. Enter Plan Mode.
2. Review questions, assumptions, and the proposed implementation.
3. Approve the plan.
4. Choose Autopilot for execution.
5. Review the resulting diff and verification evidence.

Copilot also supports:

copilot --plan --mode autopilot

This is plan-then-autopilot. Copilot still plans before editing, but it automatically moves into Autopilot when the plan is ready. The human review checkpoint disappears.

That can be ideal for an automated harness where planning improves execution quality but no person is expected to sit at the terminal. It is a poor substitute for explicit review when product requirements, data migrations, security boundaries, or API compatibility still need human judgment.

GitHub documents the mechanics in the Copilot CLI command reference , Plan Mode best practices , and the Autopilot guide .

What explicit Plan Mode still does better

It exposes assumptions before they become code

Implementation often hides an early misunderstanding under many locally reasonable decisions. A reviewed plan makes statements such as “the old endpoint will remain available,” “the migration is additive,” or “the frontend will consume the generated type” visible while they are still cheap to correct.

It separates product decisions from implementation decisions

Agents are increasingly good at deciding how to code a chosen behavior. They should not silently decide every product policy. Retention periods, compatibility promises, authorization boundaries, rollout strategy, and acceptable data loss are not ordinary implementation details.

It gives teams a reviewable artifact

A plan can be shared with a frontend owner, security engineer, or database maintainer before one agent modifies all three layers. The value is coordination, not model intelligence.

It limits sunk-cost bias

Once an agent has changed twenty files and made most tests pass, humans become reluctant to reject the approach. Reviewing the plan first makes “wrong direction” a small correction instead of a painful rewrite.

Where Plan Mode becomes expensive ceremony

Plan Mode is not free. It consumes time and context, can duplicate exploration the agent performs again during implementation, and creates a document that may become stale after the first unexpected test failure.

It is usually unnecessary for tasks such as:

• correcting a clear typo;
• adding a focused regression test for an already-understood bug;
• updating one dependency under an established upgrade procedure;
• making a small visual adjustment with an immediate screenshot check;
• applying a mechanical change whose scope and verification are deterministic.

A long plan for a five-line reversible change is not rigor. It is latency.

Plans also create false confidence. A polished checklist can still rest on incomplete repository exploration. The safest workflow does not trust the plan because it looks comprehensive; it verifies the implementation with tests, types, diffs, runtime behavior, and domain review.

What autonomous planning does better

Autonomous execution keeps the plan close to new evidence. The agent can reproduce a failure, discover that the initial hypothesis was wrong, inspect another module, revise the approach, and continue without asking the user to approve a document that is already obsolete.

This is particularly effective when:

• the desired outcome is precise;
• the repository has strong tests and deterministic checks;
• the change is easy to revert;
• established project instructions constrain the implementation;
• the agent operates inside a worktree, sandbox, container, or other limited environment;
• no unresolved product or architecture decision is hidden inside the task.

The price is reduced visibility into early decisions. By the time the human sees the result, the agent may have selected an architecture, expanded the scope, or made a compatibility tradeoff that was never explicitly discussed.

Autonomy works best when the outcome and boundaries are explicit even if the path is not.

Four practical workflows

1. Small bug: skip Plan Mode

Reproduce the failing null-state test, identify the smallest root-cause fix, implement it, run the focused test, and summarize the diff. Do not refactor adjacent code.

The task is narrow, reversible, and verifiable. Let the agent plan internally.

2. Ambiguous feature: review the plan

Plan an audit-log export feature. Before proposing implementation, identify the expected users, export formats, retention and authorization assumptions, expected data volume, and whether generation should be synchronous. Do not edit files.

The unanswered questions change the architecture. Human review is worth the delay.

3. Large migration: plan, approve, then run autonomously

Create a migration plan from REST polling to server-sent events. Include compatibility phases, observability, rollback, affected clients, test strategy, and measurable completion criteria. After approval, implement each phase autonomously but stop if the compatibility assumptions prove false.

This combines strategic review with efficient execution.

4. Production incident: remain interactive

Investigate the elevated checkout error rate. Gather evidence and maintain a ranked hypothesis list. Do not change production state, deploy, rotate credentials, or modify data. Ask before moving from diagnosis to remediation.

Neither a static plan nor unattended autopilot is ideal when the evidence and risk are changing quickly.

A decision rule that scales better than “always plan”

Use explicit Plan Mode when two or more of these are true:

• Ambiguity: reasonable people could interpret the outcome differently.
• Blast radius: the change spans services, packages, schemas, clients, or teams.
• Irreversibility: rollback is difficult, lossy, or operationally expensive.
• Hidden policy: the task includes security, privacy, billing, retention, or compatibility decisions.
• Weak verification: tests cannot prove that the chosen behavior is correct.
• Coordination: another person needs to approve the approach before implementation.

Prefer autonomous planning when most of these are true:

• the desired outcome is concrete;
• scope boundaries are explicit;
• the agent can verify success mechanically;
• the patch is small or isolated;
• rollback is cheap;
• project instructions already encode the accepted approach.

For the middle ground, use plan then autonomy: review the decisions that matter, convert them into a precise goal, and let the agent choose the low-level path.

The trend is not the death of planning—it is the separation of planning from approval

Coding tools are converging on workflows that can explore, plan, execute, verify, and continue without constant prompting. Copilot's plan-then-autopilot makes the separation explicit. Claude lets the user approve one plan into several different permission modes. Codex recommends refining uncertainty in Plan Mode and then expressing the result as a durable, verifiable goal.

This changes the role of Plan Mode. It is no longer the place where planning magically happens. Planning happens throughout agent work. Plan Mode is the place where planning becomes inspectable and interruptible before code changes create momentum.

Use it selectively. Skip it when the task is obvious and reversible. Require it when the first wrong assumption would be more expensive than the planning pause. And never mistake an approved plan for verification: the diff, tests, runtime evidence, and remaining risks still decide whether the work is done.

Further reading

• OpenAI — Developer commands for Codex
• OpenAI — Long-running work and Goal Mode
• Anthropic — Claude Code permission modes
• GitHub — Copilot CLI command reference
• GitHub — Copilot CLI best practices
• GitHub — Copilot CLI Autopilot