OpenClaw Main Fixes P0 Worktree Cleanup Data Loss
Registered Git worktrees placed directly under OpenClaw's worktrees root could be recursively cleaned as orphans; a landed fix now preserves registered checkout roots.
OpenClaw has merged a P0 correction for an orphan-cleanup path that could recursively delete child directories from a valid Git worktree when that checkout was placed directly under OpenClaw’s managed worktrees state root.
PR #119709 changes reconciliation to identify registered checkout roots before descending into candidates. It also covers registered unborn worktrees and canonical path aliases such as a symlinked state root. The landed implementation fails closed when it cannot inspect checkout metadata.
The fix is on main. The reviewed sources do not identify the first packaged version that contains it.
Who should act now
Prioritise this if agents or automation create, register or reuse Git worktrees anywhere under OpenClaw’s configured worktrees root—especially when a checkout sits immediately below that root instead of inside OpenClaw’s expected fingerprint directory structure.
The dangerous shape is a valid checkout being mistaken for an orphan container. Once reconciliation treats that directory as disposable structure, recursive cleanup can reach repository content that Git still considers a registered worktree.
The upstream issue also identifies two less obvious variants:
- an unborn worktree whose branch has no first commit yet; and
- a registered path reached through an alias, including a symlinked state root.
Do not infer safety from the presence of .git alone. The merged repair uses Git’s registered worktree view and canonical paths rather than a shallow marker check.
Safe mitigation before a containing build
- inventory the configured worktrees root and compare its descendants with
git worktree list --porcelainfor every owning repository; - identify any registered checkout placed directly below the root or reached through an alias;
- pause OpenClaw orphan reconciliation for the affected environment until a containing build is staged;
- preserve repository remotes, refs, uncommitted changes and any generated artifacts outside the cleanup boundary; and
- test the upgrade against disposable worktrees representing direct-root, nested, unborn and symlinked layouts.
Do not manually move or delete a live worktree to “fix” its layout. Git worktree registration, locks and repository metadata need to remain consistent. Use supported Git operations against a backup or disposable clone.
If cleanup may already have run, preserve what remains before invoking more garbage collection. Reconcile the owning repository’s registered worktrees, filesystem contents and external backups. A clean Git status in another checkout does not prove untracked files or uncommitted work survived in the removed path.
What the repaired boundary does
The new sequence classifies top-level and nested candidates through Git worktree registration before recursive deletion. Registered roots are retained; genuine debris can still be removed. When metadata inspection fails, the candidate is preserved instead of guessed disposable.
Interpretation: this is the correct bias for destructive maintenance. Leaking an orphan directory costs storage; misclassifying a checkout costs work.
Acceptance should prove both sides:
| Fixture | Required outcome |
|---|---|
| Registered worktree directly under the state root | Checkout and child directories remain |
| Registered nested worktree | Checkout remains |
| Registered unborn worktree | Checkout remains |
| State root reached through a symlink | Canonical registered checkout remains |
| Ordinary unregistered debris | Cleanup still removes only the intended debris |
| Git metadata inspection fails | Cleanup fails closed and records the problem |
Use synthetic repositories with unique sentinel files. Never validate a deletion fix against the only copy of real work.
Live backup failures are fixed separately
PR #119782 fixes openclaw backup create --verify failing while the Gateway is active because disposable SQLite coordination databases remain locked. The backup filter now omits transient Gateway and device-coordinator lock databases while retaining durable SQLite state.
That is useful mitigation, but it does not make a backup automatically complete or restorable. On a containing build, require the command to verify while the Gateway runs, inspect the manifest to confirm durable stores are present, and perform a restore drill into an isolated state directory. Do not copy locked SQLite files by hand.
Evidence and limits
The official issue, merged PR and landed commit establish the affected layouts, destructive cleanup boundary and source-level repair. The backup PR establishes the separate locked-database failure and volatile-file exclusion. OpenClaw Academy did not run orphan cleanup or restore a production backup.
Collector IDs 40444 and 40412 identify the worktree fix. IDs 40524 and 40481 identify the live-backup fix.
Bottom line
A registered checkout must never be treated as orphan debris. Audit worktrees under OpenClaw’s state root now, stop affected cleanup on builds without commit 1e347e2, and accept the fix only after registered layouts survive while genuine debris is still removed.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF