Summary
ExitPlanMode is a state change — it should drop the plan-mode constraints. But the current prompt shows the plan and asks the user to approve executing it, framing exit as a commit-to-run action. They're separate concerns.
Repro
- User and agent build a plan in plan mode.
- User implements the plan elsewhere (Codex, another session, by hand).
- User tells CC: "exit plan mode."
- Agent calls `ExitPlanMode`.
- User sees the original plan + an approval prompt with auto-mode toggle. No "exit" framing.
Expected
Prompt: `Exit Plan Mode?` Two buttons: `Exit` and `Stay in Plan Mode`. Whether the plan runs after exit is determined by the user's next instruction.
Actual
The only way to exit is to accept what reads as "approve this plan for execution," which implies CC will now run the plan. For users whose plan was completed externally, this is misleading and frequently rejected — leaving them stuck in plan mode with no clean exit.
Why it matters
Plan mode is increasingly used as a planning surface where execution happens elsewhere (Codex, parallel agents, human handoff). Coupling exit with execution breaks that workflow.
Summary
ExitPlanModeis a state change — it should drop the plan-mode constraints. But the current prompt shows the plan and asks the user to approve executing it, framing exit as a commit-to-run action. They're separate concerns.Repro
Expected
Prompt: `Exit Plan Mode?` Two buttons: `Exit` and `Stay in Plan Mode`. Whether the plan runs after exit is determined by the user's next instruction.
Actual
The only way to exit is to accept what reads as "approve this plan for execution," which implies CC will now run the plan. For users whose plan was completed externally, this is misleading and frequently rejected — leaving them stuck in plan mode with no clean exit.
Why it matters
Plan mode is increasingly used as a planning surface where execution happens elsewhere (Codex, parallel agents, human handoff). Coupling exit with execution breaks that workflow.