Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Task list persists after aborting a plan mid-execution [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#56391•Fetched 2026-05-06 06:29:20
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
milton-limilton-li
Participants
github-actions[bot]github-actions[bot]milton-limilton-li
Timeline (top)
labeled ×4commented ×1renamed ×1

Error Message

Error Messages/Logs

(no error — silent state carryover)

Root Cause

Likely related to #41542 — same task-list-persistence root cause, different trigger (abort + unrelated prompt / /clear, rather than /rewind).

Code Example

(no error — silent state carryover)
RAW_BUFFERClick to expand / collapse

Preflight Checklist

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

What's Wrong?

When Claude Code is in the middle of executing a plan (with an active task list created via TaskCreate), and the user aborts the run (e.g. ESC), the in-progress/pending tasks from that plan stay in the task list. They persist into the next turn even when the next user prompt is unrelated to the original plan, so Claude continues to see — and sometimes act on — stale tasks from a workflow the user already abandoned.

/clear does not clear them either: after /clear, when the next message kicks off a new request, the abandoned task list is still surfaced to the model in context.

This looks closely related to #41542 (TODO list not restored after /rewind) — same underlying issue of the task list not being tied to the active conversation/turn lifecycle. The trigger here is abort + unrelated next prompt (and /clear), rather than /rewind.

What Should Happen?

Aborting a plan mid-execution should leave the task list in a state that doesn't poison subsequent unrelated turns. At minimum:

  • When the next user prompt is clearly unrelated to the aborted plan, the prior task list should not be presented as live work.
  • /clear should reset the task list along with the rest of the session state.

Error Messages/Logs

(no error — silent state carryover)

Steps to Reproduce

  1. Start a Claude Code session and invoke a complex skill / slash command that causes Claude to generate a plan and create a task list (TaskCreate with multiple in-progress/pending items).
  2. While the plan is mid-execution, hit ESC to abort.
  3. Send an unrelated next prompt (e.g. "what time is it in Tokyo?").
  4. Observe: the abandoned task list is still active and visible to the model. Claude may reference or attempt to resume those tasks despite the new prompt being unrelated.
  5. Run /clear and send another prompt — the stale tasks are still present.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.128 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Likely related to #41542 — same task-list-persistence root cause, different trigger (abort + unrelated prompt / /clear, rather than /rewind).

extent analysis

TL;DR

The most likely fix is to update the task list management to properly clear or reset the list when a plan is aborted and a new, unrelated prompt is received, or when the /clear command is executed.

Guidance

  • Investigate the TaskCreate function and its interaction with the task list to understand why the list is not being properly cleared when a plan is aborted.
  • Review the logic for handling the /clear command to ensure it resets the task list along with other session state.
  • Consider adding a check to determine if a new prompt is unrelated to the current plan and clear the task list if so.
  • Examine the relationship between the task list and the conversation/turn lifecycle to identify potential issues with task list persistence.

Example

No code snippet is provided as the issue does not include specific code details.

Notes

The issue may be related to a known problem (#41542) with task list persistence, but the trigger is different. The fix may involve updating the task list management logic to handle plan abortion and /clear commands correctly.

Recommendation

Apply a workaround to clear the task list when a plan is aborted and a new, unrelated prompt is received, or when the /clear command is executed, as the root cause of the issue is likely related to task list management.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#agent execution#callback error#memory management#API rate limit

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING