Cloud scheduled routines (RemoteTriggers) fire but never start a session on the paired Mac

Cloud scheduled routines (RemoteTriggers) fire but never start a session on the paired Mac

Summary

I run ~31 scheduled cloud routines that execute on a paired Mac through the claude remote-control
bridge. Since roughly 2026-07-05, a large and growing fraction of them fire server-side and never
start a session on the machine.

There is no error anywhere. The trigger stays enabled, ended_reason stays empty, last_fired_at
advances on schedule, and a manual /run returns HTTP 200 with a session_id — but no session is
created, nothing appears in claude-remote-control.log, and no transcript .jsonl is written. The
work simply doesn't happen and nothing reports a failure.

On 2026-07-22, 7 of 18 due routines were dropped (11 ran) with the Mac awake the whole time.

The part I think matters beyond my own setup: a dropped dispatch is unrecoverable and invisible.
There's no retry, no dead-letter, and no signal. I only found it after writing a checker that
reconciles cron expectations against session-transcript birth times. Two of my routines had been
dead for 6 and 9 days before anyone noticed — because nothing failed, nothing ran.

Environment

• macOS 15 (Darwin 25.5.0), Mac stays awake, Claude Code desktop app running
• 4 bridge processes (claude remote-control), one per project
• Triggers created via POST /v1/code/triggers, persist_session: false, all sharing one environment
• Wired Ethernet; Wi-Fi disabled entirely since 2026-07-21

Symptom

last_fired_at advances on schedule; no session is created. From 2026-07-22 (local time UTC+7):

| due | routine | cloud fired | session created |
|---|---|---|---|
| 02:00 | daily report generator | ✅ 19:02:55Z | ❌ none |
| 03:00 | spreadsheet sync A | ✅ 20:03:10Z | ❌ none |
| 03:07 | hourly ingest job | ✅ | ❌ none |
| 04:00 | spreadsheet sync B | ✅ 21:03:27Z | ❌ none |
| 04:15 | calendar mirror | ✅ | ❌ none |
| 06:00 | calendar→DB forward sync | ✅ 23:02:27Z | ❌ none |
| 06:30 | asset-linking job | ✅ 23:32:02Z | ❌ none |

Eleven other routines ran normally in the same window, on the same machine, bridge and environment —
including the hourly ingest job at 02:13, 04:16, 05:08 and 06:16, i.e. on both sides of its own
dropped 03:07 fire.

Full-day measurement the previous day: 33 ran / 10 dropped, including a silent 1h50m stretch
(12:15→14:04) with no session created at all.

Ruled out

1. Machine asleep/off — sysctl -n kern.boottime shows 1 day 9 hours of continuous uptime

covering every drop above. (A powered-off Mac produces an identical signature — same frozen
log, same advancing last_fired_at — so I check this first now, every time.)

1. Environment drift / auto-disable — a guard job reconciles every trigger against the live

environment every 2h; its 02:05 run that morning reported 31/31 correct, 0 repaired. Every
dropped trigger was enabled: true with ended_reason: "".

1. Concurrency — drops don't correlate with load. One drop happened with exactly one session

active; fires succeeded the same day with three concurrent sessions.

1. Network interface — the Mac was on Wi-Fi; I moved it to wired Ethernet, then discovered the

bridges held their original TCP sockets and had to disable Wi-Fi entirely to force all 4 onto the
wired interface (verified with lsof -nP -a -p <pid> -iTCP -sTCP:ESTABLISHED). The drops
continued unchanged the next morning — that's the 7/18 table above.

1. One bad routine — it's not one. Over two weeks it has hit at least 10 different routines

across unrelated schedules.

Reproduction

A manual fire reproduces it on an idle, awake machine:

POST /v1/code/triggers/<id>/run
→ HTTP 200, session_id: cse_…, last_fired_at advances
→ on the Mac: no log line, no new .jsonl, no session

So the loss happens after dispatch is acknowledged, not at scheduling time.

Strongest signal: local scheduled-tasks on the same Mac are unaffected

I run both cloud RemoteTriggers and local Claude Code scheduled-tasks on this machine. Through the
exact 02:00–06:30 window in which 7 cloud routines vanished on 2026-07-22:

• cloud: 11/18
• local: 4/4 — including a task that fires every 2h, which ran cleanly at 00:04, 02:04, 04:04 and 06:04

Same Mac, same hours, same app. The only difference is whether the run is delivered over cloud
dispatch.

Pattern

Frequency appears protective: hourly routines nearly always survive, while once-daily routines in
the 02:00–07:00 window are the ones that disappear. That's consistent with an idle-connection
issue — a bridge connection quiet for a long interval accepts the dispatch but never delivers it —
though I can't see far enough into the transport to confirm.

What would help

1. Server-side visibility into whether a dispatch was delivered and acknowledged by the bridge,

as distinct from "fired" — last_fired_at can't distinguish the two today.

1. Retry or dead-lettering when the bridge never picks up a dispatch.
2. Failing those, a way to query the last dispatch a bridge actually accepted per trigger, so

monitoring doesn't require reconciling cron expressions against transcript file birth times.

Workaround

I moved the five worst-hit daily routines back to local scheduled-tasks and disabled their cloud
triggers. Local has catch-up-on-wake, so a missed local run re-fires; a dropped cloud dispatch does
not. All five immediately caught up and recovered the previous night's lost work. This is a
workaround — 26 cloud triggers remain and are still dropping.

Happy to provide trigger IDs, raw trigger payloads, or bridge logs privately, or to run any
diagnostic that would help narrow this down.