OpenClaw merged another significant Cloud Workers fix just before the morning cutoff: PR #121262, "fix(cloud-workers): support large Git workspaces". The target is large monorepos, including OpenClaw's own checkout.
The issue was practical. Operators dispatching Cloud Workers from big Git workspaces could allocate and bootstrap a worker successfully, only to fail workspace reconciliation because the eligible workspace exceeded a 25,000-entry mutation limit. The PR body says the confirmed OpenClaw checkout contains more than 31,000 tracked files.
What Changed
The patch separates two contracts that were previously too tightly coupled: full-workspace inventory and worker-authored deltas. Git eligibility is now enumerated through file-backed NUL lists and checked before placement creation or provider allocation.
Local and remote manifest generation now share bounded budgets for:
- Entry count
- Path data
- Serialized manifest size
- Eligible content size
The inbound reconciliation limits remain unchanged: 25,000 records, 64 MiB per file, and 256 MiB total. The important difference is that unchanged large baselines are no longer treated like hostile worker-authored mutations.
Durable workspace result refs also get a v2 format. Instead of duplicating a large unchanged baseline, the new result stores complete authenticated manifests plus changed resulting blobs. Existing v1 full-tree refs remain recoverable, while new builds can read both formats.
Why It Matters
Cloud Workers are most useful on real projects, and real projects are often not small. A system that works in a fixture repo but fails after allocating cloud resources for a 31,000-file checkout is expensive, confusing, and hard to diagnose.
This fix moves failure earlier and makes success cheaper. Workspaces outside the full-inventory budgets fail with an actionable invalid-request response before a cloud resource is allocated. Workspaces inside the budget can dispatch, run, reconcile, and reclaim even when their unchanged baseline is larger than the inbound mutation cap.
That distinction matters for monorepos, generated-code-heavy apps, and long-lived product repositories where agents need remote compute but should not ship or reconcile unnecessary blobs.
Verification
The PR includes unusually concrete lifecycle proof. Its evidence section reports a physical checkout preflight with 32,870 manifest entries, a 5.4 MiB manifest, and about 402 MiB of eligible content.
It also reports a real Crabbox AWS lifecycle using a managed worktree with 31,286 tracked files. Dispatch reached active, unchanged reconciliation reached reclaimed, and a redispatch with a one-file remote edit returned exactly cloud-worker-size-proof.txt with a matching SHA-256.
Additional validation included:
- Hosted CI run
31363043921passing - 237 focused Cloud Worker tests passing
- A focused 31k-file boundary rerun passing 3/3
- Build, API baseline, dead export, typecheck, lint, import-cycle, database, schema, plugin-boundary, formatting, and native-boundary gates
Bottom Line
PR #121262 makes Cloud Workers more realistic for serious repositories. Large Git workspaces can now pass through a clearer admission boundary and reconcile by authenticated manifest plus actual changed blobs, instead of collapsing around a baseline-size mismatch.