The documented runtime claim
Meta says Muse Code uses a local event log. Every model call, tool run, approval, and edit is appended to that log, which becomes a single source of truth for the runtime. Meta describes the result as replay-exact and restart-safe: after a crash, the agent can resume precisely where it stopped.
- 01Task startscontext
- 02Actions appendcalls · tools · approvals · edits
- 03Interruptionruntime stops
- 04Resumereplay-exact state
- 05Continuework proceeds
- Model calls
- Appended Current Meta statement
- Tool runs
- Appended Current Meta statement
- Approvals + edits
- Appended Current Meta statement
- After a crash
- Resume Restart-safe design
Why this matters for long tasks
A long repository task may span many model responses, shell commands, approvals, and file edits. If runtime state existed only in memory, a process failure could force the agent to reconstruct context or repeat work. An append-only history gives the runtime a durable sequence from which to recover.
This also supports auditability at the product level: an action history is more inspectable than a final patch with no record of the path taken. It does not remove the need to review the actual diff, test results, and approvals.
Recovery is not correctness
Resuming at the right point means the runtime can continue; it does not prove the previous decisions were correct. After an interruption:
- Inspect the restored task state and recent actions.
- Reconfirm any approval that could have changed external state.
- Check the working tree and active processes.
- Re-run the narrow verification for the last completed change.
- Continue only when the repository and runtime agree.
For safe first checks when a beta task or installer behaves unexpectedly, use troubleshooting. For the background workers whose actions can appear in the task history, see subagents.