No way for a user to allow third-party channel plugins for inbound notifications

Second reporter, different use case, same wall.

I build Claudictive, an Overwolf in-game overlay that lets developers keep talking to their existing Claude Code session while they are in a game. Channels is the only documented mechanism that can push a message into an already-running local session and relay a tool-permission verdict back, so it is the natural transport for what we do. The allowlist is what stops us shipping it.

The specific problem for a desktop app, beyond what is already described here: our users are not developers of our plugin, they are people who installed an app from the Overwolf store. Neither available path works for them.

• --dangerously-load-development-channels shows a full-screen warning dialog. Asking every user of a consumer app to click through a screen that says "dangerously" is not something I am willing to ship, and it would be reasonable for them to refuse.
• The curated allowlist is documented as requiring an Anthropic partner contact to coordinate an official-marketplace listing. That is not a path an independent developer can self-serve, and the community-marketplace submission form does not add you to the channel allowlist.

So the current state is that a third-party integration either ships a scary warning to end users or does not ship. Both of the proposals in this issue would resolve it for us, and the first-use consent prompt in particular seems right: it is the same trust model as MCP server approval, which users already understand.

One point in favour of a per-plugin consent prompt over a settings key: a settings key is invisible to the user, whereas the security note in the Channels docs is serious and worth surfacing at the moment of decision. "An ungated channel is a prompt injection vector" and anyone who can reply can approve tool use. A consent prompt that states plainly what the channel can do would be better security than an allowlist that users cannot participate in at all, because today the workaround is a blanket dangerous flag that disables the distinction entirely.

Environment: CLI 2.1.220, Windows 11, personal Max plan.

Update from my side, almost three weeks in.

The fork is public now: https://github.com/Ashr4f/claude-discord-sessions. I also submitted it to the community marketplace on July 30 and it is still pending review. But as far as I can tell those two processes never meet: even if the listing gets approved, the catalog does not put a plugin on the channels allowlist. So anyone who installs it gets a bot that can post, create channels and show permission buttons, but never hears a single reply.

Meanwhile the plugin kept growing (per-session channels, permission prompts as buttons, a watcher that wakes a session when someone writes in its channel) and people around me actually run it daily. The only way that works today is ugly: install the official discord plugin, then overwrite its files in the plugin cache with mine, so Claude Code keeps treating it as the official one. The allowlist does not prevent that at all. It only blocks the clean path and leaves the spoofing path as the one that works, which I doubt is the intent.

I will adjust whatever is needed on my side (consent prompt, scopes, metadata) if there is any path to enrollment.

@Odiph your case is worse than mine. I can ask a developer to click through a warning screen. You cannot ask someone who installed an app from a store to click through one that says "dangerously".

Something useful came out of #71792 this week: the dev flag is not broken. It works once you accept the "Loading development channels" dialog in an interactive terminal, and it silently does nothing when there is no terminal to show that dialog in, which is why several of us read it as a registration bug. So the plumbing is fine. What is missing is still exactly what this issue asks for: a way for the user to allow one plugin, once, without the word "dangerously" in it.

Four weeks on my side. The fork runs here every day, still through the ugly path: install the official discord plugin, then overwrite its files in the plugin cache so Claude Code keeps treating it as the official one. The allowlist does not stop that. It only stops the clean path.

Is there any enrollment path at all for a plugin that is not on the official marketplace? If the answer is no, saying so plainly would help, because right now the docs point at a partner contact and the community marketplace form does not touch the allowlist. If there is one, tell me what you need (consent prompt, scopes, metadata) and I will do the work on my side.

One more measurement, because it closes the last door: allowedChannelPlugins in a user's own ~/.claude/settings.json is ignored. 2.1.234, personal Max plan, official discord plugin disabled so only one channel server was loaded, launched with --channels plugin:discord-sessions@claude-discord-sessions and no dev flag:

MCP server "plugin:discord-sessions:discord": Channel notifications skipped:
plugin discord-sessions@claude-discord-sessions is not on the approved channels allowlist
(use --dangerously-load-development-channels for local dev)

That is consistent with the docs, which put allowedChannelPlugins under Team and Enterprise controls. So the full picture for a third-party channel plugin today:

• Team or Enterprise: an admin can allow it, works, no flag.
• Personal plan: nothing. The dev flag with its warning screen every session, or overwrite the official plugin's files in the cache so Claude Code thinks it is the official one.

The person paying for a personal plan is the one with no way to say yes, and the workaround available to them is the one that defeats the allowlist entirely. That asymmetry is the whole issue.