[BUG] Plan mode: nine identical "Updated plan" writes in a row, no progress, no loop breaker, no error

Status Open
Reported on v2.1.231
Maintainer reply None cached
Activity 0 comments · opened Aug 27, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [ ] I am using the latest version of Claude Code — observed on 2.1.231, see Additional Information

What's Wrong?

A session in plan mode emitted Updated plan nine times in a row, each write carrying identical content — the literal text /plan to preview — with two file reads interleaved and no other progress. It did not terminate on its own; the user interrupted it.

The visible output was nine repetitions of this, and nothing else:

⏺ Updated plan
  ⎿  /plan to preview

⏺ Updated plan
  ⎿  /plan to preview

  Read 1 file

⏺ Updated plan
  ⎿  /plan to preview

The apparent trigger is a model attempting to invoke a slash command from inside its own turn — the plan body is a slash command, not plan prose. Slash commands aren't invocable that way, and writing one as plan-file content is a silent no-op: no error, no tool result saying the action did nothing. So nothing tells the model its attempt failed, and it retries.

The exact cause is a guess; the reportable part is not. N identical consecutive plan-file writes with no intervening state change is a mechanically detectable non-progress state, and nothing detects it — not the harness, and not the user, who sees only a stack of identical lines with no indication the session is stuck rather than working.

This matters more than a normal loop because plan mode is where unattended sessions sit waiting for a human. A loop here burns usage against a wall with nobody watching.

What Should Happen?

Any one of these would have ended it:

  1. A circuit-breaker on repeated identical plan writes — after N consecutive writes with byte-identical content, stop and say so.
  2. A signal back to the model when its emitted content parses as an attempted slash-command invocation, so it learns the call did nothing instead of inferring nothing.
  3. At minimum, something on screen for the user. Nine identical Updated plan lines look like activity. A single line saying the plan has been rewritten with unchanged content N times would have made it obvious in one glance.

Error Messages/Logs

None — that is the substance of the report. No error, no warning, no non-zero result. The failure is entirely silent on both sides.

Steps to Reproduce

I do not have a deterministic reproduction, and I would rather say so than invent one.

Reported by the user on 2026-08-26. I attempted to recover the originating transcript from ~/.claude/projects/ afterwards and could not locate it, so I cannot name which skill or command issued the /plan to preview text. The user's account is that a skill's instructions tried to run it.

What I can state precisely: the output above is a verbatim paste from the session, and the loop ran to at least nine iterations before manual interruption.

Filing despite the thin repro because the failure mode is silent and open-ended — the class of bug where waiting for a clean reproduction means it keeps costing people usage in the meantime. Happy to add detail if it recurs and I catch the transcript.

Claude Model

Not recorded for the affected session.

Is this a regression?

Unknown.

Claude Code Version

2.1.231

Platform

macOS

Operating System

macOS 26.6.0, arm64

Terminal/Shell

zsh, inside a terminal-emulator app hosting the session on a PTY. ⚠️ Worth noting for triage: the loop is a plan-file-write loop, so I would not expect the host terminal to be implicated — but I cannot rule it out, having not reproduced it.

Additional Information

The version is not current — 2.1.231, and I have seen 2.1.238 referenced since. If this was fixed in between, that is the answer and the issue can be closed on that basis.

Adjacent but distinct existing issues, checked before filing:

  • #85523 (open) — an unbounded plan-approval loop consuming usage unattended. Same end state, different cause: that one re-enters plan mode after an iOS worker restart. This one never leaves it and involves no approval round-trip.
  • #34175, #33870, #59927 (closed) — plan-mode loops driven by ExitPlanMode approval being registered as rejection. No rejection is involved here; there was no approval prompt at all, only repeated writes.

The distinguishing signature against all of the above: repeated identical plan-file writes with no approval step in the cycle.

View original on GitHub ↗