Update command no longer blocked by Corepack prompts
The 'openclaw update' command now suppresses Corepack's interactive download prompts during preflight checks, so the update process completes without hanging when pnpm versions don't match.
The openclaw update command runs a preflight check that shells out to pnpm install across multiple candidate versions. When the system's pnpm version differs from the project's pinned version, Corepack attempts to download the correct version — but its default behavior is to prompt for user approval first. Since the update command is designed to run non-interactively (including in CI environments), this caused the command to hang and fail.
A new environment variable handler now automatically sets COREPACK_ENABLE_DOWNLOAD_PROMPT=0 before the preflight install runs, unless that variable is already explicitly configured. Users who want Corepack's default prompting behavior can still opt in by setting the variable directly.
This change lives in the update infrastructure module, affecting only the global install environment setup. It also includes a minor optimization: the environment merging logic now short-circuits and returns the existing environment object unchanged when no modifications are needed.
View Original GitHub Description
Issue
When running pnpm openclaw update on a different pnpm version compared to the pinned one inside the root's package.json (packageManager), the update script fails during the preflight deps install step when it shells out pnpm install as Corepack attempts to download the pinned pnpm version first.
Corepack's default setting is to prompt for approval before downloading the version, which leads to the script being unable to finish the preflight step and thereby not updating:
<img width="1422" height="2032" alt="openclaw-update-issue-corepack-setting" src="https://github.com/user-attachments/assets/63ce624d-0755-4dc8-9e3f-730f7c3e8c17" />This may happen for all 10 upstream candidates.
Changes
In src/infra/update-global.ts/#133-173 -> createGlobalInstallEnv() now always applies COREPACK_ENABLE_DOWNLOAD_PROMPT=0 unless the env already sets it, so the preflight install path stays non-interactive and installs the pinned pnpm version.
Other solutions considered
I'm actually unsure if changing Corepack's default behavior here is the right approach. It does allow for an agent-first usage (it also works in non-interactive envs like CI)
If the preflight deps install should continue to respect Corepack's default setting, an alternative way is:
- allow Corepack prompts only when stdin is a TTY and the user did not ask for non-interactive mode
- keep suppression for --json, CI, and other non-interactive paths
- optionally add an explicit flag like
--prompt-corepackor--interactive-preflight
Current (previous) behavior
openclaw updateis non-interactive- It fetches upstream and resolves @{upstream}.
- It runs
git rev-list --max-count=10 upstreamSha, so it collects up to 10 candidate SHAs (src/infra/update-runner.ts#611-635) - It creates a detached temp worktree at the upstream tip, then for each candidate SHA it checks out that SHA and runs the preflight install/build/lint there (
src/infra/update-runner.ts/#647-710) - If one candidate passes, it rebases your current branch onto that selected SHA.
Tests
This has been tested via running COREPACK_HOME="$(mktemp -d)" COREPACK_ENABLE_DOWNLOAD_PROMPT=1 node scripts/run-node.mjs update
It also adds a tests:
pnpm vitest run src/infra/update-global.test.ts(default becomes "0", explicit "1" is preserved)