Scheduled routine email notifications silently fail (still reproducing, related to #84645 / #80880)
Status Open
Maintainer reply None cached
Activity 3 comments · opened Sep 22, 2026
Related to #84645 and #80880, both closed as "not planned." Opening as a new issue since the underlying bug still reproduces cleanly and neither closed issue has activity — filing separately for visibility in case it helps get this looked at again.
Setup:
- Scheduled routine (daily weekday trigger, cron
30 13 * * 1-5) - Notification channels: Email ✓ enabled, Push ✗ disabled, Slack ✗ disabled (confirmed via the routine's own config)
- These settings were last saved 2026-09-21 20:11 UTC — over 17 hours before the affected run, so this isn't a "settings need one more run to take effect" lag issue.
Run in question:
- Fired 2026-09-22 13:39:12 UTC (~9:39 AM EDT)
- Completed successfully (status: succeeded), full
<routine_summary>produced as the final result - Despite Email being the only enabled channel, no email was received — checked spam/junk, and confirmed the account's email address is correct
- Interestingly, the run's own final step still called the
PushNotificationtool (returned "Mobile push requested") even though Push is toggled off for this routine — suggesting the agent-side notification call and the platform-side channel routing aren't in sync, which may be related to why Email silently does nothing here.
No error, no log, nothing user-facing to indicate delivery failed. I also left a comment with these same details on #84645: https://github.com/anthropics/claude-code/issues/84645#issuecomment-5779171448
3 Comments
Your observation suggests two contracts are being conflated: the agent-side notification tool call and the platform-side channel delivery. I would record, per run and per channel, the trigger/run identity, persisted routine revision, enabled-channel snapshot, and typed states such as requested, rejected-disabled, queued, provider-accepted, delivered, failed, and unknown-after-handoff. A successful routine must not imply successful notification delivery.
The worker should read the same persisted channel revision that the routine UI saved, reject or suppress calls to disabled channels, and expose a redacted provider result in the run summary. Focused tests could cover email-only with push disabled, stale worker configuration, provider timeout, retry/duplicate suppression, timezone boundaries, and a disconnect after provider handoff. That would make this distinguish a disabled-channel call from an email provider failure instead of silently reporting success.
Having the exact same issues and tested it against three different client tenants
Having also the same issue, quite frustrating indeed.