Claide Code needs to be more user friendly

Bug Description
I am a Claude Code convert. It has done a magnificent job in updating my large python project written for Python 3.6 into a modern version with typing and good quality comments. To do that, it maintains some status files, meaning that I can stop the process, save files and resume where it left off in the safe knowledge that things will restart without any fuss. I started it off with a coherent plan of what I wanted to do, and it then worked on intermediate steps to achieve the goal. When I wanted to stop, I asked it to update its files, then waited for it to do that, and the stopped the process. I signed up for Pro because that was necessary to use Claude Code and that seemed sensible to cope with this one project.

On day 2, problems emerged. Suddenly at some random point that I cannot predict reliably, the whole thing stops. It announces that I was only allowed to continue at the start of the next 5 hour window. When it stops dead, the state of the project can be a mess. The status files may not be current, when you start again it doesn't really appears to start where it stopped. So time and presumably the magic dust you need to keep it working is wasted in making sure that Claude is happy with the state of things, and files are all up-to-date. I spent a lot of time, checking and asking it to ensuring that the 4 status files were actually up-to-date. They often were not.

Your friiendly help robot suggested I spend more money and pointed me at /status. which is less than useful. It tells me that I have some percentage of magic dust left, but that doesn't assist me in predicting when I need to create a checkpoint so that when the plug is pulled, all will be well. The chart tells me a percentage usage, but not how the magic dust is being consumed. I need a range prediction.

It seems to me that Claude is surely clever enough to warn me when the magic dust is going to all be used, also it knows how much it 'costs' to save a reliable checkpoint set before the dust expires. I would not have minded about having a break had I been to told "sorry you are about to run out of resources" and a checkpoint is then created automatically before any service is removed, so I have the choice of waiting or maybe even topping up my account a little.

So this is my bug. Please think a little about people who've never used your product. If you have limits, then those limits should be obvious, and users should at least be told before things grind to a stop, so they have a chance of things being where they left off. A better bug fix, is to make Claude cope with this problem automatically. As it stands at present, it's basically unreliable because it can pull the plug without any warning and also apparently without any way of predicting it's sudden need for a rest.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.0.37
• Feedback ID: 8741fb31-1897-4ec2-a0f9-7e8a7bb49b79

Errors

[{"error":"Error\n    at Kw (/$bunfs/root/claude:59:1142)\n    at <anonymous> (/$bunfs/root/claude:64:10074)\n    at emit (node:events:92:22)\n    at endReadableNT (internal:streams/readable:861:50)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/claude:66:2146)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-11-12T19:00:51.921Z"},{"error":"Error: Lock file is already being held\n    at <anonymous> (/$bunfs/root/claude:87:11857)\n    at X (/$bunfs/root/claude:86:5167)\n    at <anonymous> (node:fs:243:13)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-11-12T19:00:59.464Z"},{"error":"Error: Lock file is already being held\n    at <anonymous> (/$bunfs/root/claude:87:11857)\n    at X (/$bunfs/root/claude:86:5167)\n    at <anonymous> (node:fs:243:13)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-11-12T19:02:18.375Z"},{"error":"Error: Lock file is already being held\n    at <anonymous> (/$bunfs/root/claude:87:11857)\n    at X (/$bunfs/root/claude:86:5167)\n    at <anonymous> (node:fs:243:13)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-11-12T19:04:14.136Z"},{"error":"Error: Lock file is already being held\n    at <anonymous> (/$bunfs/root/claude:87:11857)\n    at X (/$bunfs/root/claude:86:5167)\n    at <anonymous> (node:fs:243:13)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-11-12T19:15:37.117Z"},{"error":"Error: Lock file is already being held\n    at <anonymous> (/$bunfs/root/claude:87:11857)\n    at X (/$bunfs/root/claude:86:5167)\n    at <anonymous> (node:fs:243:13)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-11-12T19:15:45.081Z"},{"error":"Error: Lock file is already being held\n    at <anonymous> (/$bunfs/root/claude:87:11857)\n    at X (/$bunfs/root/claude:86:5167)\n    at <anonymous> (node:fs:243:13)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-11-12T19:17:25.417Z"},{"error":"Error: Lock file is already being held\n    at <anonymous> (/$bunfs/root/claude:87:11857)\n    at X (/$bunfs/root/claude:86:5167)\n    at <anonymous> (node:fs:243:13)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-11-12T19:17:42.625Z"}]