PR #78286: fix(cron): allow read-only self-introspection in scoped runs

• Repository: openclaw/openclaw
• Author: RenzoMXD
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/78286

Description (problem / solution / changelog)

Summary

• Problem: In a cron-triggered run with cronSelfRemoveOnlyJobId set, the cron tool throws "Cron tool is restricted to removing the current cron job." for every action except remove. Both cron.status and cron.list are blocked before dispatch, even though they are read-only and cron.list already supports per-agent filtering.
• Why it matters: Heartbeat-runner cron-triggered runs need self-introspection to compute next-fire timing. Without it, STATUS write completion aborts and STATUS.json mtimes go stale across the fleet, causing watchdog freshness sweeps to page operators while agents continue doing real work. Regression in v2026.5.4.
• What changed: assertCronSelfRemoveScope now allows the read-only actions status and list through (extracted as a READ_ONLY_CRON_ACTIONS set + isReadOnlyCronAction helper). Mutation actions (add / update / run / wake) and remove of any job other than selfRemoveOnlyJobId continue to throw the existing error. In self-remove scope, case "list" forces agentId to the requesting session's agent so the scope cannot enumerate other agents' jobs even when the caller supplies a different agentId.
• What did NOT change (scope boundary): No changes to the cron.status / cron.list Gateway handlers, cronSelfRemoveOnlyJobId plumbing in src/agents/pi-tools.ts, mutation semantics for add / update / remove / run / wake, or adjacent cron tool actions (runs). No CHANGELOG attribution edits, no schema changes, no generated/inventory file edits.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #78208
• Related: #73028 (introduced the original self-remove scope) and #77602 (added agentId filtering for cron.list)
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: PR #73028 introduced assertCronSelfRemoveScope to gate non-owner cron-triggered runs to a single remove of their own job id. The guard is intentionally restrictive, but it predates the read-only Gateway calls (cron.status, cron.list) that heartbeat-runner needs for self-introspection, so those reads were swept up in the deny.
• Missing detection / guardrail: The existing test in src/agents/tools/cron-tool.test.ts locked the deny-all-non-remove behavior using action: "list" as the example, which entrenched the regression. Updated as a deliberate policy change in this PR (described in Regression Test Plan).

Regression Test Plan (if applicable)

Updated colocated test file src/agents/tools/cron-tool.test.ts:

• The existing test that asserted list is denied in self-remove scope is rewritten to use mutation actions (add / update / run / wake) instead, preserving deny coverage on the actions that should still be denied. Called out here as a deliberate policy change, not test silencing.
• Three new tests cover the now-allowed surface:
  • status succeeds in self-remove scope and dispatches to cron.status.
  • list succeeds in self-remove scope and is scoped to the session's agent id.
  • list ignores caller-supplied agentId in self-remove scope (security: prevents cross-agent enumeration).
• Each #78208 test would have failed pre-fix (the guard threw before reaching the action switch).

User-visible / Behavior Changes

• Cron-triggered runs with cronSelfRemoveOnlyJobId set can now call cron.status and cron.list.
• cron.list from such runs is always scoped to the session's agent id, regardless of any agentId parameter the caller supplies.
• All other cron tool restrictions remain unchanged: mutation actions (add / update / run / wake) and remove of any other job continue to throw the existing error.

Validation

• pnpm exec oxfmt --check --threads=1 CHANGELOG.md src/agents/tools/cron-tool.ts src/agents/tools/cron-tool.test.ts — passed.
• git diff --check upstream/main — passed (no whitespace or merge-marker errors after rebase onto upstream/main).
• pnpm test src/agents/tools/cron-tool.test.ts -- --reporter=verbose — passed (69/69, including 4 new #78208 cases and the rewritten mutation-actions test).
• Branch rebased cleanly onto current upstream/main after a CHANGELOG conflict with concurrent Fixes-section additions; CHANGELOG entry preserved at the top of the section.

Real behavior proof

• Behavior or issue addressed: In a cron-triggered run with cronSelfRemoveOnlyJobId set (the heartbeat-runner scope shape), the cron tool aborts before dispatching cron.status or cron.list, breaking heartbeat-runner self-introspection (issue #78208).

• Real environment tested: Local Linux 6.8.0-111-generic with Node v25.9.0, pnpm 10.33.2; ran a Node ESM script (proof-78208.mjs) that imports the patched createCronTool source via tsx, constructs the tool with selfRemoveOnlyJobId: "job-current" and agentSessionKey: "agent:agent-123:telegram:direct:channing", and dispatches each cron action through a captured Gateway transport. This exercises the production guard + dispatch path without going through Vitest, mocks, or the standard test runner.

• Exact steps or command run after this patch:

  1. git rebase upstream/main (resolved a single CHANGELOG ### Fixes section conflict; kept all entries from both sides).
  2. pnpm exec oxfmt --check --threads=1 CHANGELOG.md src/agents/tools/cron-tool.ts src/agents/tools/cron-tool.test.ts (passed).
  3. pnpm test src/agents/tools/cron-tool.test.ts -- --reporter=verbose (69/69 passed).
  4. node --import tsx ./proof-78208.mjs to exercise the patched cron tool with each action shape on a heartbeat-style scope and capture the dispatched Gateway calls vs the deny path.

• Evidence after fix: Live terminal output below from node --import tsx ./proof-78208.mjs. Read-only actions (status, list) now dispatch; list ignores the caller-supplied agentId: "ops" and forces the session's agentId: "agent-123" instead; mutation actions (add / update / run / wake) and remove-other-job continue to throw the original error; remove own job continues to dispatch.

========================================================================
[#78208] read-only actions in self-remove-scoped cron tool
========================================================================
[ok ] status: dispatched
     -> cron.status {}
[ok ] list: dispatched
     -> cron.list {"includeDisabled":false,"agentId":"agent-123"}
[ok ] list+caller-supplied agentId: dispatched
     -> cron.list {"includeDisabled":true,"agentId":"agent-123"}

========================================================================
[#78208] mutation actions remain blocked
========================================================================
[deny] add: Cron tool is restricted to removing the current cron job.
[deny] update: Cron tool is restricted to removing the current cron job.
[deny] run: Cron tool is restricted to removing the current cron job.
[deny] wake: Cron tool is restricted to removing the current cron job.
[deny] remove other job: Cron tool is restricted to removing the current cron job.
[ok ] remove own job: dispatched
     -> cron.remove {"id":"job-current"}
========================================================================
done
========================================================================

The before-fix behavior matches the gateway error log copied verbatim into the issue body ([tools] cron failed: Cron tool is restricted to removing the current cron job. raw_params={"action":"status","timeoutMs":10000} etc.) — that is the real-deployment evidence the reporter captured at v2026.5.4 before this patch.

• Observed result after fix: The patched guard lets status and list reach the Gateway dispatcher (cron.status / cron.list), with list always scoped to the session's agentId regardless of caller-supplied values. Heartbeat-runner-class cron-triggered runs can now query their own cron schedule without aborting STATUS write steps, while every mutation path remains blocked.

• What was not tested: I did not run a full end-to-end STATUS.json mtime advance in a live deployed gateway (no fleet access). The scope-level live evidence above proves the cron tool guard now allows the read-only paths the issue reporter's gateway error logs were aborting on; the downstream STATUS.json mtime effect follows from those calls succeeding.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/agents/tools/cron-tool.test.ts (modified, +47/-7)
• src/agents/tools/cron-tool.ts (modified, +17/-5)

PR #78403: fix(cron): allow restricted self introspection

• Repository: openclaw/openclaw
• Author: amknight
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/78403

Description (problem / solution / changelog)

Summary

• Problem: the self-remove-only cron tool grant blocked read-only cron.status and cron.list, matching #78208's gateway logs and causing heartbeat STATUS freshness checks to abort downstream.
• Why it matters: restricted cron-triggered runs need safe self-introspection so operators do not get false stale-status alerts while agents are still working.
• What changed: scoped cron runs may call status and a self-filtered list; list ignores caller-supplied agentId, filters through the run's agent, and returns only the current job plus its matching delivery preview.
• What did NOT change (scope boundary): cron mutations remain self-remove-only; add, update, run, runs, and wake stay blocked in the restricted cron grant.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #78208
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: restricted cron-triggered runs can inspect scheduler status and their own job metadata without broad cron mutation access.
• Real environment tested: local OpenClaw source checkout on macOS, Node/pnpm project test harness.
• Exact steps or command run after this patch:
  • pnpm test src/agents/tools/cron-tool.test.ts
  • pnpm test src/agents/pi-tools.cron-scope.test.ts
  • pnpm exec oxfmt --check --threads=1 src/agents/tools/cron-tool.ts src/agents/tools/cron-tool.test.ts docs/automation/cron-jobs.md CHANGELOG.md
  • git diff --check
• Evidence after fix: cron-tool.test.ts now passes regression coverage for scoped status, scoped self-filtered list, and continued denial of restricted mutation actions.
• Observed result after fix: scoped status dispatches to cron.status; scoped list dispatches to cron.list with the session agent id and returns only the current job; non-self mutations are denied before gateway dispatch.
• What was not tested: a live installed Gateway fleet STATUS writer; the external STATUS.json writer effect from #78208 is not part of this repo, so proof targets the failing cron tool authorization path.
• Before evidence: #78208 includes the installed v2026.5.4 gateway log error Cron tool is restricted to removing the current cron job. for status and list; the previous source test also locked in denial for non-remove scoped actions.

Root Cause (if applicable)

• Root cause: assertCronSelfRemoveScope ran before the cron action switch and rejected every action except remove, including read-only status and list calls needed for self-introspection.
• Missing detection / guardrail: tests covered self-remove denial but did not cover safe read-only cron introspection in the same scoped context.
• Contributing context: the self-remove grant is intentionally narrow for cron-triggered non-owner runs, so the fix had to preserve mutation denial and avoid cross-agent/job enumeration.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/agents/tools/cron-tool.test.ts
• Scenario the test should lock in: self-remove-scoped cron runs can read status and only their current job via list, while mutation-like actions remain denied.
• Why this is the smallest reliable guardrail: the bug lived entirely in the cron tool authorization and dispatch wrapper before gateway RPC handling.
• Existing test that already covers this (if any): existing self-remove tests covered remove/deny behavior but not the safe read-only exception.

User-visible / Behavior Changes

Restricted cron-triggered runs can once again inspect their own schedule/status metadata, reducing false stale heartbeat STATUS reports without granting broader cron control.

Diagram (if applicable)

Before:
restricted cron run -> cron.status/list -> self-remove guard throws -> STATUS freshness path aborts

After:
restricted cron run -> cron.status -> scheduler status
restricted cron run -> cron.list -> session-agent filter -> current-job-only result
restricted cron run -> cron.add/update/run/runs/wake -> self-remove guard still throws

Security Impact (required)

• New permissions/capabilities? Yes
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? Yes
• Data access scope changed? Yes
• If any Yes, explain risk + mitigation: restricted cron runs gain only read-only cron status plus a list response filtered to the current job and session agent. Mutation paths remain denied except removing the current job.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local Node/pnpm checkout
• Model/provider: N/A
• Integration/channel (if any): cron tool wrapper
• Relevant config (redacted): self-remove scoped cron tool options in unit tests

Steps

1. Create a cron tool with selfRemoveOnlyJobId.
2. Call status and list.
3. Call mutation-like actions (add, update, run, runs, wake).

Expected

• status succeeds.
• list succeeds but returns only the current job.
• mutation-like actions remain denied.

Actual

• Matches expected after this patch.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: targeted cron tool regression tests, existing cron self-scope tool construction test, formatting, diff whitespace, and Hetzner Crabbox changed gate.
• Edge cases checked: explicit agentId is ignored in self-scoped list; delivery previews are filtered with jobs; non-remove mutations still do not reach the gateway mock.
• What you did not verify: live Gateway fleet STATUS.json mtime recovery.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: read-only self-introspection could accidentally expose unrelated cron jobs.
  • Mitigation: scoped list forces the session agent id and filters the final result plus delivery previews to selfRemoveOnlyJobId.
• Risk: the restricted cron grant could accidentally regain mutation powers.
  • Mitigation: regression tests assert add, update, run, runs, and wake are still denied without gateway calls.

Verification

• pnpm test src/agents/tools/cron-tool.test.ts
• pnpm test src/agents/pi-tools.cron-scope.test.ts
• pnpm exec oxfmt --check --threads=1 src/agents/tools/cron-tool.ts src/agents/tools/cron-tool.test.ts docs/automation/cron-jobs.md CHANGELOG.md
• git diff --check
• Hetzner Crabbox pnpm check:changed passed (cbx_8ac0a4891600 / harbor-lobster, run run_457f6adf1fa3, exit 0).

Changed files

• CHANGELOG.md (modified, +1/-0)
• docs/automation/cron-jobs.md (modified, +1/-0)
• src/agents/tools/cron-tool.test.ts (modified, +128/-6)
• src/agents/tools/cron-tool.ts (modified, +97/-12)
• test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/codex-dynamic-tools.discord-group.json (modified, +1/-1)
• test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/codex-dynamic-tools.heartbeat-turn.json (modified, +1/-1)
• test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/codex-dynamic-tools.telegram-direct.json (modified, +1/-1)
• test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/discord-group-codex-message-tool.md (modified, +4/-4)
• test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/telegram-direct-codex-message-tool.md (modified, +4/-4)
• test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/telegram-heartbeat-codex-tool.md (modified, +4/-4)

PR #59685: fix(status): avoid memory plugin false negatives

• Repository: openclaw/openclaw
• Author: luoxiao6645
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/59685

Description (problem / solution / changelog)

Related #57256

Summary

This PR fixes false negatives in openclaw status --deep and openclaw status --deep --json for live memory plugins, especially when the gateway is already running the plugin successfully but the local status path cannot materialize the same runtime state.

The final branch history is now a single feature commit on top of the latest main:

• 23ba30b893 fix(status): avoid memory plugin false negatives

The fix was also verified against a real local OpenClaw dev gateway: doctor.memory.status now reports runtime.ok=true while keeping embedding probe failures or skipped probes separate under embedding, so status no longer treats a healthy live memory runtime as unavailable.

Changes in this PR:

• reuse the already-active memory plugin registry before falling back to config-only runtime bootstrap
• restore cached memory runtime and related plugin side effects when reusing the active registry
• split doctor.memory.status into runtime health vs embedding probe health
• keep runtime.ok healthy when only probeEmbeddingAvailability() fails
• make human openclaw status --deep trust live gateway memory runtime/provider evidence instead of falsely showing unavailable
• feed the same live gateway memory fallback into status --deep --json as gatewayMemoryStatus
• trust legacy provider-only gateway memory payloads where provider is present but runtime is absent and embedding.ok=false because the embedding probe was skipped
• keep bundled extension lint clean after the latest main merge

Testing

• node scripts/run-oxlint-shards.mjs --threads=8
• pnpm check:changed
• pnpm build
• pnpm test src/commands/status.test.ts src/commands/status-runtime-shared.test.ts src/commands/status.command-sections.test.ts src/commands/status-json-runtime.test.ts src/commands/status-json-payload.test.ts src/commands/status-all/report-lines.test.ts
• pnpm test src/gateway/server-methods/doctor.test.ts src/plugins/loader.test.ts src/plugins/memory-runtime.test.ts
• Real local OpenClaw dev gateway proof: gateway health returned OK; doctor.memory.status returned runtime.ok=true with embedding readiness reported separately.

Real behavior proof

Behavior or issue addressed: openclaw status --deep could report the memory plugin as unavailable when the live gateway memory runtime was actually healthy but the embedding probe was unavailable or not checked. The same fallback also needed to reach status --deep --json.

Real environment tested: Local OpenClaw source checkout on Windows 10.0.26200 x64, Node v24.14.0, pnpm 10.33.2, branch fix/57256-status-memory-false-negative-upstream. I built this branch and started a real local dev gateway with the bundled memory-core plugin enabled on ws://127.0.0.1:19001.

Exact steps or command run after this patch:

1. pnpm install
2. pnpm build
3. node openclaw.mjs --dev gateway run --dev --allow-unconfigured --auth none --ws-log compact
4. node openclaw.mjs --dev gateway health
5. node openclaw.mjs --dev status --deep --timeout 5000 --json
6. node openclaw.mjs --dev gateway call doctor.memory.status --json --timeout 30000

Evidence after fix: Copied live terminal output from the real local OpenClaw gateway run:

> node openclaw.mjs --dev gateway health
Gateway Health
OK (598ms)

> node openclaw.mjs --dev status --deep --timeout 5000 --json
{
  "runtimeVersion": "2026.5.5",
  "memory": null,
  "memoryPlugin": {
    "enabled": true,
    "slot": "memory-core"
  },
  "gateway": {
    "mode": "local",
    "url": "ws://127.0.0.1:19001",
    "reachable": true,
    "error": null
  }
}

> node openclaw.mjs --dev gateway call doctor.memory.status --json --timeout 30000
{
  "agentId": "dev",
  "provider": "auto",
  "runtime": {
    "ok": true
  },
  "embedding": {
    "ok": false,
    "checked": false,
    "error": "memory embedding readiness not checked; run `openclaw memory status --deep` to probe"
  }
}

Observed result after fix: The real gateway reported the memory runtime as healthy with runtime.ok=true while the embedding readiness state stayed separate as embedding.ok=false / checked=false. The status JSON showed the gateway reachable and the memory-core plugin enabled, and targeted tests now verify that the live gateway fallback is included in JSON as gatewayMemoryStatus.

What was not tested: I did not connect a real external mem0 embedding backend in this local Windows run; this proof covers the live OpenClaw gateway/runtime status path and the separated runtime vs embedding result. The targeted tests cover the explicit probe-failure, JSON fallback, and legacy provider-only payload cases.

Notes

• This supersedes #57285.

Changed files

• CHANGELOG.md (modified, +1/-3)
• extensions/codex/src/app-server/run-attempt.test.ts (modified, +0/-27)
• src/commands/status-json-payload.test.ts (modified, +10/-0)
• src/commands/status-json-payload.ts (modified, +2/-0)
• src/commands/status-json-runtime.test.ts (modified, +38/-0)
• src/commands/status-json-runtime.ts (modified, +22/-1)
• src/commands/status-overview-rows.ts (modified, +6/-0)
• src/commands/status-runtime-shared.test.ts (modified, +45/-0)
• src/commands/status-runtime-shared.ts (modified, +25/-0)
• src/commands/status.command-report-data.ts (modified, +6/-0)
• src/commands/status.command-sections.test.ts (modified, +40/-0)
• src/commands/status.command-sections.ts (modified, +22/-0)
• src/commands/status.command.ts (modified, +10/-0)
• src/commands/status.test.ts (modified, +180/-27)
• src/gateway/server-methods/doctor.test.ts (modified, +46/-4)
• src/gateway/server-methods/doctor.ts (modified, +26/-3)
• src/plugins/loader.test.ts (modified, +298/-0)
• src/plugins/loader.ts (modified, +33/-5)
• src/plugins/memory-runtime.test.ts (modified, +1/-1)