You wake up to stalls and repeats.
You want your coding sessions to keep working while you sleep. You come back in the morning and one stopped at step two waiting for you, one redid yesterday's work, and one wrote something you now have to untangle.
A session stops when its turn ends.
A session works while it has a turn, then it stops. Nothing wakes it. A long run fills its context and older detail gets compressed away, plan included.
Anything that needs your permission waits until you're back. And a fresh session started by a timer begins with no memory of the one before.
What doesn't work.
One giant “do everything” prompt. The plan is the first thing lost when the context fills up.
Approving everything automatically. It removes the stall and also removes the one check you had.
A timer that relaunches the same prompt. Each run starts blank and repeats the run before it.
What actually helps.
Most of this isn't us.
Wake on a schedule. Claude Code's /loop command re-runs a prompt on an interval while the session stays open; closing the terminal stops it. For work that has to survive that, its docs point to cloud routines, desktop scheduled tasks or GitHub Actions.
Keep a task list and a status file in the repo. Each wake reads them first and updates them last.
Narrow permissions to what the overnight tasks need, instead of approving everything.
Make tasks small enough to finish in one wake.
Fifteen sessions, one list of work outside all of them.
We run about fifteen sessions this way. Each one wakes on a schedule and reads its orders from a shared record, not from its own memory.
Overnight on 14 October every session was given a named job before the operator went to bed, so a wake always found work waiting. The standing rule behind it is that the sessions should keep pulling the next item on their own.
| What was measured | What the record says |
|---|---|
| sessions waking on a schedule | about 15 |
| where each wake reads its work | a shared record of orders, outside any one session |
| the operator's standing rule | “They should essentially never stop.” |
| recorded | 13 and 14 October 2026 |
| where it's from | Vinculum's own project record, which runs on Vinculum; scheduling details checked against Claude Code's documentation on 14 October 2026 |
Where a shared memory fits.
In Vinculum the orders and the list of work live outside any one session, so whatever wakes up can read them.
It doesn't invent the work. If the list is empty, the loop wakes up to nothing.
Common questions.
Does /loop keep running after I close the terminal?
No. It runs while the session stays open. For schedules that have to survive a closed terminal, Claude Code's docs point to cloud routines, desktop scheduled tasks or GitHub Actions.
Should I turn on auto-approve for overnight runs?
Narrow the permissions to what the tasks need instead. Approving everything removes the stall and the safety check at the same time.