History and recovery

Cheqq has two connected recovery systems:

• Chat checkpoints protect a conversation before Cheqq acts on a user message.
• Artifact history versions the Wapp or workflow itself whenever a supported change is committed.

Use chat checkpoints when you want to revisit the intent and conversation. Use artifact history when you want to inspect or change the current state of a Wapp or workflow without changing its chat.

Chat checkpoints

Every accepted message in Ask, Plan, and Agent mode creates a checkpoint before the turn begins. The checkpoint actions appear immediately above that user message.

Restore a conversation

Select Restore to return the current conversation and captured local state to the point immediately before that message. Cheqq first preserves the abandoned future as a read-only Before restore branch, so the later conversation is not your only copy.

The confirmation lists the local artifacts Cheqq can restore, any partial captures, and external effects that will remain. A restore can include manual local edits made after the checkpoint; it returns the artifact to the captured point rather than undoing only Cheqq's individual tool calls.

After a successful restore, Undo restore appears beneath the recovered conversation. Use it to return to the preserved future. It is available only for the latest applicable restore and disappears after it is used or the conversation moves forward.

Fork a conversation

Select Fork to create an independent conversation containing the history that came before the checkpoint. The message above which the checkpoint appears and all later turns are excluded.

• Main chat creates a conversation-only branch.
• Wapp, workflow, and App surfaces also duplicate their primary artifact when required, subject to normal plan limits.
• Forked workflows start inactive, and forked Apps are private and unpublished.

The new thread records its parent and checkpoint, appears in recent conversations, and opens at the appropriate surface.

Partial checkpoints and external effects

A turn can continue when Cheqq cannot capture every supported local subject. The checkpoint is marked Partial and its warning explains what may not be recoverable. If the primary capture is unavailable, artifact Restore is disabled, but conversation Fork may still be available.

External effects are never presented as reversible. Restoring a checkpoint does not unsend email, retract a published message, reverse a payment, cancel a completed workflow run, or undo another action already completed in an external service. Cheqq records a sanitized summary of known effects and shows it before the restore.

Restore and Fork are temporarily unavailable while that thread has an active stream, approval, browser handoff, or queued-message transition.

Wapp and workflow history

Artifact history is a single collaborative timeline. It records committed changes from people, agent tools, autosave batches, imports, chat restores, and other supported sources. An entry identifies what changed, who caused it, and when it expires.

Undo and Redo

Undo moves the shared artifact to the parent of its current entry. Redo restores the next entry on the active redo path. Because history is collaborative, Undo targets the latest committed change regardless of who made it.

A new committed change after Undo clears the active Redo path. The abandoned entries remain available for browsing until their retention expires.

Use Cmd/Ctrl+Z and Cmd/Ctrl+Shift+Z outside text fields. When focus is in an input, textarea, or editable text area, the browser's native text undo takes priority.

Compare and restore

Select two retained entries to compare their authoring state. Wapp comparisons include structural changes and semantic record differences such as added, deleted, restored, or updated records and changed fields. Workflow comparisons cover the workflow definition, layout, editable settings, and trigger configuration.

Restoring an older entry creates a new, undoable history entry based on that state. Existing history is not rewritten or deleted.

Retention and named snapshots

Ordinary history is retained according to the workspace plan:

All users can browse, compare, restore, Undo, and Redo within retained history. Only paid workspaces can name a history entry as a snapshot. A named snapshot is pinned until its name is deleted; naming does not duplicate the underlying state.

If a workspace moves to Free, snapshot names and pins are removed. Their entries return to ordinary seven-day retention based on the original creation date.

Trash

Current Trash support covers:

• Wapps (from the Trash drawer on the Wapps page);
• workflows;
• Wapp collections; and
• Wapp records.

Trash retention is stamped when the item is deleted: 7 days on Free and 30 days on paid plans. Restoring a workflow keeps it inactive unless you explicitly choose to resume automation. Restoring a Wapp brings back its installs, its workflows, and its links to shared workflows — the workflows return paused, and the restore reports any references that broke while it sat in Trash. A Wapp's collections and records are never touched by deleting the Wapp, so restoring it makes that data reachable again with nothing to reconstruct. Permanently deleting a Trash item removes that recoverable copy but does not rewrite retained history versions.

What each artifact captures

Wapps

Wapp history covers install settings, collections, fields, schemas, views, layouts, dashboards, Wapp-owned skills and instructions, workflow attachment references, records, relations, and attachment references. Restore reconstructs records at the selected point in time.

It does not restore credentials, irreversible external actions, or standalone workflow definitions. Wapp history restores only the links to those workflows.

Workflows

Workflow history covers the authoring definition, nodes, edges, layout, editable settings, triggers, and trigger configuration. Pending autosave work is committed before Undo or Redo.

Restore does not reverse workflow runs, logs, or execution history. It preserves the current workflow and trigger active state where possible; a trigger reintroduced from older history starts inactive.

For recovery errors and warnings, see Troubleshooting.