On 7 November 2026, at around one in the morning Bangkok time, the official plugin directory for Claude and Claude Code rejected a new version of IT Reelsmaker, my plugin for editing vertical videos. The reason given wasn’t a bug in the code but the mere fact that there is code. The directory now accepts files other than Markdown, text, JSON, YAML and images only from Verified organisations. The same goes for scripts. Anthropic decides itself who gets this status, and, as the developer portal puts it, you can’t ask for it for now: “there’s no way to ask to become one yet”.
For a plugin that cuts video, adds subtitles and renders graphics on the user’s computer, this means one thing: while the rule stands, we can’t release a new version through the directory. Below: how we got here, what we know about the rule and what to do if you also have a plugin with code. I keep facts and our conclusions clearly apart: Anthropic hasn’t announced the reason for the rule or any timelines.
What exactly the directory bans
The rejection came with the code LOCAL_CODE_FILE_TYPE. The portal asks you to remove every file that isn’t Markdown, text, JSON, YAML or an image in PNG, JPEG, GIF, WebP or ICO format. Files that start with #! are rejected separately: with this line a script tells the system what to run it with, and the file extension no longer saves you. The licence, README, .gitignore and icon can stay.
IT Reelsmaker has 109 files, and 71 of them are code: 39 Python scripts (transcription, cutting pauses and retakes, sound) and 32 TypeScript files in the Remotion kit that draws the graphics. Without them the plugin turns into instructions without tools. The rejection has nothing to do with the latest commit: in version 1.22.3 we only split one large file into modules. The rule doesn’t look at what the code does. From authors without Verified, the directory takes no code files at all.
The portal explains Verified in one sentence: Anthropic knows your organisation is a real company. And it immediately adds that this is about who you are, not a review of your plugins.
A month for a green check
To see what this rejection cost, you need the timeline. IT Reelsmaker started on 18 September as a private skill in my working folder. On 2 October we opened the repository and submitted the plugin to the directory, and on 6 October an Anthropic reviewer published version 1.6.1. We wrote about the plugin itself in detail in a separate article. On 7 October we requested publication of 1.7.1, and that request is still sitting with the reviewer. While it’s pending, the portal won’t let you request another version: the “Publish update” buttons are inactive, and there’s no way to cancel the request. The directory has no auto-publishing: no version goes out without an Anthropic reviewer.
After 1.6.1, automated checks passed 19 versions, up to 1.22.2. None of them reached the directory’s users. We spent most of that time cleaning up the plugin for the scanner. It sent the plugin for manual review flagged “Uses a credential from the user’s machine” whenever it found both reading of settings and sending of data in the plugin; apparently it saw this as passing a key along. It demanded an explanation for an image that a text file merely mentioned by name. It reacted to individual words, export, set, env, ws, host, and we renamed them by the dozen: export became stage, set became change.
On principle, we didn’t try to trick the scanner. No string gluing like "ex" + "port", only honest changes after which the code does the same thing and the scanner no longer finds anything to pick on. By versions 1.22.0–1.22.2 the check showed “Validation passed” and zero warnings, and on the evening of 6 November 1.22.2 got the mark “Meets directory policy”. By then we had 144 commits, 37 releases and 577 automated tests on Windows, macOS and Linux behind us.
The new rule had already surfaced by then. On 7 November at around 00:50, a manual check of the branch showed it as a note, “This isn’t refused yet”: not a rejection for now. At around one in the morning, the scheduled check after the merge rejected 1.22.3.
What the directory’s users were left with
The portal’s numbers as of 5 November: 12,793 installs, 4,301 active accounts over 28 days, 8,736 uses over 30 days, 89th place in the directory. 52.6% of new accounts come back to the plugin within four weeks; load errors are 0% across 1.9 million loads. Almost two thirds of installs come from Claude.ai (65.8%), and the rest is split evenly between Claude Code (17.2%) and Cowork (17%).
The directory hands all these people version 1.6.1 from 6 October. Since 4 November the portal has marked it as “no longer meets directory policy”, under the very same credential rule we fixed in 1.22.0, and in the same breath says it continues to be distributed. It also still has a nasty bug: on Windows, every render left a copy of the Remotion project in the temp folder and didn’t delete it. Over a month of active editing, these copies can take up tens of gigabytes. We fixed this in 1.16.0, but the fix never reached the directory’s users.
It’s a strange picture. The old version stays in the directory with a note that it doesn’t meet the policy. Version 1.22.2 passed every check on the evening of 6 November but has still not been published, and the directory has already rejected the next one.
Two more of our plugins under the same rule
At the end of October we submitted two more plugins to the directory: holographic-memory, a shared local memory for Claude Code and Codex, and agent-dreaming, its nightly review. More about them in a separate article. Neither has appeared in the directory.
agent-dreaming is the most telling case, because it has no code at all. In the submitted versions, the plugin consisted of four files: a manifest, an icon, a Markdown skill and hooks.json with two session-start hooks. The first reminds the agent how many memory questions are waiting to be reviewed; the second launches, in the background, a nightly pass of the dreamem program, which is installed separately. Versions before 0.7.0 got the code REACH_UNKNOWN: the skill description was invalid YAML because of a colon inside a string. Claude Code forgives that; the directory doesn’t. On 5 November the fixed 0.7.1, followed by 0.7.2, passed the automated check with no warnings and joined the queue for a reviewer. The same day 0.7.2 got a note: later, command hooks will only be accepted from Verified organisations, and a version that hasn’t gone out by then will be reassessed. Around 6 November it was rejected, without a new scan, under the new rule. A version that passed the checks under the old rules became ineligible while it waited for a reviewer.
There were two options: move the hooks into the program itself, so that it writes them into Claude Code’s settings on install, or remove the hooks altogether. The first is easy to mistake for getting round the rule, so on 7 November we chose the second. Now the plugin is three files: a manifest, an icon and a skill, with no code and no hooks. The nightly pass is launched by a daily operating-system task, set up by the command dreamem install claude-code. On Windows that’s Task Scheduler, which catches up on a missed run after sleep; on macOS and Linux the command produces ready-made files for launchd or systemd. The reminder about questions at the start of a session is gone. The /agent-dreaming:dream skill works as before and, if the nightly pass hasn’t run for a while, offers to set up the task, and sets it up only after the person says “yes”. Codex and Antigravity keep their hooks: the program writes them into those agents’ settings, and the Claude directory rule doesn’t apply to them.
Version 0.8.0 without hooks passed the automated check and the policy check with no warnings, and the application went back to a reviewer. There’s no live version in the directory yet. Along the way the scanner managed to trip up once more: in the first version of the skill, it took the label pass starts from: next to a link to the documentation for reading a password. Once the label became nightly run:, the check passed cleanly.
For holographic-memory, every version from 0.9.0 to 0.11.0 went to manual review. Without code this plugin can’t keep the memory running by itself. Facts sit in a local SQLite database, one hook adds the facts relevant to each message into the conversation before it’s sent, a second does the same at the start of a session, and a local MCP server (the program through which the agent reaches the memory) gives it 23 tools. The engine is 37 Python files, alongside 89 test files and dictionaries for 18 languages.
On the afternoon of 5 November the portal showed two “This isn’t refused yet” notes on 0.11.0, about command hooks and local MCP servers, and on 6 November they turned into a rejection. The portal adds that changing the hook type won’t help, and an MCP server can stay only if Claude Code connects to it at a public address. That doesn’t work for memory that is meant to live on the user’s computer. The code-files rule didn’t catch 0.11.0: it was scanned on 5 November. The next version will probably be rejected for the Python too, but that’s our conclusion, not the portal’s answer.
The scanner’s findings on holographic-memory show well how it reads. Among them were the test files for the secrets filter, and a separate false “Uses a credential from the user’s machine” signal came from the German word “Pass” in a dictionary plus an address in the plugin folder. In our tests even a local 127.0.0.1 was enough. We’ve decided not to disguise the dictionaries and tests for the scanner. What we’re discussing is something else: keep the full plugin in our own marketplace on GitHub, and give the directory a reference edition without code that installs nothing by itself. That isn’t settled either, and before submitting such an edition we want to ask Anthropic whether the scheme is acceptable.
We’re not alone
I found no discussions on Reddit or Hacker News, but on GitHub the picture comes together quickly. On 6 November, issue #7024 appeared in claude-plugins-official, Anthropic’s official plugin repository. The author of the ThreadPage plugin writes that from around 5 November the directory has been rejecting command hooks and local MCP servers from organisations without Verified, the documentation doesn’t mention the rule, and there’s nowhere to apply for the status. According to him, other projects had run into the same rule that week and removed the hooks their plugins relied on.
The same day three more people replied under the issue. Desktop Steward got a rejection for a local MCP server, even though the same author’s remote connector is already approved and listed in the directory. The author of Mycelium writes that his plugin consists mostly of command hooks and removing them isn’t an option, and he hasn’t found how a one-person project can become Verified. The fan mod Cozy Clawd was rejected with the wording “Mods accepted only from Verified organizations”; its authors write that it isn’t urgent for them, as the mod can be installed from their own marketplace. As of 7 November there’s no answer from Anthropic in the issue.
On 7 November the author of AgenticSeal got a rejection under three rules of the same family at once: LOCAL_CODE_BIN for files in the bin/ folder, LOCAL_CODE_FILE_TYPE, the same code we got, and LOCAL_CODE_FRONTMATTER_KEY for keys in the frontmatter of skills and agents outside an allowed list that the portal doesn’t show. In the same place he lists three more authors who got these three codes a day earlier. Each of them is now releasing a second edition of their plugin for the directory, in Markdown only.
Some are restructuring in advance. In ai-software-factory a command in a hook was replaced with a prompt-based check; in pyvar only name and description were left in the skills’ frontmatter.
Put the authors’ reports together, and the restrictions have hit command hooks, local MCP servers, mods, the bin/ folder, frontmatter keys and, finally, any code files. At first the portal showed them as a “not a rejection yet” warning, and from roughly 5–7 November authors started getting rejections.
What’s been said officially
Almost nothing. The pages on publishing to the directory and the pre-submission checklist, and the directory policy, have no “code only from Verified” rule. The checklist, if anything, assumes plugins do contain code: it asks for readable source rather than minified, and sends to a reviewer whatever the scanner couldn’t read. Even the lists of file types don’t match: under the checklist an .ico file goes to manual review, while in the new rejection ICO is among the allowed types.
On the status itself, the documentation says there’s no separate application for Verified and that Anthropic decides during review. It’s only described for MCP connectors, and there it says plainly that Verified isn’t a security audit. We found no announcement of the new rule on these pages, no dates for the policy change and no timeline for when applications will open. The only address for the directory team in the documentation is directory@anthropic.com.
Our conclusions, not facts
What follows is what we think, not what Anthropic has announced.
The logic of the rule is understandable. A plugin with code runs that code on the user’s computer, inside their Claude session. The scanner does read such code, but over a month we saw clearly how crudely: it catches words, not intentions. Checking the author is easier than checking every line: if a well-known company stands behind a plugin, it has something to lose. Perhaps Anthropic reasoned the same way. But officially no reason has been given.
What stings is something else. The rule appeared with no announcement in the documentation and no path to the status: you can’t apply, you can’t find out the criteria, you can’t even cancel a stuck publication request. For a company with lawyers that’s an inconvenience. For a solo developer it’s a closed door. If the rule stays, authors without Verified will apparently have to keep lightweight versions in the directory, instructions and skills without scripts, hooks or local servers, and distribute everything that runs on the user’s computer outside the directory.
When Verified will become available, and whether it will at all, is unknown.
What we’re doing
On 7 November I wrote to directory@anthropic.com. We’re asking for two things: to explain how to become Verified and whether we can get in the queue in advance, and to release at least 1.22.2 instead of the month-old request for 1.7.1. That would give everyone already using the plugin a version that cleans up its temp files and passed the directory policy before the new rule. No answer yet.
We’re not new to plugin catalogues: the Hermes Agent plugin catalogue has four of our plugins, hermes-cron, hermes-dreaming, hermes-field-notes and holographic. There, publication goes through an open pull request in the Hermes repository: you can see who accepted it and when.
How to install a Claude Code plugin from GitHub
A plugin that isn’t in the directory, or is stuck in review, can be installed from the author’s marketplace on GitHub. It’s an ordinary repository that Claude Code connects with one command: first you add the marketplace, then you install the plugin from it by name. That’s also how you get the latest version of IT Reelsmaker; it appears in our marketplace on release day:
claude plugin marketplace add https://github.com/itpartypattaya/reels-montage.git
claude plugin install it-reelsmaker@itpartyIf you installed the plugin from the Claude directory and edit on Windows, the marketplace version matters especially: it fixes the temp folder that otherwise grows from render to render. And remember that installing from someone else’s marketplace is the same as running someone else’s code, only without the directory’s checks: install plugins from authors you trust, and take a look at the repository before connecting it.
What to do if you’re the author of a plugin with code
Open the Versions tab in the developer portal. If the latest check has a “This isn’t refused yet” note, the next version will most likely be rejected.
From there, there are only compromises. You can split the plugin into two editions: Markdown skills for the directory, the full one in your own marketplace. The authors from the AgenticSeal discussion are already doing this. You can leave the old version in the directory and distribute updates through your own marketplace, as we’re doing now. You can rewrite as prompts whatever lends itself to that, the way ai-software-factory replaced a hook with a prompt-based check. And it’s worth writing to directory@anthropic.com: the documentation gives no other channel to the directory team.
How to get a plugin to a green check
A month with the scanner left us with a working method. While the rule stands, it will be useful to Verified organisations whose plugins keep their code, and to anyone preparing a code-free edition for the directory: the scanner reads Markdown too. Keep two things in mind. These techniques won’t lift a rejection under the Verified rule. And a green check isn’t publication yet: a reviewer still releases the version.
Check a branch without submitting anything. The developer portal has a “Submit new” form, under “Plugin bundle”: fields for the repository, the plugin path and the branch, and a “Validate” button. It runs the same seven checks as a real submission but sends nothing. The working loop is simple: make a change, push to a temporary branch, click “Validate”, compare with the previous report. Enter the temporary branch only in this form: the “Tracked branch or tag” field in a published plugin’s settings determines where the directory takes new versions from. If the branch name contains /, it’s more reliable to fill in the three fields separately than to paste a link. And check that the report is for the right commit: it has a line like branch @ sha.
The scanner catches words, not behaviour. The most stubborn trigger for manual review is “Uses a credential from the user’s machine”, code MCP_FORWARDS_CREDENTIAL_ENV. It’s triggered when the plugin contains something the scanner took for reading a secret and something it took for sending data, even if these are different, completely unrelated files. In our checks, removing one of the two findings was enough. It’s easier to hunt down the false “reading”: links in the documentation and network methods can’t be removed from the project. We found no case, either our own or other authors’, where a reviewer lifted this check themselves.
The scanner treated these as reading a secret: references to environment variables (os.environ, getenv, process.env), words like credential, secret, password, access token, private key and .env, even in a comment or the CHANGELOG, and phrases in Markdown where a trigger word comes right before code: we rewrote “pass text” as “give text”. We precisely confirmed, by bisection, one trigger in code: the string "export" as a command name. It treated links, the word host and the abbreviation ws:, which looks like a websocket address, as sending data. The other findings were worked out from how the report moved on to the next file. That’s a strong sign, but an indirect one.
The portal names only the first matching file. For us that was in path order: CHANGELOG.md, PRIVACY.md, README.md, then skills/…, alphabetically within. Fix one and the next pops up. It’s not a new problem, it’s a queue. If an earlier file isn’t named, the scanner found no trigger for this check in it on that run. When targeted fixes don’t help, bisection comes to the rescue: in a probe branch you remove a suspicious file entirely or replace a single line, and click “Validate” again. Split in whole chunks: the scanner apparently can’t parse a file with Python cut off in the middle and gives a false “clean”.
Check where the text mentions images. The scanner skips images and fonts without reading them as code. But twice we got the manual review “Image or font file that the plugin’s code could run” (UNREAD_ASSET_REFERENCED): the scanner took two things for references to the icon: the mask "@remotion/*" in a string in a diagnostics script and the path to the icon in the CHANGELOG. Moving the icon to another folder didn’t help: the mask matched it there too. You can leave images out of the plugin folder altogether; then only a “No icon” warning remains.
The listing is fixed at submission. The directory takes the links to documentation, support, privacy policy and terms of use at the first submission, and new versions don’t update them: only the name and short description are synced. So the “Unrecognized field” warnings on these fields in plugin.json can be cleared by deleting the fields: the live listing will keep the links. For a new submission you’ll have to enter them again. The directory also takes the icon from the files only at the first save or submission; for a published plugin it’s changed on the Listing tab with the “Replace” button.
Before a release we’ve settled on one sequence. The release linter and claude plugin validate --strict with no errors, tests and CI green on every system. The release branch checked in the “Submit new” form before merging. version bumped in plugin.json, or the update won’t be seen, and a CHANGELOG written without trigger words or paths to your own images. Then the merge into the tracked branch, the “Check for new commits” button and waiting for the scan on the “Versions” tab; it takes minutes, not seconds. To keep triggers from coming back, we added a rule to our own release linter for every pattern we found. And remember that the scanner changes: all of this describes its behaviour in early November 2026.
We covered how to submit a plugin and what the portal checks separately.
