OpenClaw merged an important automation compatibility fix this morning in PR #145730: older cron jobs can remain editable after the ownership and account-attribution changes in OpenClaw 2026.9.4.
The bug affected jobs created before account attribution became explicit. Those automations could carry a creator session without a separate owner account. When a user later edited an older automation's prompt through chat, OpenClaw could ask for a new tool-permission cap and then reject the update with an owner-policy mismatch.
That is a frustrating class of failure because the user is not trying to create a new privileged automation. They are editing an existing one, often just changing the prompt. The system needs to preserve the job's original execution policy while still enforcing ownership for real capability changes.
What OpenClaw Does Now
The fix has two parts.
First, Doctor now reconciles provable creator account metadata independently of tool-cap migration. That means account recovery can run even for capless jobs, and the repair is reported instead of silently skipped.
Second, Gateway mutation admission now allows a prompt-only edit by the exact persisted creator session or account without forcing a new cap. Explicit tool edits still go through the existing owner validation. Accountless or conflicting legacy identities are not assigned to whoever happens to be calling the command.
In plainer terms: OpenClaw can repair the ownership facts it can prove, allow safe prompt edits by the original owner, and keep tighter checks for edits that actually change tool authority.
Why This Is A Good Compatibility Shape
Cron jobs sit at an awkward boundary. They are durable, often quiet for long stretches, and powerful enough that ownership cannot be hand-waved. At the same time, breaking old automations after an upgrade creates exactly the kind of operational drag users remember.
PR #145730 handles that tension carefully. It does not broaden account authority. It does not assign ambiguous jobs to the current caller. It preserves capless execution policy where that is what the job already had. The change is narrowly about making legacy ownership recoverable and prompt-only edits possible when the persisted creator identity matches.
What To Watch
If you upgraded to 2026.9.4 and saw older automations become hard to edit, this is the PR to track. The PR references #145689 and earlier ownership work around cron authorization, so it is likely to appear in release notes as a compatibility or Doctor repair item rather than as a new feature.
For operators, the takeaway is simple: existing automations should keep their policy, Doctor should be able to repair provable account metadata, and prompt-only edits should not be blocked by a missing legacy owner field when the creator identity is already known.