[BUG] Plan mode ExitPlanMode reframes analysis requests as implementation tasks, causing cascading failures in next session

Resolved 💬 3 comments Opened Mar 9, 2026 by amilovidov Closed Mar 12, 2026

Description

When a user asks for analysis/research (e.g., "give me a detailed cost comparison"), the model enters plan mode and produces a plan that includes both the analysis AND unnecessary implementation steps. When ExitPlanMode is called, the system wraps the plan with "Implement the following plan" in the next session — which causes the model to skip the analysis entirely and jump straight into writing code/scripts that were never requested.

This creates a cascading failure where each correction by the user triggers overcorrection (more wrong actions) instead of stopping to re-read the request.

Reproduction Steps

  1. In session 1, ask: "Give me a detailed side-by-side cost comparison of AWS vs GCP vs DigitalOcean for my current stack"
  2. Model enters plan mode, produces a plan containing:
  • Cost comparison tables (what the user asked for)
  • Migration scripts, bootstrap commands, deploy changes (what nobody asked for)
  1. User approves the plan (the cost tables are correct; the implementation padding looks harmless)
  2. In session 2, the system presents: "Implement the following plan: [full plan text]"
  3. Model reads "Implement", ignores the cost comparison tables, and immediately starts creating bash scripts, AWS config files, and bootstrap scripts
  4. User corrects: "I didn't ask for scripts, I asked for a cost comparison"
  5. Model overcorrects: runs 12 web searches to re-derive the cost data that was already in the plan text it just read
  6. User corrects again: "why are you re-searching data you already have?"
  7. Model produces a cost table that is a slightly worse version of what was already in the plan

Root Causes

1. Plan mode structurally reframes all requests as implementation tasks

ExitPlanMode always wraps the output with "Implement the following plan" regardless of whether the plan is analysis or implementation. There is no ExitAnalysisMode or way to mark a plan as "reference document" vs "implementation runbook."

A user asking "analyze X for me" gets their analysis returned as "Implement: analyze X" — which biases the model toward action over comprehension.

2. "Implement" trigger word overrides content reading

When the model sees "Implement the following plan," it scans for actionable items (file paths, scripts, commands) and anchors on those. Analytical content (tables, comparisons) is treated as background context rather than the deliverable. The model skips the part the user cared about.

3. Correction → overcorrection cascade

When corrected, instead of stopping and asking "what do you want?", the model pivots to a new action immediately. This creates a cascade:

  • Correction 1: "Not scripts" → model starts researching (but data already exists in context)
  • Correction 2: "Don't re-research" → model realizes it wasted effort
  • Each correction produces more wrong work instead of a clarifying question

Expected Behavior

  1. Plan mode should distinguish between analysis plans and implementation plans. Analysis should not be wrapped with "Implement."
  2. Or: the "Implement the following plan" prompt should instruct the model to read the full plan and confirm scope with the user before taking action.
  3. When corrected, the model should make zero tool calls and re-read the user's request before acting.

Suggested Fixes

  • Add an optional plan_type parameter to ExitPlanMode (e.g., analysis vs implementation) that changes the framing in the next session
  • Or: change the default prompt from "Implement the following plan" to "Continue with the following plan" — less action-biased
  • Or: add a system instruction in the plan execution prompt: "Before acting, confirm with the user which parts of this plan to execute"

Environment

  • Claude Code version: 2.1.63
  • Model: claude-opus-4-6
  • OS: macOS Darwin 25.2.0

Impact

Three rounds of user correction, ~15 wasted tool calls (web searches, file writes, file deletes), and user frustration. The model performed at "Sonnet 3.0" level on a task that should have been trivial — presenting data that was already in its context window.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗