Claude Code plugins a risk to local ecosystem?
Posted by dtdisapointingresult@reddit | LocalLLaMA | View on Reddit | 5 comments
There's an increasingly popular way to ship complex extensions for agentic work, that is specific to Claude Code, which is Code plugins. For example here's deep-wiki by Microsoft, a plugin to create a wiki from analyzing your project's repo. There's a lot in there. It's far more powerful than a skill, it can let the user do manual activation via slash commands (/deep-wiki:generate, /deek-wiki:ask, etc), it can spawns different subagent profiles depending on the task requested, plus whatever else Anthropic comes up with later on.
TLDR of plugins (LLM generated): A skill is a single capability: one SKILL.md file with a name, a description, and a prompt body that the model auto-invokes when the description matches the user's request. A plugin is a distribution unit — a directory with a plugin.json manifest that bundles together multiple capabilities of different kinds: skills (auto-invoked), slash commands (explicitly invoked under a /plugin-name:command namespace), and subagents (spawned with their own context). So skills and plugins aren't alternatives at the same level — a plugin is the package, and skills are one of several things a plugin can contain alongside commands and agents. You can ship a lone skill without a plugin, but you can't ship a slash command or a namespaced bundle of capabilities without one.
Plugins allow some pretty heavy work, for example deep-wiki is 3.5k LOC. This is a huge amount of guidance/prompts and custom paths packed in a single cohesive bundle.
But plugins are not an open standard like Skills. And it's not something agentic apps can easily implement. Most agentic apps don't support subagents or custom slash commands at the moment, let alone have them be Code plugin compatible.
Do you think this is something that will allow Claude Code to completely pull ahead of the competition (moreso) due to an implicit form of vendor lock-in, as power users focus on Code plugins?
(By the way, I did some research, and among open-source agents, AFAIK only Qwen Code supports installing Code plugins from the Claude marketplace. Alibaba get it. But that's just 1 app and not one I see discussed much.)
One-Button-8795@reddit
the really important thing here is that plugins aren’t just “extensions”
they’re becoming:
that’s a MUCH bigger shift than simple skills/prompts
and yeah vendor lock-in absolutely becomes real once teams start building:
because migrating isn’t “switch model”
it becomes:
“rebuild an entire operational layer”
which is exactly how platforms historically consolidate power over time
PixelSage-001@reddit
The security model of third-party plugins in developer CLI tools is a major concern. If a plugin has access to run shell commands in the background without explicit approvals, it's an easy vector for credential stealing or dependency confusion attacks.
We need sandboxed runtimes for these plugins where their file read/write permissions are scoped strictly to the project workspace and cannot touch environmental configurations.
NNN_Throwaway2@reddit
This doesn't seem hard to implement.
laul_pogan@reddit
The format itself isn't where the lock-in lives. Plugin files are markdown prompts plus a JSON manifest; any agent that exposes the same tool surface (shell exec, file read/write, task spawning) can consume them identically, which is exactly what Qwen Code is doing. The real moat is the tool set and billing model, not the plugin spec. If you roll your own skills locally, you own the prompt files and can port them to any compatible runner. The supply chain point is the more serious concern though: a subagent with
Bashaccess runs arbitrary shell by design, so auditing a third-party plugin before installing is the same diligence you'd apply to any npm package with a postinstall script.o0genesis0o@reddit
Does not seem more powerful than pi's extension ability.