Routines list empty (API + Web UI) and permission push notifications not arriving, execution still works
Status Open
Maintainer reply None cached
Activity 6 comments · opened Sep 8, 2026
Since 2026-09-08 (JST), two related symptoms:
- Push notifications for permission prompts (PC session → mobile app) are not arriving on my iPhone. Verified: notification permission is ON for the Claude app, Focus mode is OFF, Low Power Mode not the cause. Remote Control connection itself (chat with the terminal session from mobile) works fine.
- My scheduled routines list at claude.ai/code/routines shows 0 items, both in the web UI and via the routines list API. However, the routine itself is still executing normally on the bridge environment (PC) today — so execution is unaffected, only the listing/visibility is broken.
This seems related to the known issue where Remote Control mobile fails a repository access check and blocks conversation (#44805, #56988, #34619), reported around 2026-09-07.
Can you confirm whether this is a known backend issue?
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Following up — this is still happening 2 days later with zero response (not even the automated triage reply). This is actively blocking my ability to approve permission prompts remotely from my phone, which I rely on daily. Could someone take a look? Happy to provide more diagnostic info if helpful.
Additional detail: push notifications for approval prompts ARE arriving on my MacBook (desktop), but NOT on my iPhone (Remote Control app). This suggests the notification delivery issue may be specific to iOS/mobile push delivery rather than a general backend outage. Still blocking daily routine approvals from my phone.
Still happening one week later (2026-09-15). Routines list via both the API and Web UI (claude.ai/code/routines) still returns 0 items, even though I have 3 active routines and they continue to execute normally on the local bridge environment. Still no response from the team on this thread. Would appreciate any update on status.
New diagnostic finding: I created a brand-new test routine via POST /v1/code/triggers (a one-off run_once_at ~1 year in the future, never fired) and it DOES show up correctly in GET /v1/code/triggers (list returns 1 item). Meanwhile my 3 pre-existing routines still return 0 in the same list call, right after creating the new one in the same session.
This suggests the list/display mechanism itself is not fully broken — newly created routines list fine. The issue appears specific to the 3 pre-existing routines (created before ~2026-09-08), which seem to be excluded/hidden from the list response for some other reason (possibly a data migration issue, an account/session association problem, or similar), rather than a blanket list-rendering bug. Those 3 routines are still executing on schedule via the bridge environment, so their underlying job records are clearly intact — just not being returned by the list endpoint.
Happy to provide the trigger IDs of the 3 missing routines if that helps someone look these up server-side.
Correction / important update: I now believe the routines-list-shows-0 part of this report may NOT be a backend bug after all.
Today I re-tested with a Mac that had an active Claude Code bridge session running. Right after creating a new cloud routine via the API, the claude.ai/code/routines web UI initially showed only that 1 new routine — my 3 pre-existing local (bridge) routines were still missing. But about 9 minutes later, refreshing the same page, all 3 local routines appeared correctly, each labeled as local routines, with the UI showing a note: 'Local routines only run while the computer is turned on and online.'
Notably, GET /v1/code/triggers (the RemoteTrigger/routines API) still only returns the 1 cloud (CCR) routine even now — it appears this endpoint does not include local/bridge routines at all, which was a mismatch in how I was checking, not necessarily evidence of a bug. The web UI seems to use a different mechanism to surface local routines, gated on the local bridge being online/connected.
Given this, my working theory now is: my original 2026-09-08 report of '0 routines in web UI' may simply have happened while the Mac/bridge was offline or not actively connected at that moment, rather than a genuine backend bug. I can't fully confirm this retroactively, but it's a much more likely explanation than a server-side data issue, and I don't want to leave an inaccurate bug report open.
The separate issue in this thread — iOS push notifications for permission-approval prompts not arriving on the phone (while they do arrive on desktop) — is NOT explained by this and remains open/unresolved as far as I know.
Apologies for the noise on the routines-list part; leaving this open only for the mobile push notification issue unless someone wants more diagnostic info on the local-routines-list timing.