Channels not available on personal Max plan - --channels ignored

Root Cause Analysis (reverse-engineered from v2.1.80 binary)

I traced the exact channel eligibility check function in the compiled CLI. Here's the de-minified logic:

function checkChannelEligibility(serverName, capabilities, pluginSource) {
  // Gate 1: Server must declare claude/channel capability
  if (!capabilities?.experimental?.["claude/channel"])
    return { action: "skip", kind: "capability",
      reason: "server did not declare claude/channel capability" };

  // Gate 2: Feature flag (tengu_harbor) — FAILS HERE for affected users
  if (!isChannelsEnabled())  // reads Tq("tengu_harbor", false)
    return { action: "skip", kind: "disabled",
      reason: "channels feature is not currently available" };

  // Gate 3: Must have OAuth access token
  if (!getAuth()?.accessToken)
    return { action: "skip", kind: "auth",
      reason: "channels requires claude.ai authentication (run /login)" };

  // Gate 4: Policy settings — ALSO BUGGY
  let K = getManagedSettings("policySettings");
  if (K !== null && K.channelsEnabled !== true)
    return { action: "skip", kind: "policy",
      reason: "channels not enabled by org policy (set channelsEnabled: true in managed settings)" };

  // Gate 5: Server must be in --channels list for this session
  // Gate 6: Plugin marketplace source verification
  // Gate 7: Allowlist check (tengu_harbor_ledger) or --dangerously-load-development-channels
  // ...
  return { action: "register" };
}

Two bugs identified

Bug 1 — Gate 2 (server-side feature flag): isChannelsEnabled() calls Tq("tengu_harbor", false) which reads a server-side GrowthBook feature flag. This flag returns false for multiple users across Max, Teams, and personal plans (see reports in this thread). The flag is controlled server-side — the binary only reads it.

Bug 2 — Gate 4 (client-side logic error): The condition K !== null && K.channelsEnabled !== true treats undefined as disabled. For users whose policySettings object exists but where channelsEnabled was never explicitly set (undefined), this gate also blocks them — even if they get past Gate 2.

Proposed fixes

• Gate 2: Enable the tengu_harbor feature flag for all paying plan users server-side.
• Gate 4: Change K.channelsEnabled !== true → K.channelsEnabled === false so that only an explicit false blocks channels. Missing/undefined should default to allowed.

Why managed-settings.json workaround doesn't help

The reporter tried /Library/Application Support/ClaudeCode/managed-settings.json with {"channelsEnabled": true}. Even if this correctly sets policySettings.channelsEnabled = true (fixing Gate 4), it doesn't matter — the request never reaches Gate 4 because it fails at Gate 2 (the tengu_harbor feature flag).

Display logic reference

// How the warning message is chosen (exact strings from binary):
kind === "disabled" → "Channels are not currently available"
kind === "auth"     → "Channels require claude.ai authentication · run /login"
kind === "policy"   → "Channels are not enabled for your org · have an administrator set channelsEnabled: true in managed settings"

The reporter sees "Channels are not currently available" → confirms kind: "disabled" → confirms Gate 2 (tengu_harbor flag) is the primary blocker.

---

I'm also experiencing this on personal Max plan, macOS. Happy to test patches.

I'm on Team plan, just got similar problem right now, few hours ago still work ok.

Like wise, on team plan and hoping to get access soon.

Additional Root Cause: DISABLE_TELEMETRY blocks ALL feature flag evaluation

The gate analysis above is correct — tengu_harbor is the primary blocker. But there's a deeper issue affecting a second population of users: anyone who disabled telemetry.

The problem

The feature flag reader (AA() / xM() / MjA() in the minified binary) checks Oc() before reading cached flags. Oc() calls Y1H() which calls !PV(). PV() returns true if any of these env vars are set:

function PV() {
  return lH(process.env.CLAUDE_CODE_USE_BEDROCK) ||
         lH(process.env.CLAUDE_CODE_USE_VERTEX) ||
         lH(process.env.CLAUDE_CODE_USE_FOUNDRY) ||
         !!process.env.DISABLE_TELEMETRY ||
         !!process.env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC;
}

When PV() returns true, ALL feature flags default to false, including tengu_harbor. The cached values in ~/.claude.json (cachedGrowthBookFeatures, cachedStatsigGates) are never read.

The evaluation chain

DISABLE_TELEMETRY=1
  → PV() = true
  → Oc() = !PV() = false
  → AA("tengu_harbor", false): if (!Oc()) return false  // shortcircuits, never reads file
  → CoH() = false
  → "channels feature is not currently available"

Proof

# With DISABLE_TELEMETRY=1:
# MCP log: "Channel notifications skipped: channels feature is not currently available"

# With DISABLE_TELEMETRY unset (same binary, same config, same cached flag):
# "Listening for channel messages from: matrix" ✅

The flag tengu_harbor: true was present in cachedGrowthBookFeatures the entire time. The code just couldn't reach it.

Why this matters

DISABLE_TELEMETRY is set by privacy-conscious users (and is even in Claude Code's own documentation as a supported option). It conflates two separate concerns:

1. Telemetry — sending usage data to Anthropic (legitimate privacy concern)
2. Feature evaluation — reading locally cached feature flags (no network traffic, no privacy implication)

Reading cachedGrowthBookFeatures from ~/.claude.json is a local file read. There's no reason to gate it behind telemetry consent. The Oc() check should only gate server-side flag fetches, not cached reads.

Suggested fix

Move the Oc() gate to only block network-based flag evaluation. Cached flag reads in AA() should work regardless of telemetry state:

function AA(H, $) {
  let A = xjH();
  if (A && H in A) return A[H];
  let L = mjH();
  if (L && H in L) return L[H];
  // Remove: if (!Oc()) return $;
  // Instead, only gate the network fetch path
  if ($y.has(H)) return $y.get(H);
  try {
    let D = w$().cachedGrowthBookFeatures?.[H];
    return D !== void 0 ? D : $;
  }
}

Two distinct affected populations

1. Server-side flag not enabled — tengu_harbor not rolled out (the existing analysis)
2. Telemetry disabled — flag may be enabled and cached, but DISABLE_TELEMETRY prevents reading it

Population 2 has no visibility in any error messages. The log says "channels feature is not currently available" with no hint that telemetry settings are the cause.

Discovered by reverse-engineering the v2.1.80 ELF binary on NixOS. Full writeup available.

Same issue here. Linux (Ubuntu 24.04, kernel 6.17.0), Claude Code v2.1.81, telegram@claude-plugins-official v0.0.1.

Setup is fully functional on the plugin side:

• Bot polling healthy, pairing complete, allowlist configured
• Outbound tools (reply, react, edit_message) work perfectly
• notifications/claude/channel fires correctly over stdio
• No DISABLE_TELEMETRY or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC set

Confirmed blocker: tengu_harbor feature flag returning false. Verified via strings on the binary — same gate chain described by @soumikbhatta and @coryzibell above.

Would appreciate being opted in for the flag. Happy to provide debug logs or test fixes.

Environment

• Claude Code v2.1.81
• macOS (Darwin 25.3.0 / Mac Studio)
• Bun 1.3.11
• Personal Max plan

Auth status

{
  "loggedIn": true,
  "authMethod": "claude.ai",
  "apiProvider": "firstParty",
  "apiKeySource": "/login managed key",
  "orgName": "Rich's Individual Org",
  "subscriptionType": null
}

Note: subscriptionType shows null (not "max"), which may be a separate auth bug compounding the tengu_harbor flag issue.

Confirmed not blocked by telemetry

• DISABLE_TELEMETRY — not set
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC — not set

Error seen

--channels ignored (plugin:telegram@claude-plugins-official)
Channels are not currently available

Same behaviour confirmed for discord@claude-plugins-official. Per the root cause analysis above, this is kind: "disabled" → Gate 2 (tengu_harbor flag) is the blocker. Would appreciate being opted in.

+1 — Same issue on Max 20x plan (v2.1.81). Filed our own at #37184. Channels are critical for our multi-session deployment.

Session: Morpheus (ae19) | Task: 6gChXr7Cp3fPP5RG

+1 — Same issue here.

• Claude Code v2.1.81
• macOS Darwin 25.3.0 (Apple Silicon)
• Bun 1.3.11
• Personal Max plan (claude.ai login, chacharoa@gmail.com's Organization)
• DISABLE_TELEMETRY / CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC not set

Confirmed tengu_harbor flag returning false via binary strings inspection. Plugin installs, bot token config, and pairing all complete — blocked solely at Gate 2.

Would appreciate being opted in.

I'm experiencing the same issue on Windows 11 with Claude Code v2.1.81, Claude Max plan.

Setup:

• Plugin: discord@claude-plugins-official (v0.0.1)
• channelsEnabled: true in ~/.claude/settings.json
• DISABLE_TELEMETRY is NOT set
• Bun v1.3.11

Symptoms:

• claude --channels plugin:discord@claude-plugins-official starts and shows "Listening for channel messages from: plugin:discord@claude-plugins-official"
• Discord bot goes online and receives messages (typing indicator appears)
• However, no channel notifications arrive in the session and plugin tools are not registered
• The bot never replies to DMs

This matches the tengu_harbor feature flag issue described here. The MCP server connects and the bot works at the Discord level, but the harness never surfaces notifications.

Environment:

• OS: Windows 11 Pro 10.0.26200
• Claude Code: v2.1.81
• Auth: claude.ai (Max plan, personal account)

--channels silently ignored on Max personal plan — falls through to --print error

Environment:

• Claude Code: 2.1.81 (native + npm)
• OS: macOS (Darwin arm64)
• Node: v24.11.1
• Bun: 1.3.3
• Plan: Max (personal)
• Plugin: discord@claude-plugins-official installed and enabled

Steps to reproduce:

1. Install the Discord plugin:

claude plugin install discord@claude-plugins-official

1. Configure the bot token:

mkdir -p ~/.claude/channels/discord
echo "DISCORD_BOT_TOKEN=<valid_token>" > ~/.claude/channels/discord/.env

1. Launch with --channels:

claude --channels plugin:discord@claude-plugins-official

Expected: Claude Code starts in channels mode, connects to Discord bot.

Actual:
Error: Input must be provided either through stdin or as a prompt argument when using --print

The --channels flag is silently ignored. Claude Code appears to fall through to --print mode parsing, treating the plugin argument as a prompt, then failing because there's no
stdin.

The flag does not appear in claude --help output, suggesting the feature gate is not active for this account.

Also reproduced in Docker (node:22-bookworm, same Claude Code version, non-root user) with identical behavior.

Notes:

• The plugin is correctly installed (claude plugin list shows it enabled)
• The bot token is valid (bot is online in Discord)
• This appears to be a server-side feature flag not yet rolled out to Max personal plans
• No error message indicates that Channels is unavailable — the flag is just silently ignored, which makes debugging very confusing

+1 — Same issue here.

Environment

• Claude Code: v2.1.81 (native binary)
• OS: macOS Darwin 24.6.0 (Apple Silicon)
• Plan: Claude Max (personal, not team/enterprise)
• Plugin: discord@claude-plugins-official v0.0.1 — installed and enabled
• Bot token: configured at ~/.claude/channels/discord/.env
• Auth: claude.ai OAuth login

Telemetry

• DISABLE_TELEMETRY — not set
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC — not set

Symptoms

claude --channels plugin:discord@claude-plugins-official -w discord

Output:

--channels ignored (plugin:discord@claude-plugins-official)
Channels are not currently available

Debugging performed

Independently confirmed the same root cause via strings on the v2.1.81 binary:

function Po_() { return lT("tengu_harbor", false) }

Po_() reads the tengu_harbor GrowthBook feature flag with default false. This is the primary blocker — Gate 2 in @soumikbhatta's analysis. The request never reaches Gate 4 (policy check).

Plugin installation, bot token config, and Discord bot are all functional. Blocked solely at the server-side feature flag.

Would appreciate being opted in for the tengu_harbor flag.

Hitting the same issue on Pro plan. Would appreciate being opted in.

Workaround Found: Telemetry env vars break feature flags (including Channels)

After investigating this issue, I found a workaround. The root cause is:

DISABLE_TELEMETRY=1 and/or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 environment variables completely disable GrowthBook feature flag evaluation, causing all gated features (Channels, remote-control, /rc, /btw, etc.) to default to false.

Fix

Remove these env vars from your shell profile and restart:

# Remove these lines from ~/.zshrc (or ~/.bashrc, ~/.zprofile)
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
export DISABLE_TELEMETRY=1

Also check ~/.claude/settings.json for DISABLE_TELEMETRY.

Then:

# Open a new terminal, then:
claude auth logout
claude auth login

This resolved the issue in my environment (macOS, Max plan, v2.1.81). Channels and remote-control both became available after removing these env vars.

Why this happens

Claude Code uses GrowthBook for feature flags. The telemetry-disabling env vars suppress all non-essential network traffic, which includes the GrowthBook flag evaluation requests. Without flag evaluation, every gated feature defaults to disabled — even if your account has the correct entitlements.

Full writeup

I documented the complete troubleshooting process (3 error patterns + fixes) here:

• 🇺🇸 [English] https://qiita.com/otani_ai_memo/items/aff1405fa83c00c14039
• 🇯🇵 [Japanese] https://qiita.com/otani_ai_memo/items/bfb6fba1d31cb08c8b8d

Hopefully Anthropic will decouple telemetry opt-out from feature flag evaluation in a future version. Until then, this workaround should help.

Thanks to @otani_ai_memo for the detailed writeup!

Confirming that remote-control and Channels are now working on Windows 11 as well (v2.1.81).

In my case, I did not have DISABLE_TELEMETRY or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC set — the issue was resolved by the tengu_harbor feature flag being enabled server-side. Both claude remote-control and claude --channels are now functional.

• Environment: Windows 11 Pro, Claude Code v2.1.81, Max plan
• Channels: Working (via plugin:discord@claude-plugins-official)
• Remote Control: Working (claude remote-control)

The Qiita article covering the 3 error patterns was very helpful for troubleshooting:
🇺🇸 https://qiita.com/otani_ai_memo/items/aff1405fa83c00c14039
🇯🇵 https://qiita.com/otani_ai_memo/items/bfb6fba1d31cb08c8b8d

Max plan, same org bug

+1

Channels unavailable on Max plan. Claude Code v2.1.86, Claude Max, macOS Tahoe 26.3.1, Apple M4 Max. Running claude --channels plugin:telegram@claude-plugins-official outputs "--channels ignored" and "Channels are not currently available." No telemetry env vars set. Auth is via claude.ai login.

same issue.
Mac, Personal Max Plan. Showing shadow orgId (no org exists) and null orgName

Also affected — Android/Termux setup with a custom Telegram MCP channel (stdio, not plugin).

Setup: --mcp-config loads a Telegram MCP server via wrapper script + --channels server:telegram for push delivery. Tools work fine (pending_messages polling), but inbound messages don't push inline.

Observed: The --channels flag is silently ignored — no error, but no push delivery either. Consistent with the tengu_harbor gate analysis above.

Environment: Claude Code v2.1.92, Android 14 (Termux), Max plan.

Would appreciate any timeline on the rollout. The workaround (polling) works but real-time delivery was a significant workflow improvement.

Same issue on Claude Code v2.1.104, Personal Max plan (stripe_subscription billing type).

My ~/.claude.json has tengu_harbor: true cached, along with tengu_harbor_ledger showing the discord plugin registered. Also tried setting CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=0 in settings.json — no effect. The flag is still evaluated against the server, not the cache.

"--channels ignored (plugin:discord@claude-plugins-official)" appears at startup despite all local configs being correct. This issue has been open for months without a fix. Please prioritize — it's blocking the core use case of channel plugins for personal Max users.

Summary

Claude Code is ignoring the documented --channels flag for the official Telegram plugin and reports that Channels are not currently available, even though I am logged in with a claude.ai Pro account.

## Environment

• Claude Code version: 2.1.119
• Auth method: claude.ai
• API provider: firstParty
• Subscription type: pro
• Org type: personal org
• OS: macOS
• Plugin: telegram@claude-plugins-official

## Command

```bash
claude --channels plugin:telegram@claude-plugins-official

  ## Actual behavior

  Claude Code prints:

--channels ignored (plugin:telegram@claude-plugins-official)
Channels are not currently available

  The Telegram MCP plugin starts and outbound tool calls work, but inbound Telegram messages never reach the Claude Code session.

  MCP logs contain:

  Channel notifications skipped: channels feature is not currently available

  ## Expected behavior

  Per the Claude Code Channels docs, Pro/Max users using claude.ai auth should be able to opt in per session with:

  claude --channels plugin:telegram@claude-plugins-official

  I expected inbound Telegram messages to appear as channel events in the running Claude Code session after pairing/allowlisting.

  ## Notes

This does not appear to be a Telegram bot token, webhook, pairing, or plugin-scope issue. The failure occurs at the master Channels availability gate before Telegram-specific configuration matters.

 Could you confirm whether Channels are still rolling out by account/org, and whether some Pro personal accounts may not yet have the Channels entitlement enabled?

+1
same issue.

Same issue here — still reproducing on the latest CLI.

Environment

• Claude Code: v2.1.150
• OS: Windows 11
• Plan: Personal Max (also tested with API key / Console)
• Auth: tested both claude.ai and --console

Reproduction
claude --channels plugin:discord@claude-plugins-official
→ --channels ignored (plugin:discord@claude-plugins-official)
→ Channels are not currently available

claude auth status (claude.ai login, masked):

{
  "loggedIn": true,
  "authMethod": "claude.ai",
  "apiProvider": "firstParty",
  "email": "***@gmail.com",
  "orgId": "9cf90060-****-****-****-************",
  "orgName": "***@gmail.com's Organization",
  "subscriptionType": "max"
}

claude auth status (API key / Console):

• orgName: "***'s Individual Org"
• Same Channels are not currently available error

What I tried

• Updated to v2.1.150 (latest)
• Switched between claude.ai and --console auth — same error in both
• Created C:\Program Files\ClaudeCode\managed-settings.json with {"channelsEnabled": true} — no effect
• Cleared ~/.claude/plugins/cache and reinstalled the discord plugin — no effect
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX are all unset
• Discord bot is correctly configured (Message Content Intent on, bot is in the server, token is valid)
• /plugin -> discord MCP: failed -> tried auth but still failed

This appears to match the tengu_harbor GrowthBook feature flag analysis in #50903 — the flag evaluates to false for personal accounts regardless of auth method, and the v2.1.128 changelog note about "Console channels works with API key auth" doesn't help because the underlying flag is still false.

Please prioritize fixing the personal-account orgId / tengu_harbor rollout — this has been open since March 2026 and is blocking all consumer-tier users who paid for the feature.

Same here. Waiting for the fix.

i had DISABLE_TELEMETRY set and unset it in the shell env and the channels are now working for me.