[FEATURE] Routines have no durable in-app notification surface — findings only survive by being written into Calendar/Gmail

Summary

A routine that discovers something worth telling me has no durable place inside the app to put it. PushNotification is the only real notify channel, and its persistent leg is the phone push — the desktop leg is an ephemeral OS toast. So the moment a routine has an actual finding, the only way to make that finding survive until I next open the app is to write it into a third-party product: a Google Calendar event, a Gmail draft. That's what I ended up doing, and it's clearly the wrong shape.

Please add a first-class in-app notification target: a short message a routine can post that persists in the desktop app, waits quietly, and links back to the session that produced it. Explicitly not an OS toast, not a bell badge, not an interrupt.

Why the existing surfaces don't cover it

1. The routine's final message is not a notification. Each run spawns its own session; "notify the owner" in a routine prompt produces text in a session nobody is looking at. This is easy to get wrong — several of my own SKILL.md files assumed the final summary would reach me. It doesn't.

**2. The sidebar unread dot is per-run, not per-signal.** It marks "this routine executed," which for a 2-hourly watcher is ~12 dots a day, almost all of them "nothing happened." The thing I need surfaced is the rare run where the agent decided something matters. A run-level indicator can't express that, and at that volume it trains you to ignore it. (See #79126 — dots accumulate to the point users want a mark-all-read just to quiet them.)

3. PushNotification delivers, but nothing stays in the app. Phone push works and is genuinely good — it follows Anthropic's own infrastructure and I want to keep it. But it's fire-and-forget: dismiss it on the phone and the signal is gone. The desktop half is an OS toast, which is both ephemeral by design and historically unreliable on Windows (#60220, #76152). Nothing is left in the app to come back to.

What this actually forces users to build

My real routine (monitor-gmc-feed-support-replies, every 2h) watches for Google/Shopify support replies on a broken Merchant Center feed. To make sure a finding actually reaches me, it fans out to every channel it can reach:

| Channel | Result |
|---|---|
| Phone push via PushNotification | Works well — but ephemeral, and needs Remote Control live for a headless run |
| Google Calendar event | Abuse of the tool. It isn't a scheduled event; it's a message. Pollutes a real calendar and I have to clean it up |
| Gmail draft | Abuse of the tool. Gmail MCP can't send, so a draft-to-self is the only option — an unsent email sitting in my drafts as a makeshift inbox |
| Its own session's final message | Never seen |

Two of those four are third-party products bent into a notification inbox they were never meant to be. They also need connectors attached to the routine, which is its own source of breakage in headless runs (#79319). None of this should be necessary to say "the thing you asked me to watch for happened."

Proposed behavior

An in-app delivery target for agent-initiated notifications:

1. A routine (or any background session) can post a short message — one line, plus a link to the originating session for detail.
2. It persists until read or dismissed. Opening the desktop app hours later still shows it.
3. It's quiet. No OS toast, no sound, no bell badge, no auto-expanding sidebar. It waits.
4. It's agent-authored and deliberate — it fires only when the routine calls it, which is what makes it different from a per-run indicator. Silent runs stay silent.
5. Composable with push, not a replacement. Ideally one call reaches both: something like PushNotification({ message, status: "proactive", deliver: ["in-app", "push"] }), or a separate tool if that's cleaner. Phone push for "know now," in-app for "still here when you get back."

On the "no bells" point — I want to be clear this is a feature request for restraint. A notification center that badges and chimes and clusters everything would be worse than what exists today. The value is entirely in it being durable and quiet: a small, honest list of things routines decided I should know, sitting where I'd naturally look.

Related, but different asks

• #79126 — persisting the Routines sidebar collapse + mark-all-read. Same underlying noise problem, but it's about taming run-level indicators. This asks for a separate agent-authored signal channel so those indicators don't have to carry meaning they can't carry.
• #79080 — consolidated digest when several routines fire together. Aggregates the notifications that already exist; doesn't add a durable in-app place for them to land.
• #60220 / #76152 — Windows desktop toasts not firing. Delivery bugs in the OS-toast path. This request largely routes around that path rather than depending on it.
• #70029 (closed) — routines couldn't access PushNotification. Access is fixed; the missing destination is not.
• #76841 — no way to reopen a routine's session in the mobile app once the notification is gone. The same missing-destination problem seen from the phone side: the push is ephemeral and nothing durable remains behind it.

Environment

• Claude Code 2.1.214, Claude desktop app on Windows 11 (26200)
• 4 local scheduled tasks under ~/.claude/scheduled-tasks/, cadences from 2h to daily

🤖 Filed with Claude Code