OpenClaw merged a P0 update compatibility repair today in PR #146091: npm installations under custom global prefixes are now recognized during update checks and managed updates.
The fix targets a specific but painful layout. Users running OpenClaw through nvm with a custom npm prefix such as ~/.npm-global could hit an unknown package-manager result even though OpenClaw was installed through npm. The PR notes that the Linux installer and Node installation docs recommend this kind of prefix layout, which made the failure more than an edge case.
That matters because update tooling is one of the first places users notice friction. A healthy installation should not become "unknown" just because npm's global-root probe and the running launcher do not point through the same obvious path.
What Changed
The installed-owner resolver now checks npm's configured global prefix using the same Node runtime that is running OpenClaw. That lets npm handle .npmrc precedence and expansion instead of forcing OpenClaw to infer it from a narrower global-root probe.
OpenClaw also recognizes a global launcher that resolves into the matching npm package tree when command probes do not align. The same owner detection is used by update status and update admission, so the product should stop disagreeing with itself about whether a package can be updated.
For users, the visible change is straightforward:
- Custom npm prefix installs can be identified as npm-owned.
- Status and update admission use the same owner resolver.
- Unknown layouts still fail closed, but with better diagnostics.
- Existing pnpm and Bun detection remain unchanged.
The PR also improves the inspection details shown when OpenClaw still cannot identify a layout. Those diagnostics include the package root, probe results, inferred prefix, and launcher path.
Why It Matters
This is the kind of repair that keeps the update path boring, which is exactly what update paths should be.
Custom npm prefixes are common among users who avoid global writes into system-owned paths. Combined with nvm, they are a normal developer workstation setup, not a strange deployment. If that setup blocks OpenClaw updates, the user gets stuck before they can even receive the fix that would make updating easier.
The PR is careful about that bootstrapping problem. It documents that older installed updaters still may need an explicit prefix environment workaround for the first hop. Once the fixed candidate is in place, the resolver has the broader evidence it needs.
Validation
The PR reports 335 focused tests across update runner, global lifecycle, package-manager detection, status, and CLI command-runner suites. It also includes isolated macOS npm proof using an nvm-shaped Node path, a ~/.npm-global launcher and package, and a .npmrc prefix line.
After review, the maintainers added a Windows npm shim parser fix as well. The final focused suites passed across npm lifecycle, Bun, pnpm discovery, status, and CLI paths, and the branch passed the repository's changed-file checks.
The practical takeaway: if OpenClaw previously refused to update an npm install because the owner looked unknown under a custom prefix, PR #146091 is the repair to watch for in the next release.