PR #60153: Use owning npm prefix for global updates

• Repository: openclaw/openclaw
• Author: jayeshp19
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60153

Description (problem / solution / changelog)

Summary

• Problem: openclaw update uses bare npm from PATH for npm-based global updates, even after it has already identified the installed OpenClaw package root.
• Why it matters: in mixed global Node setups like Homebrew-installed OpenClaw with nvm first on PATH, the updater targets the wrong global npm root and can fail or update the wrong install context.
• What changed: infer the owning npm prefix from the installed package root, prefer that npm executable for npm root -g and global install commands, and add regression coverage for the Homebrew-vs-nvm case.
• What did NOT change (scope boundary): no changes to non-npm update flows, git checkout update logic, plugin install behavior, or daemon/runtime behavior outside the updater path.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes https://github.com/openclaw/openclaw/issues/60150
• Related #
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: updater logic treats manager = npm as “run npm from PATH” instead of resolving the npm executable associated with the installed package root being updated.
• Missing detection / guardrail: no guardrail or test covered mixed global npm environments where the current OpenClaw install belongs to one prefix and PATH points at another npm.
• Prior context (git blame, prior PR, issue, or refactor if known): unknown.
• Why this regressed now: not confirmed as a recent regression; likely a latent bug that only shows up when users mix global Node toolchains.
• If unknown, what was ruled out: ruled out a generic child-process spawn failure and ruled out a broken OpenClaw runtime install. The failure is isolated to updater package-manager resolution.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/infra/update-global.test.ts
• Scenario the test should lock in: package root is under a Homebrew-style global npm prefix, while bare npm root -g resolves a different global root from PATH; updater should still choose the owning npm executable and correct package root.
• Why this is the smallest reliable guardrail: the bug is in path/prefix resolution logic, so a focused unit test around manager/root/argv selection catches it without requiring full global install setup.
• Existing test that already covers this (if any): existing tests covered manager detection and install argv generation, but not mixed-prefix npm environments.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• openclaw update now prefers the npm executable associated with the installed OpenClaw package root for npm-based global installs when it can infer that prefix.
• This changes behavior only in mixed npm-prefix environments; behavior is unchanged for single-prefix installs.

Diagram (if applicable)

Before:
[openclaw update] -> [detect install root=/opt/homebrew/lib/node_modules/openclaw]
                 -> [run bare npm from PATH]
                 -> [npm root -g = ~/.nvm/.../node_modules]
                 -> [wrong global context]

After:
[openclaw update] -> [detect install root=/opt/homebrew/lib/node_modules/openclaw]
                 -> [infer owning prefix=/opt/homebrew]
                 -> [run /opt/homebrew/bin/npm]
                 -> [npm root -g = /opt/homebrew/lib/node_modules]
                 -> [correct global context]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (Yes)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:
  • The updater now chooses a more specific npm executable instead of bare npm from PATH when the installed package root clearly maps to an owning npm prefix. This reduces ambiguity rather than expanding execution scope. Fallback remains the existing behavior when no prefix can be inferred.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local global install
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted):
  • installed package root: /opt/homebrew/lib/node_modules/openclaw
  • npm on PATH: /Users/jayesh/.nvm/versions/node/v23.6.0/bin/npm

Steps

1. Install OpenClaw under Homebrew global npm so the package root is /opt/homebrew/lib/node_modules/openclaw.
2. Put nvm npm first on PATH.
3. Run:

   which npm
   npm root -g
   /opt/homebrew/bin/npm root -g
   openclaw update

Expected

• Updater should use the npm executable that owns the installed OpenClaw package root.
• For the example above, that means /opt/homebrew/bin/npm.

Actual

• Updater uses bare npm from PATH, which resolves the nvm global root instead of the Homebrew global root.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Machine-level evidence from the repro environment:

{
  "pkgRoot": "/opt/homebrew/lib/node_modules/openclaw",
  "pathNpm": "/Users/jayesh/.nvm/versions/node/v23.6.0/bin/npm",
  "pathNpmRoot": "/Users/jayesh/.nvm/versions/node/v23.6.0/lib/node_modules",
  "selectedNpm": "/opt/homebrew/bin/npm",
  "selectedRoot": "/opt/homebrew/lib/node_modules",
  "oldUpdaterWouldMismatch": true,
  "patchedUpdaterMatches": true
}

Human Verification (required)

• Verified scenarios:
  • confirmed mixed-prefix environment on a real macOS machine
  • confirmed bare npm root -g points at nvm while installed package root is under Homebrew
  • confirmed patched resolution logic selects /opt/homebrew/bin/npm
  • confirmed patched resolution logic maps back to /opt/homebrew/lib/node_modules/openclaw
• Edge cases checked:
  • fallback behavior remains unchanged when no npm prefix can be inferred from package root
  • pnpm/bun argument generation remains unchanged
• What you did not verify:
  • full repo test suite in this checkout
  • full end-to-end openclaw update execution from the patched repo build

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk:

  • inferring npm prefix from package-root shape could be too narrow and miss some valid npm global layouts
  • Mitigation:
    • only prefer the owning npm executable when the package root has the expected .../lib/node_modules/<pkg> shape and the derived npm binary exists; otherwise fall back to existing behavior

• Risk:

  • package-manager resolution behavior changes for npm global installs
  • Mitigation:
    • change is scoped to npm installs only and regression coverage was added for the mixed-prefix scenario that triggered the bug

Changed files

• src/cli/update-cli/update-command.ts (modified, +4/-4)
• src/infra/update-global.test.ts (modified, +118/-1)
• src/infra/update-global.ts (modified, +62/-7)
• src/infra/update-runner.ts (modified, +3/-3)

PR #60172: fix(update): use manager binary associated with installed global root

• Repository: openclaw/openclaw
• Author: lui62233
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60172

Description (problem / solution / changelog)

Summary

• derive the npm/pnpm executable from the installed package's global root instead of always using the bare PATH command
• thread the resolved executable into global update and fallback update steps
• add coverage for manager-command resolution and argv construction

Why

When OpenClaw is installed under one global prefix but a different npm is first on PATH, openclaw update should use the package owner's npm (for example /opt/homebrew/bin/npm) rather than the unrelated PATH npm.

Fixes #60150

Changed files

• src/infra/update-global.test.ts (modified, +20/-4)
• src/infra/update-global.ts (modified, +46/-5)
• src/infra/update-runner.ts (modified, +4/-2)