OpenClaw merged PR #167695, a managed-worktree performance and recovery change focused on large repositories and partial clones.
The bug was not flashy, but it was expensive. Removing one managed worktree could rebuild the shared repository's entire multi-pack index. On large partial clones, that meant every removal could pay a repository-wide maintenance cost. Snapshot creation could also spend another two minutes implicitly fetching missing objects through inconsistent commit-graph state.
What Changed
OpenClaw now keeps pack repair and consolidation under the background maintenance owner instead of performing that work during each individual removal.
That shift gives removal a cleaner job: preserve the checkout when required objects are missing, keep the existing ownership and timeout rules, and let explicit fetch or repository repair complete the path before retry. Native object validation, pending recovery pins, force and capacity-eviction snapshot-loss policy, and timeout budgets remain intact.
The PR also applies a no-fetch policy to snapshot inventory, ordinary snapshots, and exact-state verification through one operation-owned environment. That matters because implicit Git fetches during snapshotting can turn a local cleanup path into a slow network-dependent operation.
Why Operators Should Care
Managed worktrees are part of the machinery that makes agent workspaces practical. They let OpenClaw prepare, isolate, snapshot, and clean up repository state without treating every task as a brand-new clone.
When cleanup is slow, it can show up as delayed workspace retirement, retained disk pressure, or sluggish recovery after failed or abandoned work. When cleanup tries to repair repository-wide Git structures inline, one local removal can inherit the cost of the entire shared repository.
This change separates those concerns:
- Individual removals no longer rebuild pack indexes.
- Background maintenance owns pack repair and consolidation.
- Snapshot operations avoid implicit object fetches.
- Missing-object cases preserve the checkout for explicit repair and retry.
- No schema migration or operator configuration is required.
That is a practical improvement for installations with large repositories, retained snapshots, or many short-lived managed worktrees.
The Measured Result
The PR reports real ManagedWorktreeService.remove runs on a synthetic partial clone with 4,700 indexed packs, 2,405,376 filler objects, and 20,000 tracked files. Across 30 samples, removal p50 fell from 1,946 ms to 1,372 ms, a 29.5% reduction. Warm-sample empirical p99 dropped from 2,193 ms to 1,647 ms.
The clearest operational number is multi-pack index writes: 30 per-removal MIDX writes before, zero after. After five bounded maintenance passes, both revisions consolidated 4,730 packs down to one, which supports the intended ownership split: maintenance still does the repair work, but removal no longer does it every time.
The PR is also transparent about tradeoffs. In an intentionally unindexed run, p50 got slower until maintenance built a MIDX. Cold-inclusive p99 was dominated by worker bootstrap, so the PR does not claim a cold-start win.
Bottom Line
PR #167695 makes OpenClaw's managed-worktree cleanup less eager and more predictable. Removal stops acting like repository maintenance, snapshots stop fetching behind the operator's back, and missing-object recovery gets a safer explicit retry path.
For anyone running OpenClaw against large or partial-clone repositories, that is a meaningful cleanup-path improvement.