Please Follow us on Truth Social, X , Youtube , Minds, Telegram, Rumble, GETTR, Gab, Instagram
The post describes one user’s experience with forced migration, stalling repairs and scheduled jobs reporting success when they have not actually done any work.
A user of OpenClaw (an open-source AI agent platform) had their routine request to switch between AI models to fix several issues cause a chain reaction of problems with the system. Now the automated tasks that were set up will not work and the user can no longer trust the software to operate correctly.
After months of slowly but persistently setting up and fine-tuning a large collection of scheduled automations on the platform, the user, who wished to remain anonymous for this article, had all of that work suddenly and unexpectedly turned on its head by a simple request to change models that the built-in assistant suggested for repair. After applying the repair command and restarting the gateway, the user found that attempts to launch the gateway would fail with a forced migration of the legacy session store to a newer database format, involving tens of thousands of old chat log files.
Unfortunately the system is not returning to a working state. The single model setting that must have been left on the account is referencing a non existent identifier. Every subsequent request must now be hand edited at the command line to remove the identifier. Scheduled jobs however are no longer following the months of accumulated workflow. The assistant reports that content has been created and published but when checking on the content it has not been and it is referencing a non existent post ID. On occasion it reports that scheduled jobs and a connected account have disappeared.
He can no longer trust the current version of OpenClaw to even get the basic work done. He’s having to complete the work by hand, and only using OpenClaw for drafting. He’d like to be able to rebuild this on an earlier version of OpenClaw, but for now he’s waiting to see if the next version will fix this.
No clean way back
The user also noted that because the migration of data past the support of the release they were running on, the only way to go back to a release that supported the workflow as it was before would be to restore a verified backup of the data from before the update which doesn't exist.
Not an isolated case
This is not an isolated incident. For example, in the project’s public issue tracker, issue #162198, scheduled deliverables for in-flight work failed to deliver with the work’s record showing that it was successfully delivered. However, no retry, nor notification of failure were attempted or sent. Another open issue, is work in progress silently abandoned upon reload of the work in progress? This has been reported in other projects as well within the community. According to a third-party tracking of issues and PRs for OpenClaw there are currently 489 open issues and 500 active PRs. Silent completion loss of in-flight work has been a recurring theme in many of the agent projects within the community.
Developers are continuing to ship fixes. The latest release (2026.9.8) includes a fix for a bug that caused the gateway to freeze up for 2.5 minutes or more and produce no log output while background reviews or cron jobs started other reviews. This bug was arguably the root cause of the user’s problem with forced migration. In the extended-stable channel a set of cron fixes have been shipped as well. The reported delivery tool-call issues however are still open.
What is not established
However, this is just one user’s account and he has no way of verifying that any changes to the stored instructions have actually occurred or what those changes might be. The stored data for the scheduled jobs is separate from the ongoing failure to deliver and tool-call failures that are described elsewhere in the project’s trackers.
This user is currently deciding whether to go back to a previous version and start again or to wait for the next release.
This article relies on one user’s story, and the publicly accessible trackers for the project. The authors of OpenClaw were not contacted for this piece, and would be warmly invited to respond.
Sources:
Rollback and recovery · OpenClaw
Integrity and recovery (database schemas)
Cron announce delivery failure, issue #162198
OpenClaw Ecosystem Digest, Oct. 1
OpenClaw releases
