The literal error every time:
Error: Must provide either a ‘plan’ or both ‘old_str’ and ‘new_str’ for plan updates
The phrasing “for plan updates” is the giveaway — the tool thinks I’m trying to UPDATE an existing plan, not create a new one. But there’s no Pass 8 plan file (I confirmed via dir). Either:
The tool has stale state from a half-failed earlier attempt that “claimed” the Pass 8 name internally without writing the file.
The tool’s parameter validation is stricter than its schema suggests — maybe todos field requires a specific shape, or maybe the very long plan body is being silently truncated in some XML/JSON layer.
There’s an undocumented requirement for old_str/new_str even on first creation under certain conditions.
I’ve now tried:
With todos parameter (failed)
Without todos parameter (failed)
Long plan body with mermaid + code blocks (failed)
Short plan body, no embedded fences (failed)
Two different name values (failed)
Same error every time. The tool itself appears broken in this session.
Workaround options:
Skip the formal plan file, just use TodoWrite + execute. All the design intent for Pass 8 is in the conversation already (multiple times). The CreatePlan ceremony isn’t strictly required to ship the work — it’s a presentation tool. The TodoWrite list captures the task breakdown, and the conversation thread captures the design rationale.
Write the plan as a regular file in the workspace, e.g. f:\myproject\.cursor\rules\to-do-lists\Pass8_Workers.mdc (matches the existing project convention for tracked plans). This would persist the design context in the workspace where future conversations can find it.
Steps to Reproduce
In plan mode try and create a new plan, in a thread that has created many plans already without a problem
Thanks a lot for the report. We’re aware of some other reports of Opus 4.7 not using the Plan tool correctly (sometimes not at all, sometimes without arguments). I’ve attached your report to that open ticket, and the workarounds that you’ve identified are appropriate for now.
Could you confirm that you’ve faced this exact same issue on GPT 5.4? That’s something we don’t have other reports of right now, and it would be surprising given that GPT 5.4 has been out for a while!
I may be wrong about GPT-5.4 having the same problem. I can’t confirm.
One thing I can confirm is both threads in question were extremely long running, the GPT-5.4 was two days old or older, and the OPUS-4.7 thread had just hit the 12k lines of code generated from scratch mark in a day and had successfully created and executed at least 12 plans, maybe more.
I have been using planning a lot, for big code conversions to Rust, with extensive debugging using telemetry and Psql, a lot of activity thru both threads but in a surprisingly efficient manner with superb results.
I just would love the current OPUS-4.7 thread to live a bit longer in the planning department
Okay the GPT-5.4 planning bug is different but also a problem
Plan File Failure Description
Summary
CreatePlan successfully created a plan file and returned a valid absolute path, but later Cursor reported the file did not exist or could not be opened, even though the file was still present on disk and readable by the agent tools.
The problematic plan existed only in the global directory, not the workspace-local one.
Likely root cause
This looks like a path resolution / plan-location tracking bug, where Cursor:
creates the file in the global plans location
later tries to resolve it differently
or expects it under workspace-local .cursor\plans
or loses the association between the plan URI/path and the actual file on disk
User impact
Makes plans appear lost even when they still exist
Breaks confidence in plan-mode workflow
Makes it hard to reopen or continue plan-driven work
Encourages duplicate/recreated plans because the original appears missing
Useful diagnostic fact
A direct search still found: C:\Users\findevai\.cursor\plans\first_tranche_0c345a9f.plan.md
and no corresponding file existed under: F:\myproject\.cursor\plans
Short version
Cursor created the plan successfully, but later could not reopen it even though the file still existed at the exact path originally returned. This appears to be a plan path resolution/tracking bug involving the global Cursor plans directory versus the workspace-local .cursor\plans directory.
@Colin I went this morning to discover if the OPUS-4.7 plan bug is resolved by shutting down cursor and starting up the next day I can confirm that does not circumvent the planning bug. Still cannot create a plan. that thread is now retired.
In discovering this I also trigged an Anthropic full cache re-seed on that thread I ran ALL DAY yesterday
In confirming this planning failure bug still exists on that thread, with one prompt, this morning it just cost me $76.00 USD and for a Canadian that is about 100 bucks - any chance can i get a credit on my account for that ?
This was Work around number 3 now deleted, as it’s a proven failure and unnecessary expense
@Colin I have discovered the root cause I believe for Opus-4.7 plan mode failures - yesterday I had another plan failure by Opus-4.7 when switching from Agent mode to plan mode on the 2nd prompt of a new thread. Today I started a new thread in Plan mode for the first prompt and I successfully created a plan using Opus-4.7
The planning failures occur when I decide to be switching from agent mode to plan mode mid thread. Starting in plan mode from the beginning works.
PS I am having trouble modifying the tags you reccommended for this thread. Unable to figure out how to add tags to a existing post
Otherwise everything is cool and much appreciate that test cost from yesterday has vanished from the detail lines in my usage.