Changes and rollback

There is no direct-overwrite option. Every write starts life as a plan.

The lifecycle of one change

1. Generate a plan

Each row lists an operation type and a target path:

• create — new file or directory
• update — overwrite (with diff)
• delete — remove
• link — create a link
• warn — not recommended, but not blocked

You can apply a subset; unchecked rows are simply dropped.

2. Apply

Writes are atomic: a temp file is written first, then renamed, so a failure never leaves a half-written file behind.

Original content goes into a backup batch whose id looks like cs-20261102-7f3a.

3. Roll back

Every batch in the change history can be rolled back whole or row by row:

• overwrites are restored from the backup
• deletions are restored from the backup
• links are rebuilt toward their original targets, never left dangling

When execution is refused

• the target falls inside a read-only zone
• the target path matches the exclusion list
• the file changed externally after the plan was generated (content fingerprint mismatch)

The third is the common one: an external tool edited the same file while you were reviewing. AgentHub refuses rather than writing over it, and asks you to regenerate the plan.

External edits

The desktop app watches agent directories, the canonical store and your config. When something changes outside the app it notices and tells you — it does not rescan automatically, so a background refresh never interrupts what you are doing.

A batch pill lives in the status bar: “Plan · N operations · not applied” while a plan exists, otherwise the most recent batch. Click it to jump to the change history with that batch highlighted.