Removing a Cron Authority Account Could Give Its Jobs Every Tool
A merged OpenClaw security fix makes scheduled runs fail closed when their recorded channel account has been removed instead of falling through to unrestricted tools.
OpenClaw has fixed a fail-open authorization path on main: when a scheduled job named a channel account that had since been removed from configuration, policy resolution could fall through to no account-specific restriction. The resulting automation could receive the full tool surface, including consequential tools such as exec and apply_patch, instead of losing authority with the deleted account.
This reverses the safe revocation model. Removing an identity should narrow or terminate its jobs, never widen them.
Act if you remove or rotate channel accounts
- Inventory scheduled jobs whose creator or recorded authority references a channel account.
- Before deleting or renaming that account, disable or recreate its jobs under the intended surviving identity.
- Upgrade only to a release or source revision confirmed to contain PR
#115932or commitcee6203f. - Until then, treat account removal as incomplete revocation: separately disable affected schedules and verify their next-run tool policy.
- After upgrading, test with a disposable removed-account job and confirm its effective policy is
allow: []plusdeny: ["*"]before any model or tool execution.
Do not test this boundary with a real shell command or production schedule. A policy inspection or harmless denied tool call is enough.
How removal widened access
Scheduled work carries authority from an earlier creation context because no interactive sender may be present when the job becomes due. OpenClaw’s group-tool policy resolver looks up the named channel and account to recover the applicable restrictions.
The broken path distinguished a missing channel from a missing account incorrectly. An unknown channel already failed closed, but a known channel with an account ID no longer present could return no account policy. Downstream, that absence meant there was no account-level deny set to intersect with the job’s other policy layers.
Search results for the merged PR confirm the practical consequence: removed-account jobs could obtain full tool access, including exec and apply_patch. The fix makes the resolvers return an explicit deny-all result for this case.
Interpretation: “no policy found” cannot safely mean “no restriction” when the lookup key represents revoked authority. At an authorization boundary, missing identity state is itself a decision: deny.
This complements—not replaces—Cron tool caps
OpenClaw recently merged a broader scheduled-authority design that preserves a job creator’s explicit tool cap through senderless execution. That availability correction establishes the maximum tools a legitimate scheduled identity may carry.
PR #115932 handles the opposite edge: the identity no longer exists. A persisted cap must not keep authority alive after revocation, and lookup failure must not erase restrictions. Operators need both properties:
- a valid owner and cap survive a senderless run; and
- a removed owner fails closed regardless of the job’s previous capability.
Recreating an account with the same display name should not be assumed to restore the old trust relationship. Review the configured account identifier and recreate the schedule deliberately.
Audit procedure
For each scheduled job:
- export its immutable ID, enabled state and recorded authority account;
- resolve that account against current channel configuration;
- flag missing or renamed accounts;
- inspect the effective tool allow/deny result without starting consequential work;
- disable and recreate orphaned jobs under a valid least-privilege identity; and
- retain the audit evidence through the next scheduled run.
Also review account-removal automation. A control-plane workflow that deletes credentials but leaves schedules enabled may appear to complete successfully while preserving a dangerous gap on pre-fix builds.
Release boundary and evidence
The official repository records show PR #115932 merged on 30 July 2026 with a P1 security-boundary classification. Web search independently returned the PR and its description of the full-tool fallback plus explicit deny-all correction. OpenClaw Academy did not execute the vulnerable path, and this is a merged-main advisory rather than proof that any particular npm release contains the fix.
We are not publishing exploit steps. The operator-relevant fact is the revocation failure and the safe mitigation: stop orphaned schedules, upgrade to a containing build and verify deny-all resolution.
Bottom line
Deleting a channel account must delete its authority. On affected OpenClaw revisions, that deletion could instead remove the final restriction from scheduled work. Patch promptly, audit orphaned Cron identities and make revocation tests prove tool denial—not merely credential removal.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF