Summary

• Problem: heartbeat delivery defaulted to target: "last", so unattended heartbeat alerts could route to the last external DM (including Discord DMs).
• Why it matters: this creates leakage/spam risk for mixed personal+external chats and conflicts with internal-only heartbeat workflows.
• What changed: default heartbeat target now resolves to none; docs/config references updated; cron/exec heartbeat prompt wording now switches to internal-only language when outbound delivery is disabled.
• What did NOT change (scope boundary): explicit target: "last" / explicit channel targets still work as before; outbound channel implementations unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• 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 [Bug]: Heartbeat prompts incorrectly routed to Discord DMs #25871
• Closes [Feature]: safer default for heartbeat.target routing #24638
• Closes Heartbeat system events should not hardcode 'relay to user' instruction #25851
• Related fix: harden routing/session isolation for followups and heartbeat #25881

User-visible / Behavior Changes

• Default heartbeat target changed from last to none when unset.
• Heartbeats now require explicit target config for external delivery.
• Cron/exec heartbeat prompt text uses internal-only wording when delivery is disabled.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22 + pnpm
• Model/provider: N/A (unit + integration tests)
• Integration/channel (if any): heartbeat routing + prompt generation
• Relevant config (redacted): heartbeat defaults with unset target / target: "none"

Steps

1. Run heartbeat delivery resolution with config missing heartbeat.target.
2. Trigger cron/exec heartbeat flows with target: "none".
3. Observe outbound send behavior and prompt text.

Expected

• Unset target resolves to internal-only (none).
• No outbound send when delivery disabled.
• Cron/exec event prompts do not tell agent to relay to user.

Actual

• Matches expected after patch.

Evidence

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

Human Verification (required)

• Verified scenarios:
  • resolveHeartbeatDeliveryTarget default behavior now target-none.
  • Internal-only cron prompt path with queued cron event + target: none.
  • Internal-only exec prompt path with queued exec event + target: none.
• Edge cases checked:
  • Explicit target: "last" coverage kept in tests.
  • Existing target/account allow/deny coverage preserved.
• What you did not verify:
  • Live Discord DM end-to-end on external runtime (covered by unit/integration tests only).

Compatibility / Migration

• Backward compatible? (No)
• Config/env changes? (No)
• Migration needed? (Yes)
• If yes, exact upgrade steps:
  1. If you rely on outbound heartbeat delivery, set agents.defaults.heartbeat.target explicitly ("last" or channel id).
  2. Optionally set heartbeat.to/accountId for deterministic routing.

Failure Recovery (if this breaks)

• How to disable/revert this change quickly:
  • Set agents.defaults.heartbeat.target: "last" to restore prior default behavior.
• Files/config to restore:
  • src/infra/heartbeat-runner.ts
  • src/infra/outbound/targets.ts
• Known bad symptoms reviewers should watch for:
  • No outbound heartbeat alerts when users expected old implicit delivery.

Risks and Mitigations

• Risk: users depending on implicit last-recipient delivery may think heartbeat is broken.
  • Mitigation: docs/changelog updated + explicit migration note in this PR.
• Risk: prompt wording change could alter model behavior in no-delivery mode.
  • Mitigation: added new unit/integration tests for cron + exec internal-only prompt paths.

Mintlify

0 threads from 0 users in Mintlify

• No unresolved comments

Greptile Summary

Changed the default heartbeat delivery target from last to none, preventing unattended heartbeat alerts from routing to external channels (including Discord DMs) unless explicitly configured. When delivery is disabled (target: "none"), cron and exec event prompts now use internal-only language that avoids instructing the agent to relay messages to users.

Key Changes:

• Default heartbeat target in src/infra/heartbeat-runner.ts:99 and src/infra/outbound/targets.ts:213 changed from "last" to "none"
• New buildExecEventPrompt function with deliverToUser option to generate internal-only or user-facing prompts
• Updated buildCronEventPrompt to accept deliverToUser option and generate appropriate prompt wording
• Prompt selection logic in heartbeat-runner.ts:650-657 determines canRelayToUser based on delivery channel, target, and visibility settings
• Comprehensive test coverage for default target behavior and internal-only prompt paths
• Documentation updated across heartbeat.md, configuration-reference.md, and cron-vs-heartbeat.md to reflect new defaults

Migration Impact:
Users relying on implicit last recipient delivery will need to explicitly set agents.defaults.heartbeat.target: "last" to restore previous behavior.

Confidence Score: 4/5

• This PR is safe to merge with low risk, addressing a legitimate privacy/leakage concern with thorough testing
• The change is well-implemented with comprehensive test coverage for both default target behavior and prompt internalization. The logic correctly determines when to use internal-only prompts based on delivery configuration. However, this is a breaking change that will affect users expecting implicit external delivery, so the migration path must be clearly communicated (which it is in the PR description and CHANGELOG).
• No files require special attention - the implementation is solid and well-tested

_{Last reviewed commit: 34a754d}