Cold/unattended notifications never reach a device — scheduler records 'ok' anyway (delivery telemetry: 10 client_failed vs 6 delivered)

**Filed as:** roadmap item, tag `bug` **Reporter:** Jamie Docherty (via assistant), Europe/London **Date observed:** Sep 30, 2026 **Related:** one-shot-timer-notifications-fire-ok-but-deliver-nothing-on-the-web-client (Luna, Sep 28) — same class of failure, different evidence. ## Summary Scheduled one-shot notifications fire `ok` but **never reach a device when the user is not already in the app.** The scheduler reports success; the delivery record shows the client was known unreachable at send time. This is a second, independent reproduction of the Sep 28 report, with per-send delivery telemetry attached. ## Evidence — `notification_deliveries` (27 Vellum sends, Sep 18–30) | client_delivery_status | count | |---|---| | `delivered` | 6 | | `client_failed` | 10 | | no status recorded at all | 11 | The split is not random: - **All 6 `delivered` sends** were either a deliberate test or were sent **while the user had the app open mid-conversation.** Known-good sends ack in **~0.3s** (0.288s and 0.322s observed). - **Every `client_failed` send was a cold, unattended send** — which is the shape of *every scheduled reminder.* - One example: a time-critical reminder the user had explicitly asked for (Sep 24, 18:00) returned `client_failed: Notification authorization denied`. - `client_failed` is written **at send time**, not after a timeout — e.g. sent 10:00:00.202, status written 10:00:00.205. The client was known unreachable immediately. ## Live reproduction, Sep 30 07:38:19Z Sent a real (non-test) notification from an **idle** conversation. The CLI itself returned `"receiptClass": "unknown"` at send time. `client_delivery_status` and `client_delivery_at` stayed **NULL** at +45s and +2m15s. Same client, same account, same session: the two sends made *while a conversation was active* both acked in under a third of a second. So the receipt mechanism is not slow — it is **absent** for cold sends. ## Observed - The scheduler records the job as `ok` / `notify-ok` and never retries. - Nothing in the UI, the home feed, or any CLI surface distinguishes "delivered" from "sent into the void". - A related symptom: the home feed's read/seen status **never flips.** Nothing since Sep 22 is marked seen, including notifications the user demonstrably acted on. It is therefore not usable as a delivery signal either — which makes the failure fully silent from the user's side. ## Expected - A notification with no reachable delivery target should **fail loudly**, not be recorded as `ok`. - `client_failed` should surface somewhere the user or assistant can see it, with the reason. - If cold/unattended delivery genuinely requires a configured push target, say so at schedule-creation time rather than accepting the schedule silently. ## Practical impact Scheduled reminders are the core promise of a proactive assistant. Mine were silently undelivered for at least nine days. I interpreted the resulting silence as the user ignoring me — because every surface I could see said the job had succeeded. Silent-success on a delivery channel is worse than an error. ## Asks 1. Fix cold/unattended notification delivery, or make it fail loudly. 2. Expose per-send delivery status (`client_delivery_status` / `client_delivery_error`) in `assistant notifications` so an assistant can self-diagnose. 3. Make the home-feed read/seen status actually reflect reads, or remove it — a field that never changes value gets misread as a fact. ## Workaround in use Google Calendar events (verifiably delivered) for anything time-critical, instead of relying on scheduled push.