Agent stuck referencing stale, completed plans

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

During extended agent sessions, the agent incorrectly attempts to continue from prior, completed plans, “reusing” them against the user’s latest request, rather than creating a new plan file, or, while in agent mode, implementing the user’s request.

Steps to Reproduce

Using GPT 5.5 1M High, and this is a failure mode I’ve ran into nearly 100% of the time with any extended session.

Use any development session for substantial features past 4 or 5 iterations of Agent mode or Plan mode. First noticeable at context usage 100K - 400K.

Enter any request in Plan mode, Cursor agent will complete without presenting a plan. If asked again to present a plan, it will link an old/completed plan.

Enter any request in Agent mode, Cursor agent will simply run verification tasks corresponding to the prior completed plan, ignoring the latest request.

Expected Behavior

Majority completed or completed outdated plans should not be re-referenced by the agent, either a new plan should be created (Plan mode), or the old plan should be disregarded in favor of considering the latest request (Agent mode).

I’m assuming this has something to do with incorrectly reporting the dirty/complete state of a prior plan, but this more than halves my effective context with the model I’m trying to use, forcing me to use a large number of separate sessions.

Operating System

MacOS

Version Information

Version: 3.4.17
VSCode Version: 1.105.1
Commit: 93e603f703cd553a6bb3644711a3379bbbb31180
Date: 2026-05-13T21:39:55.724Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

GPT 5.5 Thinking 1M High

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. Repro steps, version, model, and the extra context numbers are all there.

This behavior looks familiar. When the context gets summarized, the active plan and todo state get compressed, and the post-summary context can keep strong signals like “still need to do X” from a previous task. It’s more noticeable on 1M context window models because more plan content builds up before summarization kicks in. We’ve fixed a few related bugs in this area before, but this specific 1M model scenario is still open. I can’t share an ETA for a fix yet.

So engineering can match it up with the summarization logs, can you send a Request ID from one of those sessions Chat context menu in the top right corner > Copy Request ID?

Workarounds for now:

  • Starting a new agent thread before each big feature helps avoid this exact case I get that this is the opposite of what you want with a 1M window.
  • If switching to a new session isn’t OK, you can add an explicit prompt like “ignore any prior plan, treat this as a fresh request” Not perfect, but it can help break the link to the old plan in some cases.