24. Upgrade, backup and sync

24.1 Upgrade

In-app upgrade (recommended): tray menu → check for updates → one-click replace. Packages are signature-verified; a failed verification auto-rollbacks.
Manual upgrade: download the new build from the official page and replace-and-run it (install-free); the config directory is untouched.
Upgrade staging is tidier: the upgrade's temporary installer is placed in a hidden cache directory, no longer leaving intermediate files lying around in visible folders; orphan staging files from a failed / interrupted upgrade are auto-cleaned, no manual cleanup needed.
The upgrade dialog's "Release notes" come straight from RELEASE_NOTES.md (no longer from the git log), showing only user-facing notes without leaking commit metadata.
Component security updates ship with releases: third-party dependencies (e.g. Go's x/crypto / x/net, the MCP SDK) are bumped over time to pick up security fixes.

24.1.1 Config directory migrates to avlcode (automatic)

The internal identifier migrates from zcode to avlcode: the global config directory (e.g. ~/.config/avlcode/), the in-workspace .avlcode directory, AVLCODE_… environment variables, and the related YAML / frontmatter fields all switch to avlcode naming (SSH remote workspaces too).

Automatic and safe: it migrates on startup and on opening a workspace, with a toast, without affecting existing data.
Old names kept for dual-read fallback: during migration the old zcode / .zcode / ZCODE_… are still readable, so old configs don't suddenly break.
Any residual "zCode" in the UI or external output is unified to "AVL Code".
You normally need to do nothing; if you've hard-coded .zcode/ paths or ZCODE_… variables in scripts, switch them to .avlcode/ / AVLCODE_….

24.2 Backup v2 — encrypted `.zbk`

Settings → Data hosts three dialogs: Create Backup / Restore / Snapshot History.

.zbk encrypted backup file (AES-GCM) covering 14 categories of application data (including plugins/ / ~/.avlcode/trust/ / optional hook-outputs/).
Create: pick categories → enter password → save the .zbk. plugins / trust are checked by default (so cross-machine migration doesn't need a re-install); hook-outputs is unchecked by default (only included on demand for debug history).
Restore: pick a .zbk → enter password → preview the categories → confirm.

Old and new backups are bidirectionally compatible; the .zbk format version doesn't change.

24.3 Snapshot history (automatic)

Every "destructive operation" (single-category clean / batch clean / full reset) writes a pre-clean snapshot first (named like auto-clean-<ts> or auto-fullreset-<ts>).

Snapshot history supports deep-linking — jump straight to the matching snapshot row from a destructive operation's success toast.
Each row has a Rollback button — near-zero footprint to back out.

24.4 Storage usage and per-category cleanup

Settings → Data → Storage Usage shows real disk usage by 14 backup categories + 6 non-backup items (cache / snapshots / metadata). The roll-up matches du to the byte:

Single-item / batch cleanup — categories with sensitive data (plugins / providers / trust etc.) write an auto-clean-<ts> snapshot before the action for one-click rollback.
"Full reset" deeply wipes all 14 categories + restores default config + writes an auto-fullreset-<ts> snapshot.

The workspace menu's "Clear data" entry gains a new dangerous option: "Clear all workspace files" — beyond AVL Code's own metadata (sessions, todos, settings, etc.), it actually wipes every file in the workspace directory. Like other destructive buttons, it uses the inline countdown + arm-then-confirm flow; irreversible — only use on temporary / rebuildable workspaces.

24.5 Inline countdown on destructive actions

All destructive buttons no longer pop a native confirm dialog; instead they use a GitHub-style "arm → countdown → confirm":

First click — the button turns red and shows a 3-second (5 for full-reset) countdown.
Second click — actually runs.

Only one button can be armed at any time globally (clicking another disarms the previous); clicking elsewhere or Esc cancels. Success feedback appears in place — ✓ Freed N · Undo · Close — instead of a global toast.

Settings deletions are uniformly inline-confirmed: delete buttons for skills / plugins / accounts / providers / routines etc. in the Settings panel all use in-place inline secondary confirmation. Fixes the root cause of "clicked Delete and nothing happened" — the native confirm dialog was silently swallowed by the embedded WebView and treated as Cancel. Now clicks give feedback and deletions go through.

24.6 Sync (experimental)

AVL Code offers cloud-based sync (experimental): enable in Settings → Data → Sync and signed-in devices auto-sync workspaces and sessions. Sync happens only between devices of your signed-in account.

24.7 Data redaction

Settings → Redaction is an outbound-scope data-protection engine — it automatically replaces / masks sensitive fields before content leaves the local machine. Off by default (opt-in); config lands at ~/.config/avlcode/redaction.yaml; the main process and child processes share the same compiled ruleset.

Scope toggles (each independent):

Scope	Default	When applied
`export_html`	On (once master enabled)	Exporting a session to HTML
`export_session`	On (once master enabled)	Exporting `.zsession`
`write_md`	Off	When the AI writes `.md` and similar document files to disk (Phase 2; use with caution — can alter what gets written)

Rule types:

Type	Notes
`keyword`	Literal-string substitution; `Pattern` is auto-escaped, `Replacement` is treated as a literal
`regex`	RE2; `Replacement` supports `$1` / `${name}` capture templates — useful for partial masking
`ipv4_mask`	Structured IPv4 masking — `Octets` (1-based, 1..4, any segment including the middle), or legacy `Segments` (mask first N segments); `MaskChar` defaults to `*`
`domain_mask`	Domain masking — `KeepLast` keeps N trailing labels (default 1, TLD only); the rest become `MaskChar`

Built-in secrets preset (presets.secrets, optional) — high-confidence, low-false-positive credential formats:

AWS Access Key (AKIA…)
GitHub PAT (ghp_…) / other tokens (gho_… / ghs_… / ghu_…)
Slack token (xox[baprs]-…)
Stripe live key (sk_live_…)
GCP API key (AIza…)
OpenAI key (sk-…)
Whole PEM private-key blocks (-----BEGIN … PRIVATE KEY----- through -----END …, multi-line)

Hit feedback: every redacting export / write pops a toast telling you how many hits and which rules — auditable; each substitution carries the rule's Label, so nothing slips through unnoticed.

Export redaction now covers line-start IPs in code blocks and nested JSON: session-export redaction applies rules to the decoded JSON text values, fixing a case where a line-start IP inside a code block (affected by JSON escaping) was left unmasked; it also recurses into nested JSON, covering sensitive data in tool-call arguments and results, so deep fields aren't missed.

When the master switch is off, every scope passes content through untouched — so you don't get the "things are missing and I don't know what" surprise after enabling. Recommended flow: write rules into redaction.yaml first, do a small export to verify, then turn it on for real data.