Best possible solution:

Land the isolated-session tool fix with regression coverage, and either explicitly accept or split the stricter remove error contract while tracking any existing-job cleanup separately.

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

Yes, source inspection gives a high-confidence path: current main auto-stamps caller sessionKey after cron add normalization and returns success for missing cron.remove ids. I did not run the harness because this review is read-only.

Is this the best way to solve the issue?

Mostly yes: the PR fixes future tool-created isolated cron jobs that would inherit caller session keys. The missing-id remove error is a stricter API contract and should be maintainer-accepted or split before merge.

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

Label changes:

• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Override: A maintainer applied proof: override for this PR.
• remove rating: 🦪 silver shellfish: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.
• remove status: 📣 needs proof: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

• P1: The linked bug can misroute scheduled cron output into active dashboard sessions and disrupt real user workflows.
• merge-risk: 🚨 compatibility: The PR intentionally changes the observable cron.remove missing-id contract from successful no-op to gateway error.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Override: A maintainer applied proof: override for this PR.

PR surface:

Source +9, Tests +51. Total +60 across 4 files.

Acceptance criteria:

• node scripts/run-vitest.mjs src/agents/tools/cron-tool.test.ts src/gateway/server-methods/cron.validation.test.ts

What I checked:

• Current main still auto-stamps sessionKey: Current main stamps resolvedSessionKey onto any cron add job missing sessionKey; this is the behavior the PR changes for normalized isolated jobs. (src/agents/tools/cron-tool.ts:673, f09b4ebe314e)
• PR branch guards isolated add requests: The PR branch adds a normalized sessionTarget check and skips the caller session key when the job is isolated. (src/agents/tools/cron-tool.ts:673, ac3ec4712b5c)
• Current main treats missing remove as successful no-op: Current main forwards context.cron.remove(jobId) and responds success even when removed is false. (src/gateway/server-methods/cron.ts:479, f09b4ebe314e)
• PR branch changes remove-not-found to invalid request: The PR branch returns INVALID_REQUEST and exits when context.cron.remove(jobId) reports removed: false. (src/gateway/server-methods/cron.ts:480, ac3ec4712b5c)
• Remove result contract is internal but observable: The cron service returns { ok: true, removed } after exact-id removal, so changing the gateway response for removed: false is an observable API/CLI contract change. (src/cron/service/ops.ts:462, f09b4ebe314e)
• Related issue shows user-visible impact: The linked report describes shipped v2026.5.22 cron jobs colliding with WebUI dashboard sessions and missing-id removals returning successful-looking removed:false, which matches the two changed surfaces.

Likely related people:

• vincentkoc: Current-line blame for the touched cron tool and gateway handler paths points to recent cron/e2e hardening work in commit 87a2eba. (role: recent area contributor; confidence: medium; commits: 87a2eba42763; files: src/agents/tools/cron-tool.ts, src/gateway/server-methods/cron.ts)
• steipete: Recent history shows broad cron file movement and stabilization work, including the latest shipped release commit touching the central cron files. (role: recent cron refactor contributor; confidence: medium; commits: a374c3a5bfd5, bcbfb357bec7; files: src/agents/tools/cron-tool.ts, src/gateway/server-methods/cron.ts, src/cron/service/ops.ts)
• vignesh07: The session namespace routing behavior around caller session resolution appears to date to commit f988abf. (role: session routing feature contributor; confidence: medium; commits: f988abf202e3; files: src/agents/tools/cron-tool.ts)
• thewilloftheshadow: Gateway cron parameter compatibility for jobId/id traces to commit 25297ce, which is adjacent to the changed cron.remove handler. (role: gateway cron method contributor; confidence: medium; commits: 25297ce3f504; files: src/gateway/server-methods/cron.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.

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.