feat: pnpm-style approve-builds for postinstall (with verified vendor directory)

[cau1k]

Problem

Registry items can declare postinstall commands. Today they’re either skipped by default or run via a broad --allow-postinstall flag. This is safe-by-default, but it lacks:

• A granular approval mechanism per hook / per item
• A persistent, auditable allowlist
• A way to auto-approve known-good hooks without blanket flags

Goal

Implement a pnpm-style approve-builds flow for postinstall:

• Detect postinstall hooks during install planning.
• Print a clear list of hooks that would run.
• Refuse to run by default unless explicitly approved.
• Provide commands to approve / revoke approvals.

Additionally: introduce an optional verified vendor directory which, when present, can auto-approve postinstalls for items that match a verified fingerprint.

Proposed UX

Install

• ocx add ... (default):
  • Plans installs
  • Lists detected postinstall hooks
  • Exits with instructions to approve
• ocx add ... --allow-postinstall:
  • Runs only hooks that are already approved OR verified-vendor
  • Still refuses unapproved/unverified hooks

Approval commands

• ocx approve-builds (interactive list) OR ocx approve <kind/name>
• ocx approve --all (approve everything currently pending)
• ocx revoke <kind/name> / ocx revoke --all
• ocx approvals list

Storage / Data model

Persist approvals in config (project or user config root):

• ~/.config/opencode/ocx.jsonc / .opencode/ocx.jsonc
• Example:
  • ocx.approvedPostinstall[<fingerprint>] = { kind, name, source, commands, approvedAt }

Fingerprints should be stable and specific:

• Hash of { kind, name, source, postinstall.commands, postinstall.cwd, item files hash }
• If the item changes, the fingerprint changes => requires re-approval

Verified vendor directory (auto-approval)

Introduce optional directory:

• .opencode/vendor/ (project) and/or ${XDG_CONFIG_HOME}/opencode/vendor/ (user)

Mechanism:

• Vendor entries contain:
  • Item identity (kind/name)
  • Fingerprint and/or SHA256 of the complete item manifest + referenced file contents
  • Allowed postinstall commands
• During install:
  • If the resolved item fingerprint matches an entry in vendor directory => hooks are auto-approved
  • Otherwise fall back to approval list

Notes:

• This is an “allowlist as code” that teams can commit and review.
• Can support multiple trust levels later (e.g., “verified by org key”), but start with simple hash-based verification.

Security constraints

• Never run postinstall by default.
• Never blanket-approve without explicit user intent.
• Show hook commands and (ideally) the computed fingerprint before approval.
• Approvals should be revocable.

Acceptance criteria

• Installing items with hooks presents a deterministic approval workflow.
• Approved hooks run; unapproved hooks do not.
• Vendor directory entries auto-approve matching items.
• Works for both project-level and user-level config roots.

[cau1k]

@cau1k-bot claude can you take a look at this?

[cau1k-bot]

Starting task with claude...

can you take a look at this?