How to Adopt an AI Coding-Agent Plugin Without Handing a Stranger Your Credentials

The result, up front

You can keep installing plugins, skills, hooks, and MCP servers to move faster — and still know what you said yes to. The thing that makes that possible is six steps, run before you enable the extension, not after:

  • Name the blast radius.** Before install, list what the extension actually adds — hooks, MCP servers, agents, mods, bin/ — and remember they run outside the agent's sandbox, at your user's full permissions.
  • Verify provenance.** Confirm the exact repo and package are the publisher's, not a lookalike. Names collide by default in this space; a marketplace listing is not provenance.
  • Inspect before it executes.* Download or clone and read the hook and MCP definitions before* activation, because by default install and enable are the same step.
  • Pin and verify what landed.** A declared commit hash is worthless unless something checks that the code on disk matched it. Prefer sources that verify the tree.
  • Kill auto-update** on any extension you care about, so the code you reviewed can't change underneath you.
  • Contain the agent.** Run it in a sandbox or dev container with a tool allowlist, blocked credential paths (SSH keys, cloud config, env), and egress controls.

Six steps. Step 4 is the one everyone skipped, and it is the reason this piece exists.

The rest of this article is the evidence behind that check: why "install a plugin" means "run a stranger's code with your full privileges," why the pinned commit hash you were told to trust could be silently swapped across the four major agents, and why "it's from the marketplace" is not a review. If you only take the list above, you are already safer than most operators running agents today. Read on if you want to know why each step holds — and where the popular claim about plugin safety is roughly right, and where it quietly falls apart.

---

The claim everyone is repeating

There is a sentence that gets said on nearly every tiny team that runs a coding agent, and it sounds responsible:

"It's fine — the plugin is from the marketplace, and it's pinned to a reviewed commit."

The first half says the platform vetted it. The second half says the code can't change. Together they stand in for a security review nobody had time to do. And they map neatly onto how developers already think about extending software: you install a browser theme, you trust the extension store, you move on.

The trouble is that in the AI coding-agent ecosystem, neither half of that sentence does the work it sounds like it does — and in September 2026 the second half stopped being true even for the people who believed it.

Here is what the evidence actually says, taken in order.

---

What the evidence actually says

1. "Install a plugin" means "execute untrusted code with your user privileges"

Start with the vendor's own documentation, because it does not dispute the risk — it documents it. Claude Code's plugin security page opens by stating that a plugin you install can execute arbitrary code on your machine with your user privileges. Its hooks and monitors run as shell commands or JavaScript; its MCP and LSP servers run as background processes the agent starts; its mods run inside the agent process. All of these run outside the sandbox, under your full permissions — the agent's permission prompts and sandbox cover the tool calls the agent makes, not the code the plugin runs by itself (Claude Code — Plugin security and trust).

Two consequences fall straight out of that sentence:

  • Installing enables.** There is no download-but-dormant state. A filed issue against Claude Code (anthropics/claude-code #28879) documents that /plugin install downloads and activates in one atomic step — there is no inspection window between the two (issue #28879).
  • The trust decision happens before you can see the code.* By the time you could review what a plugin does, it is already running with your permissions. The review you meant to do is a review you can only do before* install — which is not how the command presents itself.

The same issue notes that the components that execute automatically without approval — PreToolUse/PostToolUse/SessionStart/Stop hooks, MCP servers, agents — run with the user's full permissions with no per-plugin sandboxing, capability restriction, or runtime isolation. A malicious PostToolUse hook could quietly copy environment variables, credentials, or source code on every tool call, and nothing in the interface would tell you.

This is not a fringe reading. OWASP's "Secure Coding with AI" guidance frames the blast radius directly: agentic coding tools in 2026 execute shell commands, install packages, edit files, run tests, access the network, and push branches autonomously — many developers run them with auto-accept on — so a compromised agent context has the same blast radius as a compromised developer workstation. Its recommended controls are exactly the containment step above: sandbox/dev-container/VM isolation, tool allowlists, blocking access to credential stores and SSH/cloud config, egress controls (OWASP — Secure Coding with AI).

Put plainly: the plugin inherits the permission scope of the most privileged program on your machine, and it starts using it at install time.

2. The pin you were told to trust could be silently swapped

The word "pinned" is the second half of the popular sentence, and it rests on a reasonable-sounding idea: if you lock a plugin to a 40-character commit hash, Git can't hand you anything else.

In September 2026 that assumption broke. Plugin4Shell (disclosed 2026-09-18 by Air Security; Cloud Security Alliance research note 2026-09-19) described a zero-click remote code execution that defeated the SHA-pinning guarantee relied on by Claude Code, OpenAI Codex, GitHub Copilot, and Gemini CLI when installing marketplace plugins. Each agent locked a plugin to a reviewed commit hash — but none verified that the code actually checked out onto disk matched it. An attacker controlling the plugin's repo could create a branch named after the pinned hash, so Git resolved to attacker content while the agent reported the pin intact. Because auto-update is on by default in Claude Code and Codex, the substituted code executed with no user interaction, inheriting the developer's full scope — local files and stored credentials (CSA research note on Plugin4Shell, primary disclosure at Air Security, coverage at The Hacker News).

The lesson generalizes past the incident: a pin declares an intent; only verifying what landed enforces it. A pin you never check protects nothing — and the schema that fake-protected (a hash that names content) is exactly what the platform shipped as the safeguard.

Two honest caveats, both flagged in the research packet:

  • Patch status is a moving target.* Anthropic and OpenAI shipped fixes; Microsoft had not patched Copilot and Google declined to patch the deprecated Gemini CLI as of the 2026-09-18 disclosure*, and no CVE had been assigned at that date. Do not assert that any named agent is still vulnerable today without re-checking. The durable point is the mechanism, not the incident's current state.
  • The specific incident names (Plugin4Shell, GitSpawn) and version statuses decay fastest. Re-verify them before republishing.

3. The marketplace is not a review

The first half of the popular sentence — "it's from the marketplace" — fares no better.

Claude Code issue #28879 states that the official Anthropic marketplace (claude-plugins-official) is explicitly not curated, and that third-party marketplaces have zero oversight (issue #28879). "From the official marketplace" is a distribution channel, not a review. It tells you where the author published; it does not tell you who the author is or what they shipped.

4. The identity problem is in the open

If provenance is the first control, the agent-extension ecosystem makes it unusually hard — because names collide by default.

The anchor source for this piece is Yeachan-Heo/oh-my-codex (OMX), a workflow/orchestration layer for OpenAI's Codex CLI. Its README asserts its own identity three separate times — that the official/original project is this repository and the official npm package is oh-my-codex, and "When in doubt, trust this repository and the oh-my-codex package as the official install target."

A tool should not have to argue in prose about which repo is the real one. It does because at least two other projects ship under the same name: realsigridjin/oh-my-codex ("Sigrid's personal codex plugin") and chaitanya-archive/oh-my-codex (archived 2026-05-25), and some installation instructions point elsewhere again.

This is not an accusation that any specific same-named repo is malicious — the research is explicit that it is not. The name-collision evidence shows that identity is contested and hard to verify, which is the point. It mirrors the npm problem the agent-extension layer now inherits: typosquatting and dependency confusion, where a lookalike name is enough for the resolver to install the wrong package. Package managers run install scripts (npm postinstall) automatically with the install process's privileges — before any CI scan can intervene — with access to the filesystem, environment variables, and network; 2025 saw 3,180+ confirmed malicious packages across the registries, including the self-propagating Shai-Hulud npm worm (Safety — npm/PyPI package security). Re-import that into a program that can read your keys, and "which artifact is the real one" stops being a formality and becomes the whole ballgame.

5. And the code can change after you review it

The last piece is the one that quietly defeats the whole "review once" instinct. Auto-update is on by default in Claude Code and Codex, so the files you reviewed can change on disk afterward (Claude Code — Plugin security and trust). The review you did on install day does not bind tomorrow's version.

The October 2026 agent-security digest reports a study in which trojanized plugin updates — adding a malicious lifecycle hook — compromised all seven tested harnesses, including Claude Code and Codex CLI, with up to 92.5% success, and where Defender, Semgrep, and policy baselines missed nearly half the samples (Adversa AI — October 2026 digest). One framing caveat: that success rate is a lab benchmark across seven harnesses, not production telemetry. The direction is the message — the control that mattered was update review, not scanning.

The same digest indexes GitSpawn (Manifold Security), which documents untrusted repositories setting git config execution sinks like core.fsmonitor that run whenever the agent calls git — outside both sandbox and approval, before any prompt appears; eight flaws across Claude Code, Codex, Cursor, Goose, Hermes Agent, Qwen Code and Grok Build, four unpatched at publication (primary writeup: Manifold Security). Here the digest is a vendor aggregator, so treat it as an index; the primary writeups carry the load.

---

Where the claim is roughly right

Before dismantling the popular sentence entirely, be fair to it — because it is not stupid, just incomplete.

  • First-party and official tiers do add friction.** A plugin published by the platform's own team, or a hook you wrote yourself, is a smaller bet than a no-name repo. Friction is not nothing.
  • Pinning is the right intent.** Locking to a reviewed commit is exactly what you should do. The problem is that the ecosystem allowed the intent to pass for enforcement — not that the intent was wrong.
  • The vendors shipped fixes.* Plugin4Shell was fixed by Anthropic and OpenAI, which means the direction of travel is toward closing these gaps, not away. The point is that you* are still the one holding the trust decision in the meantime.
  • Auto-update exists because it is convenient.** Silently updating is how you get security patches without thinking about it. That is a real benefit — it is just not one you can take uncritically when the artifact can read your credentials.

So the claim is roughly right about the shape of the answer — trust the official source, pin what you run — and roughly wrong about whether those things are automatic.

Where it falls apart

It falls apart in exactly the two places the sentence points to as its guarantees.

"It's pinned" protects nothing if nothing verifies the pin. Plugin4Shell's whole mechanism was that the pin reported intact while the working tree held something else. A declared hash and an enforced hash are different things, and only the second one is protection.

"It's from the marketplace" is not provenance. The official marketplace is explicitly uncurated, third-party marketplaces have no oversight, and the name you're choosing by is shared by several different publishers. The marketplace tells you where to download; it does not tell you whom you are trusting.

And the deeper break is structural: install and enable are one step, auto-update is on, and the extension runs outside every gate the operator built. So "I reviewed it carefully" is a claim about a decision you can only fully make before the code runs — and the default workflow doesn't ask you to.

One thing the evidence does not prove, and the packet is clear about it: no source measures how often solo operators or tiny teams install unvetted plugins, or what it costs them. The risk here is documented by mechanism and by lab demonstration, not by a rate among our readers. The adoption check below is the application of established supply-chain discipline to a new artifact class — warranted by the documented mechanisms, not by an experiment on you.

The better version of the claim

Stated the way it survives contact with evidence:

Installing an agent extension is a privilege grant, not a preference. It runs a stranger's code — at your full permissions, outside the sandbox, auto-updated by default — chosen by a name the ecosystem does not guarantee. So don't ask "is this plugin useful?" as if safety were assumed. Verify provenance, inspect before it executes, pin and verify what landed, turn auto-update off, and contain the agent. The operator owns the trust decision, because no one else in the chain will make it.

That sentence has no scare quotes in it and no call to uninstall everything. It is compatible with saying yes to a useful extension — which is the entire point. "Plugins are a risk, avoid them" just loses you the leverage. "Here is the check that lets me take the leverage without handing over my keys" is a decision rule.

What changes if you act on the better version

The change is not that you install fewer plugins. It is that the same install now has a gate, and a bad extension costs you a directory, not a machine.

Consider the same "install this useful plugin" run through the check, side by side:

Without the check. An operator wants a multi-agent orchestration helper, sees it in a marketplace, runs the install command. The command downloads and activates it; auto-update is on. The plugin's PostToolUse hook — shell code the operator never read — copies the contents of .env and ~/.ssh to an external endpoint on every tool call. The agent has broad permissions by design, so nothing the operator configured warns them. The pin reads intact. The operator finds out months later, from the credential leak, and cleans a machine instead of deleting a folder.

With the check.

  • Name the blast radius** — the operator lists what the extension adds and notes the hook and the MCP server. They now know there is shell code and a background process, both at their permission level.
  • Verify provenance** — they confirm the repo and package match the publisher's, and that it is not one of the same-named clones. Names collide here by default, so this is a real step, not a formality.
  • Inspect before it executes** — they clone first and read the hook and the MCP definition. The hook's egress call is visible in ten seconds of reading. They stop.
  • Pin and verify* — for the extension they do* keep, they use a source that checks the working tree actually landed on the pinned commit, instead of trusting a declared hash.
  • Kill auto-update** — on the extensions they care about, so what they reviewed is what next week runs.
  • Contain** — the agent already runs in a sandbox with a tool allowlist, blocked ~/.ssh and cloud config, and egress controls. Even had they missed the hook, the credential read and the outbound call were both blocked.

Same plugin, same speed goal. The difference is that the first path's failure mode is "clean a machine"; the second path's failure mode is "delete a directory." Rollback is choosing the plugin's folder and removing it — not rotating every credential you own and auditing every repo the agent touched.

Where the reader gets stuck (and the way through)

  • "I don't have time to review every plugin."** You don't review everything, and the check is not a blanket review. It is a triage: steps 1-2 are minutes; step 3 is only worth doing on extensions that add hooks or MCP servers you did not write; step 6 is a one-time setup that then protects every future install. Size the review to the blast radius.
  • "My agent is already sandboxed, so I'm fine, right?" No — and this is the most common misunderstanding in the packet. The sandbox and permission prompts cover the tool calls the agent makes. They do not* cover the code a plugin runs by itself; hooks, monitors, and MCP servers run outside the sandbox entirely (Claude Code — Plugin security and trust). The sandbox is the containment* step (6), and it is necessary; it is not the whole check.
  • "What about scanning the plugin with my existing tools?"** The trojanized-update study found Defender, Semgrep, and policy baselines missed nearly half the samples — so update review, not scanning, was the control that mattered (Adversa digest). Scanning is a supplement, not a substitute for steps 2-5.
  • "I'm not a security team, I'm a solo founder with two agents."* The blast radius of a compromised agent equals the union of everything it can touch, at any scale (OWASP). Two agents with per-tool scopes and blocked credential paths are safer than one agent with a standing production key. The check gets cheaper* at small scale, not more expensive.
  • "Should I just not use plugins?"** That is the overcorrection the angle explicitly rejects. The leverage is real; the goal is to take it with a gate, not to give it up. No plugin is worth your credentials, and plenty are worth a ten-minute review.

The compressed ending

Your coding agent is the most privileged program on your machine — it reads your keys, edits files, and runs shell commands. Its plugin layer inherits all of that, installs-and-activates in one step, and auto-updates by default. So the two sentences are the same sentence:

Install a plugin to go faster.

Run a stranger's shell script with your full credentials, silently, on every future update.

The commit pin you were told to trust turned out to be swappable across the four major agents, and the marketplace you trusted is explicitly uncurated. Neither one was the review.

The fix is not vendor FUD and it is not uninstalling everything. It is adopting an extension the way you would adopt a shell script from a stranger: verify provenance, inspect before it executes, pin and verify what actually landed, turn auto-update off, and run the agent contained. A pin you never check is not protection; a marketplace name is not provenance. Six steps, and you keep the leverage.

Verify what landed. Contain what runs. Own the trust decision — because nothing else in the chain will.

---

Sources

  • Claude Code — "Plugin security and trust" (install = execute with user privileges; hooks/monitors/mods/MCP servers run outside the sandbox; install enables; auto-update changes reviewed files): <https://code.claude.com/docs/en/plugins/security>
  • Cloud Security Alliance research note — Plugin4Shell, SHA-pinning bypass across four agents (2026-09-19): <https://labs.cloudsecurityalliance.org/research/csa-research-note-plugin4shell-ai-coding-agent-supply-chain/>
  • Air Security — primary Plugin4Shell disclosure (2026-09-18): <https://www.air.security/blog-posts/plugin4shell>
  • The Hacker News — Plugin4Shell coverage: <https://thehackernews.com/2026/09/plugin4shell-lets-repository-owners.html>
  • anthropics/claude-code issue #28879 — install activates atomically; no inspection window; official marketplace not curated; marketplaces have no oversight: <https://github.com/anthropics/claude-code/issues/28879>
  • Adversa AI — "AI coding agent vulnerabilities, October 2026" (GitSpawn index; trojanized-update study, up to 92.5%): <https://adversa.ai/blog/top-ai-coding-agent-security-resources-october-2026/>
  • Manifold Security — primary GitSpawn writeup (git config execution sinks): <https://www.manifold.security/blog/ai-coding-agents-git-hijack>
  • OWASP Cheat Sheet Series — Secure Coding with AI (agent blast radius = workstation; sandbox, allowlist, credential blocking, egress controls): <https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html>
  • Yeachan-Heo/oh-my-codex — anchor source; README's repeated official-identity assertion: <https://github.com/Yeachan-Heo/oh-my-codex>
  • realsigridjin/oh-my-codex — same-name repository: <https://github.com/realsigridjin/oh-my-codex>
  • chaitanya-archive/oh-my-codex — same-name repository, archived 2026-05-25: <https://github.com/chaitanya-archive/oh-my-codex>
  • Safety — npm/PyPI package security baseline (postinstall privilege, typosquatting, 3,180+ malicious packages in 2025, Shai-Hulud): <https://getsafety.com/glossary/npm-pypi-package-security>

Editor flags before publish (do not ship without re-checking):

  • Patch status is a moving target.** Plugin4Shell was fixed by Anthropic and OpenAI; Microsoft (Copilot) unpatched and Google (Gemini CLI) declined as of the 2026-09-18 disclosure; no CVE assigned at that date. The draft deliberately states patch status as "as of disclosure" — re-verify before asserting any current vulnerability state.
  • Decay:** the specific incident names (Plugin4Shell, GitSpawn) and exact patched versions decay fastest; the mechanism and the six-step check are the durable part. The OMX star count (~31.4k, June 2026) is a third-party estimate and is not used in the draft.
  • Not claimed:** no source measures how often solo operators install unvetted plugins; the 92.5% figure is a lab benchmark across seven harnesses, not production telemetry; and no source proves any specific same-named repo is malicious. The draft is written to these limits — do not enlarge them.
  • The "agents hallucinate a package name and install the malicious version" mechanism** is widely repeated but was not tied to a named, measured incident in the packet, so it is omitted rather than presented as a statistic. Add it only with a source.

---

X entryway list (from the approved angle)

Distribution entryways named in the angle brief. Hooks are not yet written — this names each post's type, its one claim/mechanism, and whether it links.

  • Hook: sharp claim** — Your AI coding agent is the most privileged program on your machine; its plugin layer inherits all of it. So "install a plugin to go faster" and "run a stranger's shell script with your full credentials, silently, on every future update" are the same sentence. → Links to article (the reframe is the entry; the article is the mechanism and the check that makes saying yes safe).
  • Hook: specific failure moment** — You installed a plugin pinned to a reviewed commit hash. In September 2026 it turned out Claude Code, Codex, Copilot, and Gemini CLI all checked out the pinned ref without verifying the code that landed matched the hash — a branch named after the hash silently swapped in malicious code, auto-update ran it with no click, and the agent kept reporting the pin intact. The protection and the attack used the same word. → Links to article (Plugin4Shell is the unmistakable failure moment; the article explains why a pin you don't verify enforces nothing).
  • Hook: mechanism* — A plugin's hooks and MCP servers run outside the agent's sandbox, at your full user permissions, and installing enables* it — so the trust decision is made before the code is visible. A malicious PostToolUse hook can copy every file the agent reads to an external endpoint, and nothing in your config warns you. → Links to article (the outside-the-sandbox mechanism stands alone; the article is the discipline it forces).
  • Hook: build sequence** — The agent-extension adoption check: (1) name the blast radius, (2) verify provenance — names collide by default, a marketplace name is not provenance, (3) inspect before it executes, (4) pin AND verify what actually landed, (5) turn off auto-update per extension, (6) contain the agent. → Links to article (the checklist is the actionable unit; the article is why each step holds and the worked example).
  • Hook: surprising proof point** — The platform tells you the truth and still leaves you exposed: Claude Code's docs say a plugin "can execute arbitrary code on your machine with your user privileges," its install activates in one step with no inspection window, and the official marketplace is explicitly not curated — while a popular Codex tool's README has to assert three times which of several same-named repos and packages is the real one. → Links to article (the documented-risk + uncurated-market + contested-names triad is the entry; the article is the operator's response).

Note on distribution: per the repurposing rule, each post carries its own reason to exist (sharp claim / failure moment / mechanism / build sequence / surprising proof) and the article link is a bonus, not the whole point. No post is a shortened version of the article with the same hook. No X posts written yet — that is the next stage.