claude-code - 💡(How to fix) Fix Allow individual users to extend channels allowlist for third-party plugin marketplaces [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#47767Fetched 2026-04-15 06:42:55
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Timeline (top)
labeled ×4closed ×1commented ×1

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.

Root Cause

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:

Fix Action

Fix / Workaround

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/.

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.

Code Example

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

---

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

---

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);
  // ...
}

---

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

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.

  2. "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.

  3. 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

extent analysis

TL;DR

To resolve the issue, consider adding a feature to honor allowedChannelPlugins in the user's ~/.claude/settings.json for individual users or implement a "Trust this marketplace" persistence in the DevChannelsDialog.

Guidance

  • The current implementation only allows team/enterprise users to populate policySettings.allowedChannelPlugins in managed-settings.json, excluding individual users from this functionality.
  • To mitigate the issue, individual users could potentially use the --dangerously-load-development-channels flag, but this triggers a warning dialog on every launch.
  • A possible solution is to add a new key to ~/.claude/settings.json to allow individual users to trust specific marketplaces or plugins, similar to the existing enabledPlugins and extraKnownMarketplaces keys.
  • Another approach could be to treat extraKnownMarketplaces as a trust signal, allowing plugins from explicitly added marketplaces to use channels without the dev flag.

Example

No code snippet is provided as the issue is more related to the functionality and configuration rather than a specific code error.

Notes

The proposed solutions aim to provide individual users with more control over trusted marketplaces and plugins, similar to the functionality available to team/enterprise users. However, the exact implementation details would depend on the specific requirements and constraints of the Claude Code platform.

Recommendation

Apply a workaround by treating extraKnownMarketplaces as a trust signal, allowing plugins from explicitly added marketplaces to use channels without the dev flag, as this seems to be the most straightforward and least invasive solution.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Allow individual users to extend channels allowlist for third-party plugin marketplaces [1 comments, 2 participants]