Pi Safe File Rollback
Add opt-in, interruption-safe rollback of Pi workspace files and effective conversation, including Bash changes and recovery of interrupted rollback.
Help me safely undo an interrupted task in Pi
I use Pi for long coding tasks that change files over many model turns. If a task stops unexpectedly, I want to choose an earlier request and get both my files and the conversation back to that point, then continue working. Add an opt-in safe rollback feature with --safe-rollback and the SDK option safeRollback: true. Remember that choice when I reopen the session, require a persistent session, and leave normal behavior unchanged when disabled.
Save a checkpoint before each request starts from idle. Its model turns, retries, steering and queued follow-ups are one unit of work. Cover tracked and non-ignored untracked regular files under the workspace root, including contents, permissions, creation, deletion and renaming through edit, write and bash. Bash changes still count if the command fails, is cancelled or is killed halfway through. Keep my earlier uncommitted work and Git HEAD, branches and index intact.
When I reopen an interrupted session, keep the unfinished work in place and let me inspect and choose a checkpoint. Until recovery is resolved, block new model requests, file-changing operations and conversation changes, including navigation, forking and compaction. If rollback itself is interrupted, reopening must finish the same rollback automatically before normal execution resumes. Files need not change simultaneously, but the model must never continue with half-restored files or conversation. Filesystem errors should be visible, and recovery should remain inspectable and retryable after I fix them.
Restore both files and the effective conversation to the chosen checkpoint. Subsequent model requests must exclude the discarded work, including after another restart. Let me roll back to checkpoints on the current session's ancestor path and continue on a new branch without mixing in abandoned work. Repeating a completed rollback should be harmless. Reject invalid or foreign checkpoints and rollback while a request is still running.
I also edit files while Pi is idle, sometimes between requests. Preserve unrelated edits and files. If going back would discard my manual changes, refuse the whole rollback, tell me which paths conflict, and leave both files and conversation unchanged. Assume a local Linux Git workspace with no other writers during a request or through its downtime and initial recovery, and that the whole execution unit, including Bash children, has stopped before recovery. File names are arbitrary Linux names: backslashes, spaces, newlines and names such as __proto__ or constructor are ordinary parts of a name. Power loss, disk damage, links, special files (devices, sockets, FIFOs), ignored untracked files and external effects are out of scope. Commands do not change Git metadata, ignore rules or recovery settings, or leave independent background services.
I need this in interactive Pi and in integrations. Provide /rollback to list checkpoints and /rollback <id> to restore one, plus SDK methods on AgentSession: listCheckpoints(), getRollbackState() and rollbackCheckpoint(checkpointId). Lists contain records with stable, session-specific id values; their order and other fields are up to you. Historical checkpoints may remain listed; listing an ID does not make it an eligible rollback target. State reports enabled and a status of ready, interrupted, restoring or blocked. Add matching list_checkpoints, get_rollback_state and rollback_checkpoint RPC commands using the existing response envelope, with checkpointId as the rollback input and { checkpoints: [...] } as the list result. Other response fields are your choice.
Implement this in production code, add tests and document how to use it. Preserve ordinary tool output, Bash exit/cancellation behavior and unrelated functionality. Use the installed dependencies without changing dependency manifests or lockfiles, generated model data or build/test configuration, or weakening existing regression tests.