PR #60140: fix: thread dangerouslyForceUnsafeInstall through plugins update command

• Repository: openclaw/openclaw
• Author: flute
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60140

Description (problem / solution / changelog)

Summary

Add --dangerously-force-unsafe-install flag to plugins update command and thread it through the entire update flow.

Currently, plugins update has no way to bypass the dangerous code scanner, causing all plugins using child_process to fail updating. This affects plugins that legitimately need process management: feishu, codex, clawarena, clawnetwork, etc.

Changes

3 files, 15 insertions:

• src/cli/plugins-cli.ts: Add dangerouslyForceUnsafeInstall to PluginUpdateOptions type + add --dangerously-force-unsafe-install option to the update command definition
• src/cli/plugins-update-command.ts: Accept the flag and pass it to updateNpmInstalledPlugins
• src/plugins/update.ts: Add parameter to function signature, thread it to all 6 installPluginFrom* calls (npm/clawhub/marketplace × dryRun/actual)

Test plan

# Before: blocked
openclaw plugins update clawnetwork
# → Failed to update clawnetwork: Plugin "clawnetwork" installation blocked: dangerous code patterns detected

# After: works with flag
openclaw plugins update clawnetwork --dangerously-force-unsafe-install
# → Updated clawnetwork 0.1.3 → 0.1.4

Fixes #60138 Related: #59241 #59171 #59508 #59521 #40162

Changed files

• src/cli/plugins-cli.ts (modified, +6/-0)
• src/cli/plugins-update-command.ts (modified, +2/-1)
• src/plugins/update.ts (modified, +7/-0)

PR #60624: fix(plugins): honor --dangerously-force-unsafe-install for --link install probes (#59521, #59508, #59171)

• Repository: openclaw/openclaw
• Author: JerrettDavis
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/60624

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: openclaw plugins install --link <path> --dangerously-force-unsafe-install dropped the unsafe flag during linked-path dry-run probes in both plugin install and hook-pack fallback paths.
• Why it matters: users hit misleading blocked install flows (Plugin ... installation blocked and/or Also not a valid hook pack) even when they explicitly requested the documented unsafe override.
• What changed: threaded dangerouslyForceUnsafeInstall through linked-path dry-run probes for plugin and hook-pack install paths; added CLI regression coverage for both.
• What did NOT change (scope boundary): no scanner rule changes, no hook-pack validation rule changes, no plugin update-command behavior changes.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• CLI

Linked Issue/PR

• Closes #
• Related #59521
• Related #59508
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: linked install fallback/probe branches did not consistently propagate dangerouslyForceUnsafeInstall into the underlying dry-run install calls.
• Missing detection / guardrail: no test asserted unsafe-flag forwarding for linked plugin probe + linked hook-pack fallback probe.
• Contributing context (if known): this sits in plugin-vs-hook-pack probing logic before persisting --link config metadata.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
• Target test or file: src/cli/plugins-cli.install.test.ts
• Scenario the test should lock in: plugins install <local-path> --link --dangerously-force-unsafe-install forwards unsafe flag to both linked plugin dry-run probe and linked hook-pack fallback probe.
• Why this is the smallest reliable guardrail: it directly verifies CLI option plumbing at the exact regression point without requiring external registry/network setup.
• Existing test that already covers this (if any): none specific to linked hook-pack fallback forwarding prior to this PR.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

plugins install --link <path> --dangerously-force-unsafe-install now consistently honors the unsafe override during linked-path probe/validation for both plugin and hook-pack paths.

Diagram (if applicable)

Before:
[plugins install --link --dangerously-force-unsafe-install]
  -> [plugin probe may drop flag] -> [blocked]
  -> [hook-pack fallback probe may drop flag] -> [blocked/fallback error]

After:
[plugins install --link --dangerously-force-unsafe-install]
  -> [plugin probe receives flag]
  -> [hook-pack fallback probe receives flag]
  -> [behavior matches documented unsafe override semantics]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Windows 11 (local dev), reported issue on macOS/Linux
• Runtime/container: Node 22.22.0, pnpm 10.32.1
• Model/provider: N/A
• Integration/channel (if any): plugins CLI
• Relevant config (redacted): isolated temp config dirs for verification

Steps

1. Run openclaw plugins install --link <plugin-path> --dangerously-force-unsafe-install.
2. Verify linked dry-run probe paths receive unsafe override.
3. Run scoped CLI tests for install command behavior.

Expected

• Unsafe override is honored consistently for linked path probes (plugin and hook-pack fallback).

Actual

• After fix: both linked probe paths receive unsafe flag and tests pass.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • Scoped suite passes: corepack pnpm test -- src/cli/plugins-cli.install.test.ts.
  • Regression tests confirm forwarding for linked plugin probe and linked hook-pack fallback probe.
  • Installer-level behavior check against C:/git/headroom/plugins/openclaw: blocked without unsafe flag, succeeds with unsafe flag.
• Edge cases checked:
  • Existing CLI install tests remain green after adding hook-pack forwarding coverage.
• What you did not verify:
  • Full end-to-end global openclaw binary install in this environment (separate local runtime/toolchain mismatch outside this PR scope).

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Risks and Mitigations

• Risk: linked installs with explicit unsafe override remain permissive where scanners report critical findings.
  • Mitigation: no new bypass introduced; this restores documented behavior parity and still requires explicit --dangerously-force-unsafe-install opt-in.

AI Disclosure

This PR was implemented with the assistance of OpenAI Codex on gpt5.3-codex.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/telegram/src/doctor-contract.ts (modified, +1/-1)
• extensions/whatsapp/contract-api.ts (modified, +25/-6)
• src/channels/plugins/contract-surfaces.ts (modified, +24/-8)
• src/channels/plugins/setup-wizard-helpers.ts (modified, +7/-1)
• src/cli/plugins-cli.install.test.ts (modified, +0/-1)
• src/hooks/install.ts (modified, +1/-0)
• src/plugins/discovery.ts (modified, +29/-0)