Best possible solution:

Move cron cancellation to the cron/Gateway owner boundary: register active cron run abort handles, have tasks.cancel invoke that runtime, finalize the task row only after abort is requested, and keep main-session cron behavior explicit.

Do we have a high-confidence way to reproduce the issue?

Yes. The current-main source path shows cron task cancellation falls through to Task runtime does not support cancellation yet, and the linked report gives the CLI command sequence that reaches it.

Is this the best way to solve the issue?

No. The one-line ACP branch is only a plausible shortcut; the maintainable fix needs to reach the cron service's active abort path or a cron-owned detached-task runtime before changing task state.

Full review comments:

• [P1] Route cron cancellation through the cron runtime — src/tasks/task-registry.ts:2097
  Adding cron to the ACP branch does not actually cancel the active cron run. Cron task rows use cron/main session keys from resolveCronTaskChildSessionKey, while AcpSessionManager only cancels ready ACP sessions; generated agent:<agent>:cron:<job> rows will fail ACP resolution, and explicit ACP keys would still not abort the cron service's in-process AbortController. The fix needs a cron-owned active-run cancellation path before the task row is finalized.
  Confidence: 0.92

Overall correctness: patch is incorrect
Overall confidence: 0.92

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 520992a1defd.

Label changes:

• add P2: This is a normal-priority bug fix for operator cancellation of running cron tasks, with meaningful but bounded runtime impact.
• add merge-risk: 🚨 session-state: The diff can mark cron task state as cancelled without proving the underlying cron run/session was actually aborted.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🧂 unranked krab.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body only reports a Vitest run with mocked cancelSession and explicitly says no live cron job/MCP cancellation was tested. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P2: This is a normal-priority bug fix for operator cancellation of running cron tasks, with meaningful but bounded runtime impact.
• merge-risk: 🚨 session-state: The diff can mark cron task state as cancelled without proving the underlying cron run/session was actually aborted.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🧂 unranked krab.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body only reports a Vitest run with mocked cancelSession and explicitly says no live cron job/MCP cancellation was tested. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

PR surface:

Source 0, Tests +42. Total +42 across 2 files.

Acceptance criteria:

• [P1] node scripts/run-vitest.mjs src/tasks/task-executor.test.ts src/gateway/server-methods/tasks.test.ts src/cron/service/timer.test.ts src/commands/tasks.test.ts.
• [P1] Real CLI/Gateway proof cancelling a running isolated cron task through openclaw tasks cancel <taskId> with private details redacted.

What I checked:

• Current cancellation branch: Current main only sends runtime === "acp" tasks to getAcpSessionManager().cancelSession; this PR changes that condition to include cron. (src/tasks/task-registry.ts:2097, 520992a1defd)
• Cron child session keys are not necessarily ACP sessions: Cron task rows set runtime: "cron" and derive childSessionKey through resolveCronTaskChildSessionKey, which produces main-session cron run keys or generated agent:<agent>:cron:<job> keys for isolated jobs. (src/cron/service/task-runs.ts:38, 520992a1defd)
• ACP cancellation requires ACP metadata: ACP manager cancellation resolves a ready ACP session before cancelling; non-ACP session keys throw Session is not ACP-enabled rather than cancelling a cron run. (src/acp/control-plane/manager.cancel-session.ts:39, 520992a1defd)
• Cron active run owner: The cron service owns the AbortController in executeJobCoreWithTimeout and passes that signal into cron execution; the ACP manager path does not abort this controller. (src/cron/service/timer.ts:130, 520992a1defd)
• Entry point can route through a runtime owner: cancelDetachedTaskRunById already gives a registered runtime first refusal before falling back to core task cancellation, which is the right seam for a cron-owned cancellation path. (src/tasks/task-executor.ts:728, 520992a1defd)
• Adjacent tests show mocked-only coverage: Existing cancellation tests mock ACP and subagent controls; the proposed cron test follows that mocked shape rather than proving a live cron abort signal is requested. (src/tasks/task-registry.test.ts:3352, 520992a1defd)

Likely related people:

• Peter Steinberger: Current-line blame on cancelTaskById, cron task-run keying, and cron timeout code points to the recent source bridge commit, and task seam history also shows Peter's task refactor/revert work. (role: recent area contributor; confidence: medium; commits: 9fd5f9ee7ca0, da6e9bb76f16, 759d37635d5a; files: src/tasks/task-registry.ts, src/cron/service/task-runs.ts, src/cron/service/timer.ts)
• Mariano: git log -S 'Task runtime does not support cancellation yet' points to the background task lifecycle commit that introduced the central cancellation surface. (role: feature introducer; confidence: medium; commits: 17c36b5093da; files: src/tasks/task-registry.ts)
• Frank Yang: git log -S 'runAbortController' points to cron timeout abort handling, which is the active-run cancellation mechanism this fix needs to reach. (role: adjacent cron abort contributor; confidence: medium; commits: 1051f42f9638; files: src/cron/service/timer.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.