Scheduled tasks stamp lastRunAt but never launch a session (no error, no failed-run state)

# Scheduled tasks stamp `lastRunAt` but never launch a session

**Product:** Claude Code, desktop app (Code tab), macOS 15.6 (Darwin 25.6.0)
**First observed:** 2026-09-06 · **Still occurring:** 2026-09-09
**Severity:** all scheduled automation silently stopped; nothing surfaced it

## Summary

Scheduled tasks fire on time and update `lastRunAt`, but no session is created and
no work is done. There is no error, no notification, and no failed-run state. From
the registry the tasks look perfectly healthy — `enabled: true`, sensible
`cronExpression`, a moving `nextRunAt` and a fresh `lastRunAt` — which is why this
ran undetected for two days before anyone noticed the output had stopped.

A manual **Run now** from the sidebar fails in exactly the same way.

## The measurement that shows it

Session transcripts are written to `~/.claude/projects//.jsonl`, one
per session, so counting files by **birth time** counts sessions actually launched.

```
for f in *.jsonl; do stat -f '%SB' -t '%F' "$f"; done | sort | uniq -c
```

| Date | Session files created |
|---|---|
| 4 Aug – 5 Sep | 8–12 every day |
| 6 Sep | **0** |
| 7 Sep | **0** |
| 8 Sep | 6 — all within 25 minutes of an app restart |
| 9 Sep | **0** (as of 12:05 IST) |

Meanwhile `lastRunAt` kept moving. On 9 Sep, in tight clusters:

```
04:11:21.158Z task A (scheduled 07:07 local)
04:11:21.160Z task B (scheduled 09:35 local)
04:11:21.586Z task C (scheduled 07:07 local)
04:27:19.860Z tasks A, B, C again
04:43:19.871Z tasks D, E
04:58–04:59Z tasks F, G
```

Three tasks with three different scheduled times stamping within 0.43 s of each
other is not three jobs running — it looks like a dispatch loop retrying and
failing silently, roughly ten times across the morning, launching nothing.

## Ruled out (each measured, not assumed)

1. **The task files.** All present, non-empty, valid frontmatter. The recurring ones
are symlinks into a git repo (a supported layout here); `find -type l ! -exec test -e {} \; -print` returns
nothing. The app surfaced "the routine file is empty" for a 43,832-byte file.
2. **Machine asleep.** `pmset -g log` showed sleep during the original window, which
fitted perfectly and was wrong: re-timed to ~09:50 with the machine demonstrably
awake, the tasks fired and still did nothing.
3. **Stale sessions being reattached to.** ~230 archived on 8 Sep, finishing 06:52Z.
A fire at 08:54:17Z — two hours later — created no session.
4. **App state.** Claude.app restarted 10:46 IST 8 Sep (a superset of 3, since it
kills every session). The same 08:54:17Z fire still launched nothing.
5. **The cron path specifically.** A manual **Run now** produces no session, no side
effect and no transcript — twice, on 8 and 9 Sep. Whatever is broken sits in the
session launcher, not in scheduling.

The only period that worked in four days was the 25 minutes after an app restart,
when 5 sessions launched (including a deliberate one-per-minute probe). That is
consistent with "an already-open session blocks the launch", but it is untested —
the test requires zero sessions open at a fire, and a session cannot run it.

## Why this is worse than a crash

Every signal available to a user says the task ran:

- `lastRunAt` is fresh, so the registry looks healthy.
- No error, no notification, no failed-run indicator anywhere.
- `find -newermt` — the obvious way to look for recent session files — is GNU-only
and matches nothing on macOS BSD `find`, so a first-pass check silently reports
"no recent files" regardless. Even when it works, mtime matches a *resumed* old
session and reports it as a new one. Only birth time (`stat -f '%SB'`)
distinguishes them.

The failure is therefore invisible from inside. Ours surfaced only because a human
noticed a daily report had stopped arriving.

## Impact

Eight scheduled tasks stopped — a mix of daily reporting, database integrity
checks and CI monitoring. Three days of each were lost before it was diagnosed,
and everything since has been run by hand.

## What would help

1. Do not stamp `lastRunAt` unless a session was actually created — the stamp is
currently the strongest false signal in the system.
2. Surface a failed launch: a failed-run state, or a notification.
3. Confirm or deny whether an open session can block a scheduled launch.

Happy to supply the raw `stat` output, the registry dumps, or anything else useful.

Start from the scheduled-task launch path and the manual Run now entry point, then compare when lastRunAt is stamped with when a session transcript appears under ~/.claude/projects//.jsonl. Reproduce on macOS with a scheduled task and an open session if possible. Done means failed launches are visible, lastRunAt is not a false success signal, and the open-session blocking question is confirmed or ruled out.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.