What survives a restart, and what a restart ends

September 18, 2026 · Architecture · Operations · 5 min read

Long-running work fails in a specific way when the process holding it ends. The useful question about any agent tool is not whether it can resume, but what the resumption actually restores.

What a task keeps

An active ClearFrame task retains its goal across application restarts. Reopening the app presents the task with the objective it was working toward, not a blank prompt and a request to restate it. The development loop is described in the product as persistent goals, isolated changes, and a way back — three properties that are only useful together: a goal that persists is worth little if the changes it produced cannot be reviewed, and a review is worth little without a way to reverse it.

What resumption restores

A task resumes from its saved checkpoint. The distinction matters: the checkpoint records file state, and the task record holds the goal and its history. What is restored is therefore a known file state plus the intent that produced it.

What is not restored is the work in flight at the moment the process stopped. An operation that was executing when the app closed did not complete and did not roll back; it simply stopped. The task resumes and continues from the checkpoint, which is the correct behaviour and a different promise from "nothing is ever lost".

Steering a running task

A task exposes three controls beyond simply letting it run: pause, resume, and give direction. The third is the one that changes how the tool is used. A task that has gone slightly wrong does not have to be cancelled and restarted; it can be told what to do differently and continue from where it is.

Cancellation is available as its own action, and it is a different decision from pausing. Pausing preserves the task to be continued; cancelling ends it. Presenting them as separate controls is what allows a reader to make the smaller decision.

The boundary this creates

The honest statement of the model is that a task survives a restart with its goal and a recoverable file state, and does not survive with the operation that was running. That is a narrower claim than durability, and it is the one the mechanism supports.

The limit is worth naming beside the capability because the alternative reading is so attractive. "Persistent" invites the conclusion that a task continues through anything. What it means here is that the task is not lost.

Why this shape rather than a durable queue

A durable job queue would keep the in-flight operation and replay it on restart. For file-modifying work that is worse, not better: a replayed operation may run against a project that has changed since, and an operation that had already made partial progress would be applied twice. Resuming from a checkpoint and continuing is the conservative choice, because the starting state is known rather than assumed.

The review surface is part of the persistence

A goal that survives without its changes would be a task that remembers what it was doing and cannot show what it did. The two are kept together: the isolated workspace holds the task's changes, and the review panel presents them against the checkpoint the task resumed from.

That is why the checkpoint and the goal are described as one mechanism rather than two features. Resuming a task means restoring the file state the task expects to continue from, which is the same machinery the recovery layer uses when a change needs to be reversed by hand.

Stated limits

• In-flight work does not survive. The operation running when the process stops is not completed and not replayed.
• Resumption is from a checkpoint. You return to a saved file state, not to the exact instruction that was executing.
• Remote runs have their own bound. Where remote execution is enabled, runs use a separate workspace and last up to two hours.
• Cancellation is separate from pausing. One ends the task, the other preserves it.

What the controls are for

Pause exists because a task sometimes needs a decision that only a person can make, and cancelling to get one throws away the work already done. Give direction exists for the same reason at a smaller scale: a task that has misunderstood one constraint can be told so and continue, instead of being restarted from the goal.

Both are only useful because the task holds its goal and its checkpoint. A control that resumed a task without either would be a way to start a slightly different task, which is what a prompt already does. The persistence is what makes steering mean something.

Related reading

The task workflow in the documentation, file recovery for what the checkpoint covers, and bounding what an unattended task may spend.