Resume, Replay, and Fork a Run
Understand the differences between resuming, replaying, and forking AI agent runs within the Wren harness. Learn how to handle incomplete sessions, rebuild provider context, and ensure reliable event management across multiple runs. This lesson helps you design controls for session lineage, preventing repeated side effects and maintaining evidence through durable journals.
We'll cover the following...
- What are we building in this lesson?
- What is the difference between resume, replay, and fork?
- When is a journal safe to resume?
- How does Wren rebuild provider context from events?
- Why does replay need a separate path?
- How do Pi and DeepSeek Harness draw this boundary?
- What does a fork preserve?
- How do the terminal controls preserve lineage?
- How do you test a history feature without repeating history?
- Can you map saved events to the next safe action?
- What can you add to your own harness today?
- Try it yourself
- What’s next?
Wren stopped during CLIN-547 after it called edit with mode: "apply". The terminal window closed before the tool receipt appeared.
The operator had three available actions: rerun the task, retrieve the previous transcript, or continue from the last recorded state. These actions represent three distinct operations. Treating all three as a single resume operation can apply the same file mutation more than once, obscure the absence of an execution receipt, or overwrite the original execution record without making that change explicit.
This is a Carry failure across process boundaries. Wren has a journal, but a new process needs rules for using it. This lesson separates three actions: continue from settled history, look at old evidence, or create a new branch.
What are we building in this lesson?
Use a saved video as the mental model:
Replay watches the recording. Nothing in the scene happens again.
Resume starts new work after the last safe frame.
Fork copies the recording up to a safe frame and starts a different continuation.
The safe frame is the part that matters. If the video ends with Wren asking a tool to edit a file but never recording the result, the new process cannot know what the disk contains. It must inspect the state instead of pressing the old button again.
What is the difference between resume, replay, and fork?
Take a look at the following table:
Operation | Reads | Calls Provider or Tools? | Writes | Use It When |
Resume | Current journal | On the next task only | Appends to current journal | The session has no unresolved tool calls. |
Replay | Current journal | No | Nothing | You need to inspect what happened. |
Fork | Current journal | No | New child journal | The next task might diverge from the parent. |
None of these actions reruns an old call. Replay renders saved events. Resume rebuilds messages for a future provider call. Fork copies settled evidence into a child journal and records its parent. The old journal stays unchanged.
Choose a settled or unresolved journal below, then try resume, replay, and fork. Replay remains read-only in both states. Resume and fork block when the last tool call has no result.
The unresolved example is the important one. Wren cannot know whether the edit happened. Rendering the saved events is safe, but creating new work from uncertain state is not.
The provider can still make a new call after a resume or fork. That is new work with a new receipt. It is never a disguised attempt to recreate an old side effect.
When is a journal safe to resume?
Wren does not require the last run to succeed. A cancelled or blocked run may still contain safe evidence. It requires one narrower fact: every started tool call has a result.
A call event means Wren asked the executor to act. If its matching result is missing, the process may have stopped during the operation. The edit ...