[BUG] Plan agent cannot write plan file, state lost (but tokens billed) - UPDATE: both macOS and Windows
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?
Environment: Windows and macOS, VS Code UI extension
About 50% of the time a planning agent will spend several minutes spinning (writing the plan file) only for the Write tool to fail. The failure error isn't displayed to the end user, and typically the agent then exits giving the orchestrator a shorter version of the same. Meanwhile, I've been billed for about 100K tokens that just got doppred on the floor. In fact, that's more like 250K-500K tokens wasted because at that point, the planning agent exits, so all of the research -- all of the tool calls reading files and reasoning -- is gone, summarised in the limited handoff message that isn't persisted. Then, the orchestrator tries to make up for it by doing supplemental research, but it has no access to the findings of the planner agent.
Occasionally I'll get the first few lines of the accidentally-ephemeral plan shown in VS Code and have managed to select it and copy it into a text editor, but sometimes it's actually just blank.
<img width="1217" height="199" alt="Image" src="https://github.com/user-attachments/assets/3578c902-7846-4180-bccc-3060590c9c24" />
What Should Happen?
When the model generates text with the intent to write it to a file, the tooling system shouldn't just give up on the first attempt and give the user no recourse.
Error Messages/Logs
Steps to Reproduce
Have Claude deeply plan a complex area in Plan Mode. Unsure if this is related to Windows, could be realted to path separator chars.
I was using the Sonnet 4.5 1M model but I've also seen this with Opus 4.5
Claude Model
Other
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.5x
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
<img width="1217" height="199" alt="Image" src="https://github.com/user-attachments/assets/f7eedc39-2806-4941-8408-8b7726e07a92" />
13 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
May be a similar area, but manifests as a much different issue to the three found
Tip for anyone finding this: in VS Code, enable developer tools and inspect the cropped elements containing the content you have paid for, wherein you can copy the element and paste it into another text editor to hand back to the orchestrator
<img width="351" height="668" alt="Image" src="https://github.com/user-attachments/assets/aa2cbe8e-4040-4ec9-b8bd-27078c3d99e2" />
FYI, I have the same type of issue.
More now claude is asking to create the /plans folder, asking to list the c:\users\xxx\.claude folder.
where as everything was smooth before.
It use token for nothing. The saving of the plan can fail multiple times, so I suspect this is also using additional tokens at each retry.
I move to the latest version yesterday which is a bit better but not as the previous version.
The issue starts on monday version.
Not related to Windows. At least, I'm experiencing the same on Ubuntu (VSCode Plugin also).
It's a problem sometimes, and sometimes not.
For anthropic, Feedback ID: 13f11c69-0d76-4600-9f97-aa20fe9377d5 is another instance of this.
Earlier it says:
and then it says:
???
Still getting this in VS Code with 2.0.55, it's effectively a dead tool at the moment. I asked it to make a plan, the delegated agent couldn't write its 600-line findings to a file, so I stepped in and grabbed the DOM element and handed it to the primary orchestrator, which has since just got distracted instead
<img width="253" height="502" alt="Image" src="https://github.com/user-attachments/assets/76c77b83-94c5-4bd1-9d87-a41453a95e25" />
From second pair of hands to totally unusable in a few version bumps - quite worrying - I hope this gets some attention soon
Adding insult to injury:
<img width="751" height="198" alt="Image" src="https://github.com/user-attachments/assets/86b2d0c6-4ea4-46a1-9796-bb240237a3f3" />
Update: this is happening on macOS too, latest version. I can no longer trust Claude Code to create plans without dropping information on the floor.
Through the use of developer tools I was able to extract this to a file manually:
<img width="362" height="76" alt="Image" src="https://github.com/user-attachments/assets/601ca7c5-a3f7-412e-9ac7-12dfef7a3cda" />
It was 1200 lines.
The agent orchestrator attempted to write a plan file based on the much shorter handoff message the agent subsequently gave it:
<img width="257" height="62" alt="Image" src="https://github.com/user-attachments/assets/0e123cb7-94c2-4ebe-b5a5-08bf24825e0c" />
Under half the length, and missing vital context that the agent had originally researched only for the Write tool to give up on the first try.
This is an astonishing waste of time and money: all the tokens this involved (both reading and writing) are burned and yet, obviously, still billed. Not to mention the tokens wasted in generating a subsequent, poorer plan, and then me steering it back on track.
I don't know how else to surface this issue but it's disheartening that this problem is getting very little attention.
Is this an environment-specific issue? I’ve been experiencing it in my setup for a little while now as well, and it’s making it cumbersome to work with Claude.
For reference, I’m using Claude Code via Zed ACP.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.