Allow individual users to extend channels allowlist for third-party plugin marketplaces

Resolved 💬 2 comments Opened Apr 14, 2026 by dastanko Closed Apr 14, 2026

Summary

As an individual Max subscriber running a self-hosted plugin marketplace, I have to dismiss a --dangerously-load-development-channels confirmation dialog on every single launch of Claude Code, with no way to persistently allowlist my own marketplace. The same primitive is available to team/enterprise users via policySettings.allowedChannelPlugins in managed-settings.json. There's no technical reason individual paying users should be excluded.

Background

I maintain a Telegram bridge plugin that lets me drive Claude Code from my phone. The official telegram@claude-plugins-official ships without OpenAI Whisper voice transcription, so I patched it locally. Plugin auto-updates wiped that patch three times in two months — a known problem with locally-modified plugins under ~/.claude/plugins/cache/.

To escape that maintenance loop, I forked the plugin into my own marketplace dastanko/claude-plugins, baked Whisper into server.ts, and added it via /plugin marketplace add. The plugin runs cleanly from ~/.claude/plugins/marketplaces/dastanko-plugins/plugins/telegram/ — except for one persistent friction.

The friction

Because my marketplace isn't in Anthropic's tengu_harbor_ledger (the channels allowlist fetched via GrowthBook), normal --channels registration silently drops my plugin's channel notifications:

plugin telegram@dastanko-plugins is not on the approved channels allowlist
(use --dangerously-load-development-channels for local dev)

Switching to --dangerously-load-development-channels makes channels work, but DevChannelsDialog now mounts on every launch:

WARNING: Loading development channels

--dangerously-load-development-channels is for local channel development only.
Do not use this option to run channels you have downloaded off the internet.

Please use --channels to run a list of approved channels.

Channels: plugin:telegram@dastanko-plugins

  ❯ 1. I am using this for local development
    2. Exit

No "remember this choice" option. No settings.json key to acknowledge a specific marketplace. No per-channel trust state. I press 1 every time I start Claude Code, indefinitely.

Why this is asymmetric

Looking at the registration check (N9$ in the bundled CLI):

let K = T7();                                     // user tier
let _ = K === "team" || K === "enterprise";
let A = _ ? T8("policySettings") : void 0;
// ...
if (f.kind === "plugin" && !f.dev) {
  let { entries: Y, source: O } = A56(K, A?.allowedChannelPlugins);
  // ...
}

And A56:

function A56(H, $) {
  if ((H === "team" || H === "enterprise") && $)
    return { entries: $, source: "org" };
  return { entries: Cs$(), source: "ledger" };  // ← individuals: GrowthBook only
}

Team/enterprise admins can populate policySettings.allowedChannelPlugins in managed-settings.json and have their plugins pass the allowlist check natively — no dev flag, no dialog. Individual users have no equivalent path. The only escape is the dev flag, which itself triggers the unconditional warning that has no persist-choice option.

What would solve this (any one)

  1. Honor allowedChannelPlugins in user ~/.claude/settings.json for individual users, scoped to that user's own machine. They already control what they install via enabledPlugins and extraKnownMarketplaces; adding one more key is consistent with the existing trust model.
  1. "Trust this marketplace" persistence in DevChannelsDialog: add a third option that writes a marker into settings.json so the dialog skips on subsequent launches for that same plugin@marketplace pair.
  1. Treat extraKnownMarketplaces as a trust signal: if the user has explicitly added a marketplace via /plugin marketplace add, that's consent — let plugins from it use channels without the dev flag.

Why I'm filing this

I pay for Max. I've already invested in forking and maintaining my own marketplace specifically to escape an upstream maintenance loop. The current behavior pushes me toward "binary patcher that re-applies on every Claude Code auto-update" as the only way to make this stop — which is exactly the maintenance burden I was escaping. Individual paying users deserve the same primitive team/enterprise admins have, just scoped to their own machine.

Environment

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗