What survives a restart

What is on disk when a process dies, what is only in memory, and what starts the run again. Closing the editor, a crash, a sleeping machine and a reboot are different cases.

Who keeps running #

The daemon is detached from the terminal and the editor that started it, so closing either does not stop it. A supervisor process starts the daemon, and starts it again when it exits with the run still active, which is what a crash looks like.

The supervisor does not restart a daemon after a stop, a pause, or a run that ended as idle, error or completed. It gives up after more than 5 restarts within 5 minutes. It then writes supervisor.giveup to the log and sets the status to error. On Windows, the supervisor also asks the operating system not to sleep while the run is active, so a wait for a usage limit to reset does not sleep through it.

A machine that goes to sleep on its own freezes these processes rather than ending them, and the run carries on when the machine wakes. A shutdown or a reboot ends them, and the section on reboots covers what starts the run again.

When a run ends #

When the loop returns, the daemon exits, and it does not wait for anything a participant started from a turn and left running, such as a development server. Its supervisor sees the exit and does what a finished run needs: it releases the keep-awake request, closes the browser the run kept open for its browser tools, and decides whether the machine may suspend.

That last step is optional. With suspendOnCompletion on, AutoDev puts the machine to sleep once the run is over or halted on you, if nothing else needs it. It is off by default, and Suspending the machine lists the conditions.

What survives #

Item	After a restart	Why
The objective, memory, participants and config	Kept	They are files in `.autodev/`.
The thread and each participant's cursor	Kept	`thread.jsonl` and `cursors.json` are on disk. The next turn is told what is new to it.
A message you sent that nobody has read yet	Kept	`inbox.json` holds it until the daemon drains it.
The status, and a pending gate, proposal or question for you	Kept	`state.json` holds them. A run that is `gated`, `proposed` or `awaiting_user` is not relaunched, because the decision is yours.
The notices participants left you	Kept	`notices.json` holds them with their answers and holds.
The clock of a wait, the count of audit rejections and the run of talk turns	Kept	They are in `state.json`, so a crash does not reset the bound.
Spend	Kept	`state.json` holds the running total.
Each participant's session	Kept	`sessions.json` holds the session id, so a turn can resume the same conversation. A session belongs to the provider that made it, so a participant that moved to another provider starts a new one.
Checkpoints	Kept	They are git commits, and `checkpoints.json` lists them.
The quota ledger	Kept	`quota.jsonl` never rotates.
The runtime budget	Starts over	It is measured from the start of each daemon run.
Which provider is limited or unreachable	Lost	The record is in memory, and a restart probes again.
A turn that was running	Lost	See below.

thread.jsonl, state.json, sessions.json and the rest of the machine's files are in ~/.autodev/<project>-<hash>/, and goal.md, memory.md, participants/ and config.json are in .autodev/. Where state lives lists both.

A turn that was running #

A participant that dies before it posts leaves nothing on the thread, because a post is the only thing that reaches it. Its cursor has not moved, so its next turn is shown the same posts again.

Files the turn had already written stay in the working tree. When the daemon starts again, the baseline checkpoint commits changes that are not committed as autodev: baseline before run, unless checkpoints are off or the folder is not a git repository. AutoDev does not resume a turn in the middle. It starts a new one.

After a reboot #

Nothing starts by itself after a reboot. AutoDev does not register itself to start at boot, so the run stays stopped until something starts it. state.json still says the run is active, and its pid belongs to nothing, so autodev status and the panel show it as stopped.

These start it again:

autodev with no command, run in the project. It relaunches a run whose status was running, planning or waiting, and one that is rate_limited, which then sleeps until the limit resets. It does not relaunch a run in any other status. If a server was running detached with autodev serve --daemon, it starts that again too.
autodev start, which starts the daemon whatever the status was, or says that one is already running. A pause request left over is cleared, since starting is an intent to continue. autodev resume alone only records the request, and does not launch a daemon.
A message sent from the panel or with autodev send, when no daemon is alive and the team is set up and confirmed on this machine. The run starts to read it.
Approve, on a gate that was waiting. It records the approval and starts the run.

The panel does not relaunch a run when it opens. For a run that stopped on its own it says the run is paused and will not resume on its own — send a message to resume.

How a dead run is noticed #

AutoDev does not trust the status field on its own. It checks that the pid in state.json is alive, and that the process is an AutoDev process for this project. A pid that a reboot handed to another program counts as dead. A check that cannot answer counts as alive, so that AutoDev never starts a second daemon under a live one.

When the pid is dead and the status is still an active one, AutoDev clears the pid and keeps the status and the current task, which is what lets the run be relaunched where it was.

The memory file #

Every run starts with a memory.md. When a run starts, AutoDev creates an empty one if there is none, so a run started from the panel has a file for its first participant to read as well. Each participant is told where it is, to read it first when its context is compacted, and to write to it with the remember, revise and forget tools: decisions and why, constraints, dead ends, and anything a later turn would pay to learn again.

That is why a run survives a restart in the way that matters: a new session has the thread and memory.md, and does not need the conversation that produced them. A restore does not rewind the file, and autodev new-run copies it into the archive before it empties it. autodev memory prints it. Where state lives describes the file.

Checkpoints and restore covers the rewind, and The run stopped and why covers reading a stopped run. Every CLI command describes autodev start and bare autodev.