Proposal: an install-gate hook so plugins can vet a package before it installs

[gabrielbav]

Problem

The plugin manager has no extension point that runs before an installation changes the profile. plugin-manager/operation, install-state and friends announce progress, but nothing can stop or pause an install. Third-party plugins, skills and subagent bundles run with access to the shell, files and credentials, so a community plugin that wants to check a package first (for prompt injection, credential theft, exfiltration, vulnerable dependencies, a license, an org policy…) currently has no way to do it.

Proposal: a small, generic hook in the plugin manager

DSH ships no policy. It only lets plugins register gates:

ctx.effect(() => ctx.pluginManager.registerInstallGate({
  id: 'my-gate',
  async vet({ spec, fetch, log, signal }) {
    // fetch(dir) installs the spec into a quarantine dir with lifecycle scripts disabled
    return { report, verifyInstalled, dispose } // report.level: 'pass' | 'review' | 'block'
  },
}))

• Every installation asks every registered gate before the profile changes: the Plugins page, updates, and the plugin_manager tool. The strictest ruling wins.
• block refuses the install (gate-blocked).
• review asks the person, then retries with an acknowledgement digest (gate-review / gateAcknowledged):
  • in the install dialog, through a new plugins.install.gate slot the gate fills;
  • in a conversation, through an approval card with display-only text. The model only sees the level and score, never gate reasons or findings, which can quote untrusted package content.
• Tamper check: after pnpm installs, every gate confirms the installed files match what it checked, otherwise the install rolls back (gate-mismatch).
• Optional requireInstallGate: true: refuses installs while no gate is running. dsh plugin add refuses too, because the CLI runs no gates.
• Report: InstallGateReport holds the level, the gate's own localized reasons, findings, a digest, and an optional score, checks and metrics. That's enough for a scanner, and a simple allow-list can return just a level and a reason.

With no gate registered, behaviour is exactly as today.

Other things people could build on it

The point is that this isn't one plugin's feature. Any of these become small community plugins, and several can run together:

• Org allow-list: only approved publishers or package names install.
• Signature or build-attestation checks: require npm signatures or attestations.
• License policy: review or block GPL/AGPL plugins in a company setting.
• Release-age or pinning rules: for example, no package younger than 7 days.
• Company approval service: ask an internal scanner or ticketing system before installing.
• Audit log: a gate that always passes but records every install.
• Security scanning: for example Airlock, below.

Working implementation

• Hook: gabrielbav/deepseek-harness@feat/install-gate (diff against master). It's one commit touching the plugin manager, the Plugins page install dialog, the approval card (displayDescription, ApprovalService.policyOf) and the CLI. Docs are updated in English and Chinese, with tests for multiple gates, a crashing gate, review/acknowledge, tamper rollback, a missing gate, and a Full-access session.
• Example gate: dsh-plugin-airlock (npm). It quarantines and scans with Cisco Skill Scanner, SkillScan, Cisco MCP Scanner, OSV-Scanner, Trivy and Gitleaks, plus custom SARIF tools. It's a normal third-party plugin and needs nothing from DSH besides this hook.

I know external PRs aren't accepted right now, so I'm sharing it here in case the team wants to adopt the idea or the code. Happy to adjust the design to whatever fits the project. If you'd like DSH to have this extension point, please upvote 🙏