#22467: fix: failure while installing skills

## Summary This fixes #22459 by avoiding the following line from appearing while installing skills. ``` "Do you want to continue? [Y/n]" ``` - **Problem:** `openclaw onboard` fails to install node-based skills (e.g. `clawhub`, `mcporter`) when pnpm/yarn/bun is managed by Corepack — Corepack emits an interactive "Do you want to continue? [Y/n]" download confirmation that can never be answered inside the non-interactive install subprocess, causing all Corepack-managed package manager installs to exit 1. - **Why it matters:** This blocks onboarding entirely on any clean system where Corepack hasn't yet cached the chosen package manager binary — a common first-run condition. - **What changed:** `src/process/exec.ts` now sets `COREPACK_ENABLE_DOWNLOAD_PROMPT=0` in the child process environment whenever the spawned command is `pnpm`, `yarn`, or `bun` (detected by basename, stripping `.cmd`/`.exe` suffixes). This mirrors the existing `NPM_CONFIG_FUND=false` suppression already in place for npm. Five new tests were added to `src/process/exec.test.ts` covering injection for each package manager, the negative case (node), and the no-override guarantee. - **What did NOT change:** Install behavior beyond prompt suppression is unchanged — Corepack still downloads the binary automatically, just silently. No changes to skill metadata, onboarding flow, or any other command execution path. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [x] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #22459 ## User-visible / Behavior Changes `openclaw onboard` skill installs using pnpm, yarn, or bun now complete silently on systems where Corepack has not yet cached the package manager binary. Previously these installs failed with exit 1 and the Corepack prompt text leaked into the displayed error message. ## Security Impact (required) - New permissions/capabilities? No - Secrets/tokens handling changed? No - New/changed network calls? No — Corepack already made the same download; this only removes the confirmation gate - Command/tool execution surface changed? No - Data access scope changed? No - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: Any (macOS / Linux / Windows) - Runtime/container: Docker Container - Model/provider: N/A - Integration/channel (if any): N/A - Relevant config (redacted): `nodeManager: "pnpm"` in skill install preferences ### Steps 1. Start from a system where pnpm is not yet cached by Corepack (`corepack disable pnpm` or fresh environment). 2. Run `openclaw onboard`. 3. Select **Yes** to configure skills, choose any skill with a node install spec, select **pnpm** as the node manager. ### Expected - Skills install successfully without any interactive prompt. ### Actual - Install fails with exit 1; Corepack's "Do you want to continue? [Y/n]" prompt appears in the failure message and the subprocess hangs until timeout. ## Evidence - [x] Failing test/log before + passing after Five new vitest tests in `src/process/exec.test.ts` assert: 1. `pnpm` invocation → `COREPACK_ENABLE_DOWNLOAD_PROMPT=0` in child env 2. `yarn` invocation → `COREPACK_ENABLE_DOWNLOAD_PROMPT=0` in child env 3. `bun` invocation → `COREPACK_ENABLE_DOWNLOAD_PROMPT=0` in child env 4. `node` invocation → `COREPACK_ENABLE_DOWNLOAD_PROMPT` not injected 5. Caller-supplied `COREPACK_ENABLE_DOWNLOAD_PROMPT=1` → not overridden ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: Reproduced the hang using the exact terminal output from the bug report; confirmed `COREPACK_ENABLE_DOWNLOAD_PROMPT=0` is the documented env var for suppressing the download prompt. - Edge cases checked: Existing value not overridden (env option takes priority); `.cmd`/`.exe` suffixes on Windows correctly stripped before basename comparison; `bun` (not in `resolveCommand`'s auto-cmd list) handled separately in tests. - What you did **not** verify: End-to-end `openclaw onboard` run against a live environment (no installed dependencies in worktree at time of review). ## Compatibility / Migration - Backward compatible? Yes - Config/env changes? No - Migration needed? No ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert the `shouldSuppressCorePack` block in `src/process/exec.ts` (approximately 10 lines). - Files/config to restore: `src/process/exec.ts`, `src/process/exec.test.ts` - Known bad symptoms reviewers should watch for: Any pnpm/yarn/bun subprocess that intentionally relied on Corepack prompting the user before downloading (no known case in this codebase). ## Risks and Mitigations - Risk: `COREPACK_ENABLE_DOWNLOAD_PROMPT=0` causes Corepack to download package manager binaries without user awareness in contexts outside of skill installs. - Mitigation: The env var is set only on the spawned child process, not on the OpenClaw process itself, so it cannot propagate to other tools or user sessions. <!-- greptile_comment --> <h3>Greptile Summary</h3> Prevents `openclaw onboard` skill installs from hanging when Corepack needs to download pnpm/yarn/bun binaries by setting `COREPACK_ENABLE_DOWNLOAD_PROMPT=0` in the child process environment. **Key changes:** - Added `shouldSuppressCorePack` detection logic in `src/process/exec.ts:120-123` that identifies pnpm, yarn, or bun commands by stripping `.cmd`/`.exe` suffixes before basename comparison - Sets `COREPACK_ENABLE_DOWNLOAD_PROMPT=0` only when the env var is not already present (respects caller-supplied values) - Mirrors existing `shouldSuppressNpmFund` pattern for consistency - Five comprehensive tests verify the behavior for each package manager, negative case (node), and no-override guarantee <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The fix is minimal (10 lines of logic), well-tested (5 new tests covering all cases including Windows-specific behavior), follows existing patterns in the codebase (`shouldSuppressNpmFund`), and solves a blocking bug without introducing new behavior beyond prompt suppression. The env var is scoped to child processes only and respects caller overrides. - No files require special attention _{Last reviewed commit: aef9a60} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->