ScheduleWakeup / self-paced loop never fires - the session only wakes when the user types
Follow-up to #93110 (same user - Coupang delivery driver in Korea, 17-hour days,
one day off every 23 days, building a trading system with Claude Code for over a year).
The problem
I asked Claude to run a self-paced loop so it would keep working on my project between
my visits. It scheduled wakeups with ScheduleWakeup and told me it would check back
every 25-30 minutes.
It never fired. Not once. Measured gaps between when it said it would wake up and
when it actually resumed:
| Scheduled | Actually resumed | Gap |
|---|---|---|
| every ~25 min | after I typed | 6h 22m |
| every ~25 min | after I typed | 27h 39m |
| every ~25 min | after I typed | 10h 24m |
| every ~25 min | after I typed | 46h |
Every single time, the session only came back to life when I typed something.
What we ruled out
This isn't sleep or a crash. We checked:
- Windows uptime: 6 days continuous,
Kernel-Power 42(sleep) events: 0 - Claude Code processes: alive the whole time (13 processes, started 6 days prior)
- The bots and scheduled tasks I run outside Claude: all still running normally
So the machine was awake, the app was alive, and only the wakeup timer never fired.
Why this matters
I sit down at the computer for a short while every 2-3 days. The entire value of a
self-paced agent loop for someone like me is that it keeps working while I'm out
driving. If it only runs while I'm actively typing, it's not an agent - it's a chat
window.
The assistant kept telling me "I'll check back in 25 minutes and continue." I'd come
back two days later and nothing had happened. I had to ask "is it working?" every time,
and every time the answer was that the loop had silently stopped.
Workaround we ended up building
Claude ended up writing a completely separate daemon for me:
- a Python process that loops every 30 seconds
- registered as a Windows Scheduled Task so it restarts if it dies
- it runs the experiments, health checks and report generation on its own
- results land in markdown files I can read whenever I sit down
That works. It has now run continuously for days. But the whole point ofScheduleWakeup was to avoid needing that, and building it required the assistant to
write a process supervisor, a PID/heartbeat liveness check, and a watchdog task. An
ordinary user can't do that.
Ask
Either make ScheduleWakeup actually fire when the app is running, or be explicit in the
docs/UI that it only resumes on user input - so people don't plan around something that
doesn't happen. Right now the assistant confidently says "I'll wake up in 25 minutes" and
it simply isn't true.
Thanks.
---
*P.S. I gave up on building my own tools a long time ago - that's exactly why I rely on
this one. I have plenty more feedback where this came from. Buy me a meal and I'll tell
you all of it. Dario Amodei, that means you.* 🍚
3 Comments
Contact: yongtai7@gmail.com
I only sit at the computer for a short while every 2-3 days, so I will probably miss
replies here. Email reaches me.
Happy to provide logs, timestamps, session IDs, or anything else that helps - I have a
year worth of them. And there is more feedback where this came from.
I can also speak to UX/UI from a Korean user perspective - not as a designer, just
as someone who actually uses this after a 17-hour shift and can tell you exactly where it
gets confusing. If that is useful to anyone on the team, reach out.
Good luck, and good night.
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate of #93110 — and I have three more days of measurements.
Why this is separate from #93110
#93110 is about the model not knowing what time it is inside a conversation.
This issue is about the session not waking up at all. They interact, but fixing one does not fix the other:
UserPromptSubmithook that injects the timestamp. That fixed #93110 for me completely.A clock does not make the alarm ring.
(I have not checked #92847 or #91523 — if either is genuinely the same failure, close this one in
favour of it. But please don't fold it into #93110.)
Updated measurements (3 more days since I filed this)
| Scheduled at | Due | Actually resumed | Gap |
|---|---|---|---|
| 09-10 01:12 | 01:44 | 01:17 | fired |
| 09-10 02:55 | 03:35 | 09-10 21:21 | 18h 04m |
| 09-11 05:45 | 06:15 | 05:53 | fired |
| 09-11 06:05 | 06:46 | 09-12 00:12 | 18h 07m |
| 09-12 00:16 | 00:46 | 09-12 06:37 | 6h 21m |
Six wakeups, three failed. Average gap on failure: 14h 11m.
All three times, the session only resumed because I typed something.
What makes this expensive rather than merely annoying
The machine was never the problem. On the same box, 15 Windows scheduled tasks ran the whole
time without a single miss — 1-minute, 2-minute, 13-minute intervals, all green.
The difference is that those daemons only run scripts. They cannot notice that a number looks
wrong, or that a conclusion from yesterday has been invalidated. In one of those 18-hour gaps I
later found a unit bug that had silently corrupted two days of analysis. No daemon would ever
have caught it, because nothing was broken - the numbers were just wrong.
So the gap is not "the assistant was idle for 18 hours." It is "nobody was thinking for 18 hours,
and the work kept building on a bad result."
What I ended up doing
Running
ScheduleWakeupandCronCreatein parallel, hoping one of them fires. That is aworkaround, not a fix, and I only know to do it because I measured the failure rate.
Happy to provide session IDs or logs.
Contact: yongtai7@gmail.com