OpenClaw Fixes Cron Tool-Cap Loss Across Senderless Runs and Workers

OpenClaw has merged a substantial correction to how isolated Cron jobs carry tool authority into later scheduled runs. A job created with an explicit tool cap could lose tools that its creator was allowed to grant when the eventual run had no sender identity and OpenClaw reapplied anonymous wildcard policy.

The result was a confusing failure mode: a deliberately narrow scheduled job could reach its due time with fewer—or no—callable tools, even though its persisted cap was valid. PR #112661 now carries that authority through embedded agents, supported CLI backends, continuations, trigger and script paths, Codex, Copilot and cloud workers.

This is both an availability fix and a trust-boundary change. The important design claim is not merely “Cron gets its tools back.” The persisted cap remains a hard upper bound, while current global, agent, provider, profile, base-group, sandbox, runtime, subagent and worker restrictions still apply.

Operator decision

• If capped Cron jobs unexpectedly report missing tools: do not “fix” the symptom by broadening wildcard sender policy or removing the job’s cap. Those workarounds weaken the boundary the cap is meant to provide.
• If you run official packages: wait for a package that explicitly includes PR #112661 or merge commit 71c558ed. At verification time, npm latest and beta both predated the merge.
• If you run from source: use the merged PR head or a later revision, not one of the feature branch’s intermediate commits. This change spans policy capture, CLI enforcement, Doctor migration and cloud-worker admission.
• If you maintain a selectable CLI backend: verify exact tool-cap enforcement against the updated backend contract. The new path is designed to fail before model or tool execution when a backend cannot prove it can enforce the cap.
• If you use cloud workers: expect old persisted worker-v1 placements to be reclaimed and safely redispatched as worker-v2 on first use. Preserve job history and investigate a visible retry rather than bypassing worker admission.

There is no new operator-facing configuration to add.

Why senderless execution lost authority

Interactive turns normally arrive with requester identity. Scheduled invocations often do not: the creator configured the job earlier, but no person is sending the due-time turn.

Before this merge, OpenClaw could resolve wildcard sender policy again for that identityless invocation. An anonymous wildcard restriction could then remove a tool already captured inside the job’s explicit toolsAllow cap. Upstream’s live reproduction used a write-capped job that reached its scheduled run with no callable tools.

The fix introduces a trusted internal scheduled-policy context only when two durable facts exist:

1. the job has an explicit persisted tool cap; and
2. the immutable owner session is available.

That context reuses the owner session for current base group policy and skips only a fresh sender-specific overlay. It does not freeze the entire policy from job-creation time, and it does not turn creator authority into a permanent bypass.

Interpretation: OpenClaw is separating two questions that were previously conflated. The owner establishes the maximum tool set the job may use; current system policy can still reduce that set when the job runs. A missing sender should not silently replace the owner with an anonymous requester, but nor should an old job outrank today’s safety controls.

The cap follows every execution route

A narrow fix inside the embedded agent runner would have left alternate backends inconsistent. The merged work therefore propagates one canonical availability contract across OpenClaw’s execution routes.

Claude CLI translates the contract into exact CLI arguments. Gemini CLI receives an isolated system policy that disables ungranted native, discovered, agent, hook, skill and command-backed surfaces, then exposes only a grant-scoped OpenClaw MCP server. Gateway-mediated coding tools are resolved from the same canonical factory and filtered by the server-minted grant.

For other selectable backends, inability to prove exact enforcement is terminal: OpenClaw should record an actionable Cron error and decline to start the run rather than silently drop the cap or expose a broader tool set.

That fail-closed behaviour matters. A scheduled job is precisely where an operator may not be watching the moment policy is evaluated.

Cloud workers gain signed scheduled authority

The same authority must survive a remote execution boundary. The fix adds a versioned, signed scheduled-authority envelope to cloud-worker launches, with worker-v2 validating and consuming it before execution.

Persisted worker-v1 placements from earlier beta packages cannot satisfy that contract. The upgrade path destroys an idle incompatible lease and redispatches the existing session and workspace through worker-v2. If a worker-v1 launch was interrupted while starting, the failure remains visible for retry instead of widening authority to keep the run moving.

Upstream reports a packaged upgrade test starting from 2026.7.2-beta.3, preserving the session and workspace while replacing the worker placement. That is upstream evidence, not an independent Academy cloud-worker test.

Scheduled self-management remains narrow

The PR also tightens what a scheduled run may do to Cron itself. A host-signed, short-lived capability allows the current job to use a limited self-management surface: list, get, inspect runs and remove itself.

It does not authorize editing or running sibling jobs, updating schedules, accessing scratch outside the grant, or reusing an expired retained connection. This avoids the opposite failure mode—repairing tool availability by handing every scheduled turn broad scheduler administration.

Release boundary

At verification time, npm reported:

• latest: 2026.7.1-2
• beta: 2026.7.2-beta.4

Beta.4 was published at 06:11 UTC on 24 July. PR #112661 merged at 06:24 UTC, so that beta cannot contain the final merge. The pull request describes bounded compatibility for CLI plugins built against beta.1 through beta.3, but compatibility code on main is not evidence that an already installed package has the fix.

Watch for PR #112661 or merge commit 71c558edbd2c85df4e8981cfd75389631b5c56c9 in a later release, then verify the installed version before changing any interim controls.

Safe validation after upgrading

Use a harmless, isolated job rather than a production automation to verify the new path:

1. create a job with the smallest explicit tool cap needed for a disposable action;
2. confirm the job records the intended immutable owner session;
3. let the scheduler invoke it without an interactive sender;
4. verify the required tool is present and tools outside the cap remain absent;
5. inspect Cron history for backend-enforcement, worker-admission or migration errors; and
6. remove the disposable job and artifact.

Do not test by granting a broad shell, filesystem or scheduler surface. The point is to prove that a narrow cap survives, not that an unrestricted job can do something.

Evidence and limits

OpenClaw Academy reviewed the merged pull request, its final commit, changed-file surface, stated live reproductions and npm publication timestamps. Upstream reports extensive focused tests, source-build gates, live Gemini and Codex scenarios, and a beta.3 cloud-worker upgrade exercise.

We did not independently run the unreleased branch, launch a cloud worker or reproduce the senderless failure. We also do not assign a complete affected-version range: the primary source identifies behaviour and shipped-beta compatibility constraints, while the current official channels demonstrably predate the final merge.

Bottom line

A persisted Cron tool cap should survive the absence of a live sender, but it should never become a time capsule that bypasses current policy. PR #112661 restores that balance across local, CLI and worker execution.

Until the fix ships, treat missing-tool failures as an upgrade issue—not an invitation to relax wildcard policy or remove the cap.