/plugin-install

description: Confirm and install exactly one uninstalled plugin-catalog entry, or record an explicit decline.
allowed-tools:
  - Bash

Accept exactly one plugin name as `<name>`. This command installs one named, previously surfaced plugin at a time -- never several, and never a plugin the user has not already seen named (via SessionStart, a prompt-time recommendation, `overview`, `plugins <text>`, or a bypass-gate warning) in this conversation.

When the user explicitly accepts a plugin recommendation in this session -- and the prompt hook has registered that acceptance and handed you an instruction naming the plugin -- run exactly `${CLAUDE_PLUGIN_ROOT}/scripts/sf-context plugin-install <name> --accept-proposed`. The runtime requires that exact plugin to exist in the same-session proposal ledger and be selected in the active workflow. If it is a trusted install target -- either the exact local `./plugins/builder/<name>` source, or a curated, reviewed external identity the runtime allowlists in code (currently only `agentforce-adlc` from the official Claude Code marketplace) -- the user's acceptance is the sole confirmation and the guarded runtime installs immediately. Do not add a second prose confirmation or rerun the command.

Prefer to elicit that acceptance with an ordinary conversational question and the user's own typed reply -- that is the primary path, and a literal `UserPromptSubmit` message (the user's own words) advances the session's decision workflow to `selected`. A structured `AskUserQuestion` selection is also honored: when the user picks an option that **names exactly one open proposal**, a PostToolUse bridge advances the same workflow to `selected` just as a typed reply would. So if you do ask with `AskUserQuestion`, make each install option **name the plugin** (e.g. "Install salesforce-test-drive"); a bare "Yes"/"No" option names no plugin and advances nothing, and you would then need the user's typed confirmation instead. If you are proposing two or more plugins at once, ask about them with **separate, sequential questions that each name exactly one plugin** rather than a single question with a combined option (e.g. "Install both") -- a combined option or answer (such as "Both plugins") never names a single open proposal, so the bridge deliberately leaves it unresolved instead of guessing which one, or both, the user meant. A bare affirmative such as "yes", "ok", or "install it" advances the workflow -- and earns you the named install instruction -- **only when exactly one plugin is open to acceptance**; the runtime resolves that sole candidate for you, including a lone proposal that a topic change just cleared from the live workflow, but only on your very next message -- a short-lived, one-shot marker carries it forward for that one message and nothing later. When two or more are open (for example a `plugins <text>` discovery list that returned more than one), a bare "yes" is ambiguous: the runtime deliberately does not pick one and instead tells you to ask which the user means, so `--accept-proposed` would refuse with a missing-same-session-selection error. Do not guess or retry `--accept-proposed` then -- ask the user which single plugin they mean and have them **name** it (e.g. "install salesforce-test-drive"); a named acceptance always selects itself, no matter how many were proposed, and is also the only way to re-accept a plugin the user previously declined (a bare "yes" never reverses a decline).

If the accepted entry is not a trusted install target -- an external URL/object source (or any other non-local source shape) whose exact identity is not on the runtime's curated allowlist -- the same command installs nothing. It prints the concrete source, a TRUST WARNING, and a content-bound nonce. Relay that output faithfully and ask the user to confirm that exact source. Only after that confirmation run `${CLAUDE_PLUGIN_ROOT}/scripts/sf-context plugin-install <name> --confirm <exact nonce>`. Never invent, shorten, transform, reuse, or expose another nonce; a stale or mismatched nonce requires a fresh source preview. A bare self-directed `plugin-install <name>` call retains this source-preview path for compatibility and does not inherit the trusted accepted-proposal fast path.

A successful install shells out to `claude plugin marketplace add` when needed for a reachable local-development checkout and then `claude plugin install` on the user's behalf, with fixed argv and no shell. Failure output contains only exit/timeout metadata, never raw subprocess text. Installation changes Claude Code's on-disk/enabled state; it does **not** prove that this running session's plugin catalog, skills, hooks, agents, or MCP servers have been rebuilt.

On success, relay the command's complete activation handoff verbatim. Then **stop the turn**: do not continue the original plugin-dependent request, invoke a skill from the new plugin, or claim the plugin is active. The user's next action is the exact host command `/reload-plugins`; do not try to execute or imitate that slash command through Bash. The handoff is task-aware: when installation interrupted a concrete task it explicitly tells the user to say `continue` after reload to resume that task; a recommendation-only install instead asks for a new concrete task. After the user runs `/reload-plugins`, follow that handoff without making them restate an interrupted task, but first use Claude Code's refreshed plugin/skill inventory to verify that the named plugin or its namespaced components are present. If the host does not expose a refreshed inventory, say activation could not be verified and ask the user to start a fresh session; never turn an on-disk install or `enabledPlugins` setting into a claim of live activation. A SessionStart hook payload does not identify `/reload-plugins` or enumerate the active plugin set, so do not invent either signal.

When the user declines instead -- says no, "not now", or otherwise reject