[BUG] Desktop app task list: plan is skipped or never advances mid-turn

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

In the Claude desktop app (Code tab), the task list under the latest message does not track progress on multi-step, tool-heavy requests. Three behaviors, all seen with Sonnet 5.5:

1. No plan is created, even for a request that runs 16 separate commands.
2. A plan is created and never advanced mid-turn. Step 1 shows the spinner for the whole turn, then all steps flip to completed at once when wrap_up runs.
3. A plan is created, never advanced, and wrap_up is never called. Step 1 spins forever.

It reproduces in a clean folder with no CLAUDE.md, no project settings (so no project output style), so project instructions aren't the cause. The model does keep the list correct when each plan step maps to a single tool call, so this looks like a prompting or tooling gap rather than a UI rendering bug.

What Should Happen?

The list should reflect real progress. Each step should show in-progress while it is being worked and completed when it is done, and the list should never be left spinning once the turn ends. If a plan exists, a turn should not end with steps that were never advanced.

Error Messages/Logs

Steps to Reproduce

Repro prompt, run in the clean folder (transcript read):

update_plan     (not called)
Bash x16
wrap_up         (not called)
-> final answer, no task list shown

Same prompt, in a project with a CLAUDE.md (transcript read):

update_plan x1
Bash x16
wrap_up x1
-> final answer; UI: spinner on step 1, then all 4 steps completed at once

A longer real task (an API data pull; transcript read):

update_plan x1
Bash x~11
(no wrap_up)
-> final answer; UI: step 1 spinning permanently

| Run | Context | Plan created | Advanced mid-turn | wrap_up |
|---|---|---|---|---|
| 1 | Project with CLAUDE.md | yes | no | yes |
| 2 | Clean folder | no | n/a | no |
| 3 | Clean folder | no (per UI) | n/a | not checked |
| 4 | Clean folder | yes (per UI) | no (per UI) | not checked |

Two simpler prompts (5 trivial commands) also produced no plan. Sample sizes are small, so the plan-creation rate is a rough estimate.

Steps to Reproduce

1. Create a git repo with about 12 small commits touching several top-level directories (scripts, tests, docs, a dot-directory, root files). No CLAUDE.md and no .claude/settings.json.
2. Open it in the desktop app (Code tab) as a new session. Model: Sonnet 5.5.
3. Send this prompt:

```
For each of the last 12 commits, run git show --stat --format=%s <sha> as its own command and record the top-level directories touched. Then spot-check the 3 busiest directories with git log --oneline -5 -- <dir>`. EXCLUDE docs-only commits. COLLAPSE directories that appear in fewer than 2 commits into "other". ORDER by commit count, descending. Output only a plain-text list in a code block, one entry per line, no headers or counts. After the list, give one line on sample size and gaps.

````

1. Watch the task list. Roughly one run in three creates a plan, and none that did advanced it during the turn.
2. Read the session transcript and count update_plan and wrap_up calls against the commands run.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.301 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Possible contributors in the model's task-list instructions (Claude's own reading, not confirmed):

• The plan must be sent with the very first tool call, before the work is known, so steps come out coarse. One step can span a dozen tool calls, with no natural point to advance.
• Advance is tied to "the call that begins" the next step, and the tool must not be called alone. In a run of back-to-back commands it is easy to forget.
• wrap_up is described as also checking off the list ("no closing update_plan is needed"), which makes an end-of-turn flush look sufficient.
• The exemption for "a single-command answer or pure conversation" is fuzzy, which fits plans being created only some of the time.

Suggested directions: warn at turn end when a plan exists that was never advanced; allow a standalone advance or advance automatically as tool calls complete; ask for finer-grained steps or a re-check after N tool calls; tighten the "when to create a plan" threshold.