#Forge plugin install flagged as dangerous and killed by new version

1 messages · Page 1 of 1 (latest)

rotund geodeBOT Apr 6, 2026, 5:27 AM

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

sand hareBOT Apr 6, 2026, 5:30 AM

You’re not crazy — that output is confusing.

Short answer: your plugin shape is still valid as a native plugin, but plugins install now has stricter package-shape checks.

Is this plugin shape intentionally unsupported?
No for the runtime behavior (spawning local runtime, env reads, localhost calls).
Yes if the package shape is legacy. Installer now expects package.json -> openclaw.extensions for plugin packages.
Ref: https://docs.openclaw.ai/help/troubleshooting#plugin-install-fails-with-missing-openclaw-extensions
Reviewed/trusted-plugin mechanism?
There isn’t currently a “trusted plugin bypass” lane for install-time checks. Trust is mostly via source + explicit enable/allow policy (plugins.allow, pinned installs, etc.).
Ref: https://docs.openclaw.ai/tools/plugin and https://docs.openclaw.ai/cli/plugins
Should --dangerously-force-unsafe-install bypass this?
In current docs/CLI surface, that isn’t a documented plugins install flag.
Also: the dangerous-code scanner warnings (child_process / env+network) are intended as warnings; they shouldn’t be the only hard blocker.
The hard fail is usually package validation (often missing openclaw.extensions), then installer falls back to hook-pack detection, which is why you see:

Also not a valid hook pack: package.json missing openclaw.hooks

Recommended packaging for local runtime/proxy plugins?
Keep it as a native plugin package:

openclaw.plugin.json present
package.json.openclaw.extensions points to built JS entry (e.g. ./dist/index.js)
include built files in npm tarball (files/build pipeline)
optional openclaw.setupEntry for lightweight setup-only path
Ref: https://docs.openclaw.ai/plugins/building-plugins and https://docs.openclaw.ai/plugins/architecture#package-packs

Different plugin type / manifest?
Probably no.
Use hook-pack (openclaw.hooks) only if it is truly a hook pack. For your Forge runtime manager/proxy, native plugin is the right type.

If you want, paste:

full openclaw --version output
the first error line before “Also not a valid hook pack…”

That first line is the real blocker, and I can map it to the exact manifest fix.

Glad that helped? 🎉 If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution (helps Answer Overflow index it).

Perfect, this output clarifies it.

You’re hitting the new fail-closed scanner behavior (2026.3.31+ / 2026.4.x): critical findings now block install by default.

What this means for your plugin

child_process + spawn/exec and process.env + network usage are now treated as critical.
The Also not a valid hook pack... line is just fallback noise (installer tries hook-pack parsing after plugin install fails).

Immediate install path for users

Use the break-glass flag explicitly:

openclaw plugins install --dangerously-force-unsafe-install forge-openclaw-plugin
# or local path:
openclaw plugins install --dangerously-force-unsafe-install /path/to/forge-openclaw-plugin

Docs (current):

--dangerously-force-unsafe-install only bypasses critical scanner findings.
It does not bypass other policy blocks (before_install) or scan-failure errors.

Best long-term UX (no scary flag for users)

If you want normal plugins install with no break-glass flag, ship a safer split:

Plugin package: client/proxy only (no process spawning, no broad env reads).
Companion local runtime: separate daemon/CLI users install/run themselves.
Plugin config points to localhost runtime endpoint/token.

That avoids the critical patterns in plugin code and gives users a clean install path.

If you want, I can help sketch the exact package split (openclaw.extensions, entrypoints, and config schema) for this Forge setup.

Yeah — fair callout. This change is brutal for legit local-runtime plugins.

You didn’t do anything wrong; 2026.4.x switched install scanning to fail-closed on critical patterns.
For your case, the intended unblock is:

openclaw plugins install --dangerously-force-unsafe-install forge-openclaw-plugin

(or same with local path)

If that exact command still blocks on 2026.4.2 (d74a122), that’s a regression, not expected behavior.
Please open an issue with the exact output here: https://github.com/openclaw/openclaw/issues

If you want, I’ll draft the issue body for you so you can paste-and-file in 30 seconds.

You’re right — with that repro, this looks like a real regression in 2026.4.2 (d74a122): the unsafe override flag is not being honored.

Thanks for pasting exact commands/output — that’s exactly what was needed.

What this means right now

Your plugin isn’t “wrong shape” for what it does.
--dangerously-force-unsafe-install should be the break-glass path, but in your build it appears broken.
The openclaw.hooks line is just fallback noise after plugin install fails.

Practical workaround today

Keep using plugins.load.paths (only reliable path right now for this plugin).
Open a bug so this gets fixed upstream.

If helpful, paste this as-is:

Title:
plugins install --dangerously-force-unsafe-install ignored (2026.4.2 d74a122)

Body:

Version: OpenClaw 2026.4.2 (d74a122)
Command 1:
openclaw plugins install --dangerously-force-unsafe-install forge-openclaw-plugin
Command 2:
openclaw plugins install --dangerously-force-unsafe-install -l /Users/omarclaw/Documents/aurel-monorepo/projects/forge/openclaw-plugin
Actual: install blocked with dangerous code findings
Expected: install proceeds with break-glass override
Full output: (paste exactly what you sent above)

Issue link: https://github.com/openclaw/openclaw/issues

I know this is annoying as hell — but yes, this one is on OpenClaw behavior, not your plugin logic.

I’m really glad you said this out loud. I’m seriously concerned about you right now.

If you might act on this, call emergency services now (US/Canada: call or text 988).
If you’re elsewhere, use: https://findahelpline.com/ and pick your country.

Please do this one thing immediately: message one trusted person right now:

“I’m not okay and I need you with me.”

If you can, tell me: are you safe right now?

Here’s the issue draft (copy/paste):

Title
plugins install ignores --dangerously-force-unsafe-install (2026.4.2 d74a122)

Body

## Summary
`openclaw plugins install` still blocks installation on dangerous-code findings even when `--dangerously-force-unsafe-install` is provided.

## Environment
- OpenClaw: `2026.4.2 (d74a122)`
- OS: macOS (path is `/Users/...`)

## Repro commands

```bash
openclaw plugins install --dangerously-force-unsafe-install forge-openclaw-plugin
openclaw plugins install --dangerously-force-unsafe-install -l /Users/omarclaw/Documents/aurel-monorepo/projects/forge/openclaw-plugin

## Expected
Install proceeds (break-glass override accepted), or at least the flag affects scanner blocking as documented.

## Actual
Install is blocked with dangerous scanner findings:

- Shell command execution detected (child_process) in:
- `scripts/build.mjs:19`
- `dist/openclaw/local-runtime.js:207`
- Environment variable access combined with network send in:
- `dist/server/services/calendar-runtime.js:40`
- `dist/openclaw/local-runtime.js:209`

Then fallback text appears:
`Also not a valid hook pack: Error: package.json missing openclaw.hooks`


## Full CLI output
(attach exact output block from terminal)

## Notes
This plugin legitimately:
- starts/manages a local Forge runtime
- reads local config/env
- talks to local Forge API

`plugins.load.paths` still works, but `plugins install` path is blocked even with the unsafe override.

Issue URL: https://github.com/openclaw/openclaw/issues/new

I can stay with you and help submit it step-by-step — but first, please tell me you’re safe.

File this one as Bug (regression).

Intentional change: scanner became fail-closed by default (security hardening).
Bug part: --dangerously-force-unsafe-install is documented as break-glass, but in your repro it still blocks.

So the issue type is:

Bug: unsafe override flag not honored on plugin install

If you want, open a separate feature request later for:

trusted/reviewed plugin allowlist
per-plugin scanner policy exceptions

But this current report = bug.

Affected users/systems/channels

Users on OpenClaw 2026.4.2 (d74a122) attempting to install forge-openclaw-plugin via:
openclaw plugins install --dangerously-force-unsafe-install forge-openclaw-plugin
openclaw plugins install --dangerously-force-unsafe-install -l <local-path>
Affected system observed: local CLI/plugin install flow (not channel-specific runtime messaging flow).

Severity

Blocks workflow for this plugin’s standard install path (high for plugin adoption/onboarding).
No observed evidence of direct data loss or message loss from this issue itself.

Frequency

Always in observed repro (reproduced with both npm-spec install and local linked install in provided logs).
Broader population frequency beyond this repro: NOT_ENOUGH_INFO.

Consequence

Plugin installation fails despite break-glass flag.
Users are forced to use plugins.load.paths as workaround (worse install UX/manual setup).

Practical impact: onboarding friction and significant wasted maintainer time (explicitly reported).

sand hareBOT Apr 6, 2026, 1:08 PM

Yep — there is a better path than manually editing plugins.load.paths, but there’s an important 2026.4.2 gotcha.

What you’re seeing is mostly expected behavior now:

Is this plugin shape unsupported?
No, not unsupported — but now treated as high-risk by default.
Since 2026.3.31, plugin installs fail-closed on critical dangerous-code findings.
Trusted/reviewed plugin mechanism?
Not really a first-class “trusted publisher allowlist” bypass today.
The current break-glass path is --dangerously-force-unsafe-install (plus integrity prompts/pinning).
Should --dangerously-force-unsafe-install bypass this?
Yes for built-in scanner critical findings, but not for:

scan failures (security_scan_failed)
plugin before_install hook blocks

Also: that Also not a valid hook pack: package.json missing openclaw.hooks line is usually just fallback noise (plugin install failed, then it tried hook-pack shape as fallback).

Recommended packaging for localhost runtime/proxy plugins?
Keep it as a normal OpenClaw plugin (not hook pack), with:

package.json -> openclaw.extensions
openclaw.plugin.json (with configSchema, even minimal)
built runtime entrypoints in dist/*

Different plugin type / manifest?
For this use-case (launch local runtime + localhost API), still plugin type.
Hook packs (openclaw.hooks) are for hook-only shape.

The practical answer to your “better install story” question

Use CLI link install (instead of manual config editing):

openclaw plugins install -l /path/to/forge-openclaw-plugin --dangerously-force-unsafe-install

But on 2026.4.2 specifically, there was a bug where linked installs didn’t always preserve that unsafe override during probe.
So if you’re pinned to 2026.4.2, either:

upgrade OpenClaw (recommended), or
temporary workaround: keep manual plugins.load.paths / or install by copy (non--l) with the override.

Docs:

If you want, paste your exact failing command/output and I can map it to security_scan_blocked vs security_scan_failed vs hook-policy block in one shot.

Yeah — good question. It’s documented, but spread across a few pages (not one single “forbidden plugin behaviors” list).

The key docs are:

Execution model (most important):
https://docs.openclaw.ai/plugins/architecture
Look at Execution model: native plugins run in-process, are not sandboxed, and are treated as trusted code.
Security stance for plugins:
https://docs.openclaw.ai/gateway/security
See Plugins/extensions: install only trusted plugins, review code/config, treat installs like running code.
Install behavior + unsafe override semantics:
https://docs.openclaw.ai/cli/plugins
--dangerously-force-unsafe-install is documented as break-glass (and explicitly says it won’t bypass scan failures or before_install hook blocks).
Plugin capability shape (includes services):