Chris wrote:
Sorry—Tom AI gave you a vague “didn’t hold” answer instead of identifying a failure, and it shouldn't have made that sound like a known cause. I checked the cleanup behavior: the AI path hides Docker's actual error behind a generic refusal, so your docker system df confirms Docker reports reclaimable space, but it doesn't tell us why removal failed. One safe next check: in the dashboard, open Settings → Tools → Maintenance → Run cleanup once, then tell me the exact message it shows or whether it reports reclaimed space. That cleanup removes unused images and build cache, not volumes, containers, or app data; it can remove previous app images needed for Roll Back and images for apps you've switched off. Please don't run docker system prune. I've recorded this correction so the guidance won't present an unknown cleanup failure as a known cause to the next person.
Chris wrote:
Update: we found why Tom AI said "didn't hold", and it's fixed in SparkBox 1.6.885, which is out now. What went wrong: Tom AI counted a cleanup as failed whenever some other app on your box was already stopped or unhealthy at the time, even when the cleanup itself worked. It also offered to remove old image layers that an app still runs on. Docker always keeps those, so Tom AI's own check afterwards said the cleanup hadn't finished. Each of those was written down as a failed try, and Tom AI then refused to repeat it for a week without saying why. In 1.6.885 a cleanup is judged only on what it removed, the offer only counts what can really be removed, and the earlier "failed" tries no longer block a new one. Volumes, containers and app data are still never touched. One next step: run sudo sparkbox upgrade, then ask Tom AI again to remove unused images and the build cache. If it still refuses, reply here with the exact words it shows. The Run cleanup button from my last message still works too, if you'd rather not wait. Legend boxes get 1.6.885 now; boxes without a paid licence get it about a week after release.