无钥匙的安全门：当插件安全阻止合法使用

Source: Dev.to

Problem

你发现了一个社区插件正好满足你的需求，但安装被阻止了。

WARNING: Plugin "openclaw-codex-app-server" contains dangerous code patterns:
Shell command execution detected (child_process) (src/client.ts:660)
Plugin installation blocked: dangerous code patterns detected

没有任何覆盖标志能生效。--dangerously-force-unsafe-install 标志被阻止，而社区文档中提到的 --trust 标志根本不存在。

这正是一个安全机制在原则上是正确的，但在实际使用中却失效的典型案例。

Why the Current Approach Fails

• 插件使用 child_process，因为这正是它的工作——启动编码 CLI。
• OpenClaw 的静态分析捕获了这种用法并阻止了安装。考虑到过去出现的恶意技能，这种做法是合理的。
• 然而，这道门没有钥匙：没有官方渠道可以说“我已经审查过此插件，我接受风险”。

Issues with the Existing Flags

1. 误导性的标志行为 – --dangerously-force-unsafe-install 本应提供明确的同意，但实际上并未覆盖阻止。
2. 未文档化的覆盖方式 – 安全默认设置应该是可配置的，但当覆盖方式未被记录时，用户要么放弃，要么采用不安全的变通办法。
3. 过于宽泛的静态分析 – 在字符串层面阻止 child_process 会同时捕获恶意和合法的使用。一个启动 Codex CLI 的插件与运行 curl | bash 的插件本质上是不同的。

Proposed Improvements

• 每个拒绝都必须有文档化的允许 – 提供一个清晰、文档化的机制，让用户在审查代码后能够覆盖阻止。
• 覆盖标志必须真正起作用 – 像 --dangerously-force-unsafe-install 这样的标志应按宣传的那样工作。
• 为静态分析添加同意层 – 在用户明确同意后才继续，并将决定记录下来以供审计。
• 记录信任决策 – 记录用户何时覆盖安全门，以便后续审计。

目标并不是完全移除这道门，而是给它上锁并提供钥匙给用户。