OpenClaw has removed the shared system that tracked work performed by its other runtimes. The September 27 change in openclaw/openclaw deletes Tasks and TaskFlow APIs, commands and panels. Scheduled jobs, native agents and result delivery retain their own execution paths. For plugin authors, the immediate consequence is a broken contract: the removed Task interfaces have no compatibility layer.
A ledger sounds like a reassuring addition to an agent system. It can give a user one place to inspect work that runs elsewhere. But when the scheduler, session and native agent each know whether a job is running, another authoritative record creates another answer that must stay correct through cancellation, delivery and restart. OpenClaw’s decision is to remove that shared authority and make the surviving owners carry their own responsibilities.
The interface disappears before the stored rows do
The SDK migration guide names the cuts: api.runtime.tasks, registerDetachedTaskRuntime and the Task-specific harness SDK module. Plugins must use native launch, wait and history operations, Cron run history, or the Lobster workflow runner for the corresponding job. Harness result routing has a completion-only interface.
This is not a database purge. The same guide retains the physical tables and their schemas. Cron still uses its own history rows in task_runs; the other Task and TaskFlow rows remain stored but unused by the runtime. A familiar table name can therefore survive after the API it once backed has ceased to exist. An integration that merely checks whether the table is present can draw the wrong conclusion.
The revised automation guide distributes the reader’s next steps: subagents for delegated work, ACP for coding-harness sessions, automation history for scheduled runs and Lobster for local pipelines with resumable approvals. That is a change in how operators find their evidence, as well as in how plugins call the system.
Recovery has to know whose work it is
The difficult part is an upgrade with unfinished native work. OpenClaw’s Codex migration reads old Task records and carries eligible assignments into existing session-binding metadata. It checks the original requester’s session, lifecycle and connection facts. A native parent that has rotated is not, by itself, enough to establish ownership.
An import marker records which old Task rows have already been consumed. It must survive acknowledgment and later resets so an unchanged historical row cannot bring completed work back. The migration tests exercise that boundary, including a newer binding arriving during import and a requester being replaced while the write is pending. In those cases, the repair must preserve the newer state rather than overwrite it.
The operator documentation also makes room for an honest refusal. Older or ambiguous records can lack the ownership facts needed for a safe import. Doctor leaves those records untouched and warns; it does not invent an owner from the current parent. Preserving data and successfully resuming its work are separate promises.
A merged removal, a bounded upgrade claim
The strongest counterweight to a tidy simplification story is in the public landing record. Maintainer Peter Steinberger authorized an administrative merge after an earlier full CI pass, subsequent conflict review and focused checks. The later CI planning step hit a changed-file metadata limit. The record does not claim a fresh full-suite pass on the final head.
It reports a successful published 9.4 native assignment import, but leaves later native completion witnesses and the final 9.4 rollback unproven. We inspected the source and tests, not a running upgrade. The merge establishes what main now contains; it does not establish what every installed release runs or that every old session will finish correctly.
For operators considering a revision containing this removal, the useful rehearsal is an upgrade of a disposable copy with unfinished work and an older plugin. Check which calls disappear, whether ownership warnings are actionable and whether results reach the original requester after restart. The next decisive evidence is the missing completion-and-rollback replay. Removing a duplicate authority earns its keep when the work that outlives the upgrade can still find its way home.