Fix subscribe cron notification delivery

[Mr-Lucky]

Summary

• Add internal agentguard subscribe --cron-notify-run mode that prints either the notification body or NO_REPLY
• Switch OpenClaw/QClaw threat-feed cron jobs to host announce delivery using channel: last
• Avoid relying on the agent turn to know Telegram chatId, while keeping no-op cron ticks silent
• Update cron tests, subscribe tests, README, skill docs, and changelog

Testing

• npm run build
• node --test dist/tests/feed-cron.test.js dist/tests/cli-subscribe.test.js

Type

• Bug fix
• New feature / detection rule
• Refactoring
• Documentation

Testing

• npm run build passes
• npm test passes (32 tests)
• Manually tested the change

Related Issues

Closes #

[github-actions]

AgentGuard PR Review

The patch introduces a few concrete regressions and security-sensitive gaps.

1. high — src/feed/cron.ts / OpenClaw cron delivery is changed to announce without validating the destination route

   • What can go wrong: The new OpenClaw/QClaw cron jobs now deliver through the host’s last chat route (delivery.mode = 'announce', channel = 'last'). If the saved “last chat route” is stale, user-controlled, cross-session, or points to an unexpected chat context, scheduled threat-feed notifications can be delivered to the wrong recipient. This is a confidentiality and integrity risk for security advisories.
   • Fix: Before installing announce-based cron, validate that the route is the authenticated, current user-owned chat target and is suitable for notification delivery. If not, fall back to a non-chat delivery mode or require explicit user confirmation.

2. medium — src/cli.ts around the new --cron-notify-run path can suppress real errors as NO_REPLY

   • What can go wrong: In the pullAdvisories catch block, any Cloud reachability error under --cron-notify-run now exits 0 and prints NO_REPLY. That hides genuine failures from cron consumers and monitoring, making outages indistinguishable from “no notification needed.” The same silent behavior is used for 404s and other failure modes, which can mask broken Cloud connectivity or protocol regressions.
   • Fix: Distinguish “no advisories / no notification” from transport or protocol failures. Keep NO_REPLY only for the empty-success case, and emit a non-zero exit code plus an error message for network/auth/server errors.

3. medium — src/feed/cron.ts changes OpenClaw native install command to send --announce --channel last without checking command support

   • What can go wrong: The native OpenClaw cron invocation now appends --announce --channel last unconditionally. If older OpenClaw versions do not support these flags, cron installation or execution will fail, breaking scheduled notifications.
   • Fix: Feature-detect support before adding these flags, or gate them behind a version check with fallback to the previous delivery mode when unsupported.

4. medium — src/cli.ts --cron-notify-run is exposed as a public CLI flag but not validated as internal-only

   • What can go wrong: Any local user or automation can invoke agentguard subscribe --cron-notify-run directly. Because it changes output semantics and suppresses errors, this can be used to bypass expected failure reporting in scripts that rely on the normal subscribe contract.
   • Fix: Enforce that --cron-notify-run only works when invoked from the installed cron context, or at least document and validate it as an internal mode that cannot be mixed with user-facing modes.