Resume & Replay
When a run fails or you want to redo part of it, Gump offers two recovery modes with different trade-offs.Resume
Continue where you left off. The worktree stays as-is, sessions are preserved.session: reuse is configured.
To resume a specific run:
Replay
Start fresh from a specific step. The worktree is reset to the state before that step.Differences
| Aspect | Resume | Replay |
|---|---|---|
| Worktree | As-is (diff from last attempt in place) | Reset to pre-step commit |
| State bag | Reloaded, all outputs preserved | Reloaded, target step’s outputs cleared |
| Agent sessions | Preserved (resume possible) | Lost (fresh session) |
| Retry counters | Reset | Reset |
| Use case | Continue after a crash | Clean re-execution from a known state |
Limitations
Both resume and replay restore the code and the state bag. They do not restore:- Dependencies (if
go.sumorpackage-lock.jsonchanged externally) - Runtime versions (Go, Node, Rust updates between runs)
- External state (databases, APIs, services)
- Agent sessions (for replay — they’re lost because the worktree is reset)
When to use which
The run crashed mid-step →--resume. The worktree has the partial work. The agent can continue.
A gate keeps failing and you changed the prompt → --replay --from-step. Start the step fresh with the new prompt.
You want to re-run with a different agent → --replay --from-step. The worktree resets and the new agent starts clean.
The plan was bad and you want to start over → just run gump run again. A new run creates a new worktree from scratch.