Your agent has an app store now. The label is one paragraph and a link.

There are 2,282 prebuilt add-ons you can drop into a coding agent right now, and a decent number of them do the exact job somebody was about to quote you four or five figures to build. A NetSuite connector. A Jira and Confluence bridge. A Shopify catalogue assistant that reads products and manages carts. A Slack integration you do not have to stand up yourself. One command, about ten seconds, no ticket, no sprint, nobody to wait on. That is the good news and it is genuinely good. The part that changed this week is quieter: as of Thursday, whatever you switch on in your account installs itself into every terminal you sign into, on every machine. And 2,124 of those 2,282 catalogue listings consist of a name, one paragraph of description, and a link to somebody's repository.

What actually changed this week

Three things landed between Tuesday and Thursday, and they only look like plumbing until you put them next to each other.

On Tuesday, signing in with a Claude account started also asking for access to your claude.ai plugins. A scope change in a login flow. Nobody reads those.

On Thursday, the reason showed up. Version 2.1.275 added syncing of the skills and plugins enabled on your claude.ai account down into terminal sessions signed in with that account. You turn something on once, on a web page, and it is present in the tool on your laptop, your work machine, and whatever cloud session you spin up. There are opt-out settings (syncClaudeAiSkills: false and syncClaudeAiPlugins: false), which tells you the default direction of travel. The default is propagate.

The same release added /plugin install <name> --marketplace <source>, which collapses the old two-step dance (register a catalogue, then install from it) into one command that offers to add the catalogue for you. It also did three things that read like an apology for how the install path used to work: plugins fetched from an npm source are now pulled with npm pack --ignore-scripts and integrity-verified, so a package's install scripts no longer execute on your machine during installation. Passwords and tokens embedded in a marketplace URL stopped appearing in logs, in messages, and in the output of claude plugin marketplace list. And updating a catalogue no longer deletes your local copy of it when the fetch fails.

Read that middle one again, because it is the whole week in one line. Until Thursday, installing a plugin from an npm source could run that package's install scripts on the machine where you keep your work. That is not a scandal, it is how npm has always worked and it is why --ignore-scripts exists. It is worth noticing anyway, because the same seven days that hardened the front door also widened it into a hallway that reaches every device you own.

The shelf is already full

I pulled the public community catalogue directly, because a catalogue is a fact and a vendor's description of a catalogue is a summary. The file is on GitHub, it is about a megabyte and a half of JSON, and here is what is in it.

Two thousand two hundred eighty-two plugins. Published from 1,863 distinct GitHub accounts, which means this is overwhelmingly individual people shipping one thing each, not vendors maintaining product lines. Of those 2,282 entries, 2,274 are pinned to a specific commit, which is real and matters. One hundred fifty-seven carry a category. Thirty-six name an author.

And four of them declare what the plugin actually installs.

Four. Two thousand one hundred twenty-four entries contain nothing but a name, a description, a source URL, and a homepage. The catalogue is a shelf of boxes with the product name printed on the front and nothing on the back.

Now, that is not the end of the story, because the install screen does better than the catalogue does. When you run /plugin and open a plugin's details, the docs say you get a "Will install" section listing the plugin's commands, agents, skills, hooks, and MCP and LSP servers, plus a context cost estimate and a last-updated date. That is a real ingredients label and somebody thought hard about it. But read the next sentence in the same doc: not every plugin provides the data behind those fields, and for plugins from local or custom marketplaces the section may instead say "components will be discovered at installation." Which is to say: in the exact case where you would most want the label, because somebody sent you a link to a catalogue you have never heard of, the label can be blank until after you have said yes.

Why this matters if you are the one building the tools

If you are the ops person who finally stopped filing tickets and started building your own things, this is the first week the economics of that changed in a direction that is not about the model.

Up to now, getting an agent to do a specialized job well meant teaching it. You wrote the instructions, you iterated for an afternoon, you kept a file somewhere, and the knowledge lived on your laptop and in your head. That was the cost of building without engineering: not the code, the context. Every new job started at zero.

Installing is a different economy. Somebody already spent that afternoon. The 99-point audit checklist, the NetSuite field mapping, the way to talk to a particular API without getting rate limited, all of it packages into a folder you install in ten seconds. And with the sync that landed Thursday, you install it once for yourself rather than once per machine, which sounds trivial until you remember that the reason your process never spread past you is that it lived on one computer.

So the honest answer to the weekly question, what can you ship this week that you could not last month, is this: you can stop building the parts somebody else already built, and you can stop re-setting-up your own environment every time you touch a different machine. That is a real week.

There is also a cost tool in there that almost nobody uses. The plugin manager tracks plugins you installed but have not used in at least two weeks across at least ten sessions, and shows a last-used date. Every enabled plugin costs you context on every single turn, whether you use it or not. If you are on a metered subscription and you felt your week get shorter recently, an audit of that list is fifteen minutes with an actual payback.

The honest take

Here is the part the enthusiasm skips.

Anthropic's own documentation is refreshingly blunt about this, more blunt than most of the coverage: "Plugins and marketplaces are highly trusted components that can execute arbitrary code on your machine with your user privileges. Only install plugins and add marketplaces from sources you trust." And elsewhere, on the install screen itself: Anthropic "doesn't control what MCP servers, files, or other software are included in plugins and can't verify that they work as intended."

That is not fine print. That is the vendor telling you, correctly, that the trust decision is yours and there is no one behind it.

Now look at what a plugin is allowed to contain, per the authoring docs. Skills and agents, sure. Hooks, which run commands automatically when events happen. MCP servers, which are the things that touch your Gmail and your CRM. Background monitors that start on their own when the plugin is active, no instruction required. A bin/ directory whose executables are added to the shell's PATH while the plugin is enabled. And a settings.json that can set an agent key, which activates one of the plugin's own agents as the main thread, applying its system prompt, its tool restrictions, and its model. In plain words: a plugin can replace the thing you are talking to.

Notice which one of those Anthropic will not let you distribute through a company's own plugin library on claude.ai: the bin/ directory. You cannot ship executables onto everyone's PATH through the managed channel. Somebody sat in a room and decided that at scale, that specific thing is not okay. It is still okay one person at a time, from a link.

The community catalogue does run automated validation and safety screening, and the SHA pinning is genuinely the right design. But understand what pinning buys and what it does not. It means you get the exact commit that was reviewed, rather than whatever is on the branch today. It does not mean the pin stays still: per the submission docs, CI bumps the pin automatically as the author pushes new commits. Review is an event. Distribution is continuous. Those are not the same shape, and every software marketplace in history has learned that the hard way.

Then add auto-update. Official marketplaces and marketplaces added from claude.ai have auto-update on by default, and Claude Code checks for plugin updates after your session starts with a random delay of up to ten minutes. Third-party marketplaces you add yourself are off by default, which is the right call. So the thing you carefully reviewed in September is not necessarily the thing running in November, and the mechanism that changes it is working exactly as designed.

None of this is specific to one vendor, which is why it is a pattern and not a news item. Codex, Copilot, and every agent framework with an extension directory landed in the same place this year, because extensibility is how a tool stops being a product and becomes a platform. Microsoft's security team wrote the general version of this in June and the framing is the useful one: each action the agent takes is individually legitimate, and the vulnerability lives in the trust boundary between systems rather than inside any one of them. Their guidance is an allowlist of approved publishers and treating tool descriptions as things that require change review. That is enterprise language for a small-shop instinct: know who wrote it, and notice when it changes.

The ceiling this week, stated plainly: the tooling got materially better at telling you what a plugin contains, and materially better at not running strange code during installation, and it still cannot tell you what a plugin intends. There is no permission manifest. A plugin does not declare "I will read your Gmail" the way a phone app has to. The only boundary is your agent's own permission settings, which live per machine, while the install you just approved now arrives account-wide.

A standard you can actually hold

Treat an install like a software purchase, because it is one, and you already know how to do this. Before you type the command, look at who published it and whether that account has any other reason to exist. Open the "Will install" section and read it; if it says components will be discovered at installation, that is your answer about how much you know. Prefer a catalogue with a review pipeline over a link somebody pasted in a Slack thread, and treat "my colleague sent it to me" as a source of a link, not a source of trust. Leave auto-update off for anything you added yourself. And once a quarter, open the not-used-recently list and take things off the shelf, which costs you nothing and buys back context you are paying for on every turn.

Then make the one decision that is new this week, and make it deliberately: whether account-level sync should be on for you at all. It is not a laptop setting. It is a fleet setting, and for the first time you have a fleet.

The last fifteen years of software went the same way, from installing things to subscribing to things to having things arrive. This one arrives with your credentials already in its hand, and the only label on the box is a paragraph the author wrote about themselves.