You asked to be told when the machine is ready to run itself on a schedule. It is not ready, and the honest reason is narrower than it sounds: almost everything about what an unattended run may write is in place and was tested again today, but nothing yet guarantees the machine is awake, nothing stops the handful of commands that destroy things, and the scheduled trigger has never fired once. This page is the finish line rather than an argument for a verdict — five gates, what each costs, who has to do it, and the check you can run yourself to see whether it has been met.
Not yet. The blocker that dwarfs the others is the host: this laptop suspends when the lid closes, and today it was shut for eleven hours and fifty-three minutes. In that window the machine was conscious for about four minutes in total, no agent did any work for nine hours, the five-minute background watcher ran thirteen times instead of a hundred and forty-two — and every time it did run, it could not reach GitHub, while still writing a line that read like a healthy sweep. A scheduled run at 3am on this machine would not fail loudly. It would get a few seconds of processor, die on its first network call, and leave a log that looks fine.
You have already named the fix yourself: a machine that does not travel and does not sleep. Until that exists, the rest of the work is worth doing but cannot be proven, because every detector we would build to watch an overnight run lives on the same machine that goes to sleep.
Three pages went up across two days circling one question, and you closed all three today: "D14/15/16 all seem like a mess to me. Close them all. Do a single assessment of readiness to move to a schedule and let me know when it's ready." You were right, and the mess is ours rather than any confusion of yours.
This page does not restate yesterday's verdict. It re-derives the answer from live state, because a great deal changed inside a day — including the thing that turns out to matter most, which no earlier page mentioned at all.
You were travelling today and the laptop was shut. That is not an anecdote about a lost day; it is the most informative test this program has run, because it is exactly the condition an unattended overnight session would meet.
| What was observed | Measured | What it means for a scheduled run |
|---|---|---|
| The lid closed and the machine suspended | 09:34 to 21:27, eleven hours fifty-three minutes; the only full wake in the window was the lid opening | Sleep is not an edge case here. The power settings already disable idle sleep on both battery and mains — closing the lid is the one thing that still suspends this machine, and it does so on mains too. |
| The machine flickered awake for background maintenance | 61 dark wakes, two to eleven seconds each, 242 seconds in total — about half of one percent of the window | An overnight run would get roughly four minutes of scattered processor across a night, in fragments too short to finish anything. |
| Agents stopped, but not cleanly | Two workers went silent while their status still read working, quiet for twelve and a half and thirteen hours; one died on a name-resolution error inside a six-second maintenance wake; none of the three wrote a closing line | This is the failure shape that matters most to you: not a crash, but a run that looks alive and is not. Nothing detected any of them. |
| Work in progress was nearly lost | 2,127 lines of uncommitted work had to be salvaged off disk from the worker that died | This is why the commit-early rule now exists. It is a real mitigation and it survives sleep, because it needs no detector. |
| The five-minute watcher kept its schedule on paper only | 13 runs where 142 were due; two gaps of about five and a half hours; 43 recorded failures to reach GitHub | Missed runs on this scheduler are lost, not deferred — nothing replayed when the machine woke. A watchdog hosted here cannot promise a 7am check. |
| The one sweep that did complete reported success | Its line read seven repos, two release candidates, workers clean, while every one of its seven repository queries had failed | The house failure mode, in the exact place we would put the alarm. A watcher that reports health from failed calls is worse than no watcher. |
| Yesterday, by contrast, the machine never slept | No sleep event at all on the 15th; across both days, 47 of 59 sessions ended cleanly | The fleet is not the problem. On a machine that stays awake, agents mostly finish. The two days are not comparable, and only one of them resembles an unattended night. |
The brief that commissioned this page put the sleep at 08:28:59. That lid-close was real but lasted about three minutes; the long suspension began at 09:33:59. And the shared session log, whose gap reads as eleven hours, actually spans twelve — the machine's clock moved from Paris to London while it slept, so timestamps written before the wake sit an hour ahead of ones written after.
Neither changes the conclusion, and both are recorded here for the same reason yesterday's page recorded its own retraction: this program's recurring defect is a claim made once, relayed confidently, and acted on. Every figure above was re-run first-hand from the machine's own power log, job records and sweep log, and ten of the load-bearing ones were then given to independent agents told to refute them. Four came back overstated and were rewritten.
The boundary that decides what an unattended run may write is the part that is genuinely finished, and it was probed again today rather than taken on trust.
The worker identifier never reaches the worker's own shell, so the stamping the convention promises is manual, and no commit today carried it automatically. The delivery record names one session as its only writer, so an agent that dies silently leaves no entry unless something notices. Both are known and filed; neither is fatal; neither should be described as enforcement.
Each gate below names the check that settles it. The point is that you can run these yourself and get an answer that does not depend on anyone's account of the work.
You wrote it yourself tonight: "Hopefully moving everything to devoted machine later this week, and then we can really turn on automation." That is the fix. In fairness to the record, that sentence is the only place this plan is written down — no hardware, no date, no power arrangement is recorded anywhere, and the brief that commissioned this page had already firmed your hopefully into a fact, which is the relay error this program keeps making.
pmset -g log | grep -c "Entering Sleep state" returns zero, and the sweep log shows the day's ticks with no gap longer than fifteen minutes.Yesterday's page said "never delete, never force-push" is a sentence rather than a gate. That was true and it is still true, and it is now measured rather than asserted. Fourteen destructive command strings were fed to the guard today: it refused one, the merge, and passed the other thirteen — deleting a repository through the interface, deleting a branch by reference, force-pushing to a main branch, deleting a tag, deleting a release, resetting a checkout hard. A delete call through the web interface is auto-approved with no prompt at all, because every such call is on the allow list and no rule carves out the destructive ones. The account's own token carries the repository-deletion permission.
Two further facts decide the shape of the fix. Four of the seven repositories have no branch protection on their main branch at all — including the hub and the agent harness — and the working branches that agents actually merge into are unprotected everywhere. And the guard script itself sits in a folder no rule stops an agent from editing. A guardrail that lives only on the machine the agent is running on is a guardrail the agent can remove.
None of the three checks yesterday's page called blocking exists today. The sweep that runs every five minutes does four useful things, and none of them is one of the three. The one check that reads the job records ignores, by construction, any job that has not already reached a terminal state — which is precisely the set of jobs that stall or die. All four of today's stuck and dead workers were invisible to it for that reason.
The 7am missing-digest alarm has a further problem worth stating plainly: no digest has been produced by anything since the fourth of August, so the alarm would currently have nothing to look for even once built. And the failure that check was written for is still live — the demo study's pipeline has failed on both of its last two scheduled runs and nobody was told either time.
Nothing anywhere invokes the launcher on a schedule — not the system scheduler, not the user's own timed jobs, not the cloud routines. The autonomy level in the guardrail file still reads, in its own words, scheduled — nightly trigger without a human launch (not yet enabled). No autonomous session of any kind has run since the first of August. The launcher itself is in good shape: its pre-flight ran clean today, eight fail-fast checks including one that mints a live credential.
Three specific weaknesses should be closed in the same pass, because a human at the keyboard has been covering all three. The kill switch is checked when a session launches and never again by anything mechanical — mid-run it depends on the agent choosing to look. The one-session-at-a-time rule is a scan of job files rather than a lock, so a fixed clock can race a session you started by hand minutes earlier. And the level check in the pre-flight warns instead of refusing.
The only limits on an autonomous run today are four hours of wall clock and one increment. There is no token limit and no money limit anywhere in the guardrail file. Until now the ceiling has been you: runs happen when you launch them. A schedule deletes that ceiling and replaces it with nothing.
For scale, the evidence-gathering behind this one page cost about 1.6 million tokens across eighteen agents in seventeen minutes. That was one page, supervised, in daylight.
A page that concludes without naming what would change its mind is an argument, not an assessment. When the gates above are met and someone tells you the lane is ready, these are the observations that would mean it is not:
Every gate above has a check you can run from your own keyboard, and none of them requires you to believe a report. When all five pass — and the rehearsal's digest is sitting in front of you on a morning nobody launched anything — the lane is ready, and not before.
The alternative is to make this laptop ignore its lid for a week — possible, but it needs your hands at an administrator prompt and it means travelling with a machine that never suspends. Everything else on this page can be built while you wait; none of it can be proven on a host that sleeps.
Hosting the watchdog on the same machine as the sessions is simpler and reuses the sweep that already works. It also means the watcher sleeps exactly when the thing it watches does — which is what happened today, along with a healthy-looking line written from seven failed queries.
The local guard is quick and it is where the merge stop already lives. It is also a file in a folder any agent can edit, on a machine every agent runs on. Server-side branch protection is the only stop that survives an agent changing our own tooling — and today four of seven repositories have none at all on their main branch, and no repository protects the working branch agents actually merge into.
Today: four hours and one increment, with no cost limit of any kind. The human throttle disappears the moment a clock does the launching, and one supervised page of research tonight ran to roughly 1.6 million tokens.
This question is carried forward from the closed assessment, where it was never answered. Week one could restrict scheduled runs to the agent harness and the hub, where a bad night costs tooling cleanup rather than chart credibility, widening to the clinical libraries' working branches after one clean week. The published-surface boundary is machine-enforced either way.
Everything on this page was measured tonight from the machine's own records and from live repositories, not carried over from the pages it replaces. The load-bearing claims were then handed to independent agents instructed to refute them; four came back overstated and were rewritten before publication, and two of those corrections are described in the body above rather than quietly applied.
What is not established, and is marked as such rather than assumed: whether a background session can be launched by the system scheduler at all; what the dedicated machine is, when it lands, or whether it will be mains-powered and always on; and whether the two frozen workers could have been revived rather than replaced, which would have required a write this pass did not make.
This decision artifact was drafted by Claude Code using Opus 5, in an unattended worker session (W0013), and reviewed by @jwildfire.