Plugin Marketplace: Discovery & Trust
Distinguishing catalog, installation, runtime discovery, enablement state, and plugin root trust
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Plugin Marketplace: Discovery & Trust”?
Distinguishing catalog, installation, runtime discovery, enablement state, and plugin root trust
Make the claim earn its place. Use this page as a decision aid, not a definition to memorize. Connect the idea to one real task, one observable result, and one failure that would change your mind.
Write one question you could answer with evidence after trying this idea.
A conclusion that sounds complete but leaves the key assumption untested.
Marketplace：Discovery, Installation, and Execution Layers
A catalog can surface plugins, an installer can copy or clone them, and the runtime still needs to evaluate enabled status and trust. Only by separating these three layers can you see the real security boundaries of a plugin ecosystem.
Lesson Objectives
Reconstruct the Discovery Chain
Explain index-first, filesystem fallback, manifest parsing, and source precedence.
Separate Four States
Distinguish between discoverable, installed, enabled, and trusted — avoid collapsing everything into a single "installed" semantic.
Draw the Execution Boundary
Determine how skills, agents, hooks, MCP, and scripts are handled differently when a plugin is not trusted.
From Catalog to Runtime
Real Structure of a Marketplace and Plugin
Catalog answers "what's available"
marketplace-root/
├── .grok-plugin/
│ ├── marketplace.json
│ └── plugin-index.json
├── plugins/
│ └── sample-plugin/
└── default-skills/Scanner reads the index first; if missing or invalid, it falls back to scanning plugins/*/. default-skills can be added as a virtual plugin in the results.
Plugin answers "what's inside"
sample-plugin/
├── plugin.json
├── skills/*/SKILL.md
├── commands/
├── agents/
├── hooks/hooks.json
├── .mcp.json
└── scripts/plugin.json is the preferred manifest; .grok-plugin/plugin.json and .claude-plugin/plugin.json are fallback locations. PluginManifest can override paths for skills, commands, agents, hooks, MCP, and LSP; after parsing, paths are validated to remain within the plugin root.
Two Discovery Chains, Each with Its Own Role
--plugin-dirHighest source priority
.grok/pluginsCompatible with .claude
$GROK_HOME/pluginsInstalled plugins
git / local source
[plugins].pathsLocation affects trust
Key distinction: xai-grok-plugin-marketplace handles catalog, scanning, and installation; xai-grok-agent::plugins handles runtime discovery, deduplication, name conflicts, enabling, and trust. A record appearing in Marketplace does not mean the component is immediately executable.
Three Gates from Visible to Executable
Source and Path
MarketplaceRelativePath rejects absolute paths, parent-directory traversal, and out-of-bounds joins. Remote entries can be pinned by git ref or SHA.
Enabled State
Discovery config maintains enabled and disabled lists. Project- or user-scoped entries default to the disabled list; CLI override and config-path entries default to enabled. Users can adjust explicitly.
Execution Trust
Project plugins are authorized by canonical plugin root at single-plugin granularity. Trust records are written to ~/.grok/trusted-plugins.
Component Matrix for Untrusted Plugins
Path resolution failure treated as untrusted
match dunce::canonicalize(plugin_root) {
Ok(path) => self.trusted.contains(&path),
Err(_) => false,
}Source affects initial trust determination
CLI override and user scope are marked trusted in the source; project scope requires explicit trust. Config paths under the user home may be auto-trusted; other locations still require authorization.
crates/codegen/xai-grok-agent/src/plugins/trust.rs · discovery.rsInstaller Preserves Provenance; Catalog Makes No Scale Guarantees
Install records are traceable
Local Marketplace installs via managed install storage; remote entries are located via Git URL, ref, SHA, and subdir. InstallRegistry writes a MarketplaceProvenance.
Source proves the mechanism, not the ecosystem scale
The current code can prove the official source constant, multiple sources, catalog indexing, search, and install flow. It cannot prove plugin count, active authors, audit coverage, or growth rate — this page makes no such inferences.
xai-grok-plugin-marketplace/src/lib.rs · types.rsLab: Build a Threat Model for a Plugin
Deliverable
Plugin skeleton and threat table
- Create a minimal plugin directory with a skill, hook, and MCP config; write the manifest.
- Create a Marketplace index entry and explain how the filesystem fallback works when the index is missing.
- List the four states — discoverable, installed, enabled, trusted — and diagram the allowed transitions.
- Design three attacks: path traversal, malicious project hook, same-name plugin hijacking; find the source-level guardrails for each.
- Identify one remaining risk and propose a solution: pre-install review, SHA pinning, or least privilege.
The core value of a plugin system is shaped equally by its capability surface and its trust surface. The catalog solves discovery, the installer handles persistence, and the runtime trust gate decides which components enter the execution chain.
Source snapshot note: This page is based on the local grok-build-main repository's xai-grok-plugin-marketplace and xai-grok-agent::plugins. The directory tree merges source-code defaults for teaching clarity; source precedence, path constraints, enable config, and trust behavior follow source semantics.
Why “Marketplace： Discovery, Installation, and Execution Layers” depends on the operation
“A catalog can surface plugins, an installer can copy or clone them, and the runtime still needs to evaluate enabled status and trust.” makes the structure concrete. The useful comparison is not which name sounds more advanced, but how the data is arranged and how far the most common operation has to travel.
Read a structure through access and change
“Explain index-first, filesystem fallback, manifest parsing, and source precedence” exposes a trade-off that is easy to miss: reading by position, looking up by key, adding at either end, inserting in the middle, and traversing relationships do not favor the same organization. A structure that is fast for one operation is not automatically fast for all of them.
- Create a minimal plugin directory with a skill, hook, and MCP config; write the manifest
- Create a Marketplace index entry and explain how the filesystem fallback works when the index is missing
- List the four states — discoverable, installed, enabled, trusted — and diagram the allowed transitions
Count scale and update frequency together
Use “The core value of a plugin system is shaped equally by its capability surface and its trust surface.” as a boundary check. Write down the data size, the dominant operation, and the latency you can accept before deciding whether an AI-generated structure actually fits.
From “Marketplace： Discovery, Installation, and Execution Layers” to “Reconstruct the Discovery Chain”
“Marketplace： Discovery, Installation, and Execution Layers” grounds the problem in “A catalog can surface plugins, an installer can copy or clone them, and the runtime still needs to evaluate enabled status and trust. Only by separating these three layers can you see the real security boundari…”. “Reconstruct the Discovery Chain” then moves it toward “Explain index-first, filesystem fallback, manifest parsing, and source precedence”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
When you meet a new data structure, do not begin by memorizing its definition. Write down the most frequent operation, estimate scale and update behavior, and check whether the structure satisfies all three conditions.
- “Marketplace： Discovery, Installation, and Execution Layers”: A catalog can surface plugins, an installer can copy or clone them, and the runtime still needs to evaluate enabled status and trust. Only by separating these three layers can you see the real security boundari…
- “Reconstruct the Discovery Chain”: Explain index-first, filesystem fallback, manifest parsing, and source precedence
- “The closing point”: Identify one remaining risk and propose a solution: pre-install review, SHA pinning, or least privilege
The final “The closing point” brings the discussion to “Identify one remaining risk and propose a solution: pre-install review, SHA pinning, or least privilege”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.