openclaw - 💡(How to fix) Fix [Feature]: Allow opt-in per-worktree heavy-check locks [1 pull requests]

Summary

Allow high-capacity local development setups to opt into per-worktree heavy-check locks.

Problem to solve

Local heavy checks currently use the Git common dir for openclaw-local-checks/heavy-check.lock, so linked worktrees serialize pnpm check:changed and most pnpm test runs.

That default is safe, but it slows down operators who intentionally run independent checks across multiple worktrees on machines with enough CPU and memory.

Proposed solution

Keep the current repo-common lock as the default.

Add an explicit opt-in, for example:

OPENCLAW_HEAVY_CHECK_LOCK_SCOPE=worktree

When set, store the heavy-check lock under the current worktree, such as .artifacts/openclaw-local-checks/heavy-check.lock. This keeps each worktree internally serialized while allowing sibling worktrees to run independently.

Alternatives considered

Disabling the lock entirely is weaker because it also allows competing heavy checks inside the same worktree.

Changing the default lock scope is weaker because low-memory machines still need the current conservative protection.

Impact

Affected: operators running multiple local worktrees.

Severity: workflow friction, not a correctness bug.

Frequency: occurs whenever parallel local checks are run across linked worktrees.

Consequence: independent validation jobs wait on each other even when the host has enough resources.

Evidence/examples

pnpm check:changed and most non-tooling pnpm test runs acquire the local heavy-check lock. The lock path is based on git rev-parse --git-common-dir, which is shared by linked worktrees.

Related context: PR #78501 is tightening local heavy-check protection, so this request keeps the safe default and only adds an explicit opt-in.

Additional information

Non-goals:

• Do not remove the default repo-common lock.
• Do not change CI behavior.
• Do not bypass Vitest cache isolation.
• Do not reduce protection for low-memory local machines.