Channels feature regressed between 2.1.104 and 2.1.114 on personal Max: tengu_harbor evaluates false despite cached true

Channels feature regressed between 2.1.104 and 2.1.114 on personal Max: tengu_harbor evaluates false despite cached true

CLI version: 2.1.114 (auto-updated from 2.1.104 in mid-April 2026)
Plan: Personal Max (billingType: stripe_subscription)
Install: Native installer at ~/.local/share/claude/versions/
OS: macOS 14 (Darwin 24.6.0)

Summary

Channels stopped working after the auto-updater moved my Claude Code CLI from 2.1.104 to 2.1.114. On 2.1.104, MCP servers declaring experimental.claude/channel could push notifications/claude/channel to the CLI and the channel tag rendered in the agent's next turn. On 2.1.114, the CLI prints --dangerously-load-development-channels ignored and Channels are not currently available at startup and ignores the push entirely.

Decompiling 2.1.114 shows the new gate is a GrowthBook feature flag called tengu_harbor that returns false at runtime, even though my ~/.claude.json has cachedGrowthBookFeatures.tengu_harbor: true.

I worked through this with support (ticket thread available on request). First reply pointed at the channelsEnabled managed setting, which per the decompiled source is only consulted for team/enterprise tiers, so it does not apply to a personal Max account. Second reply confirmed the tengu_harbor diagnosis but said GrowthBook flag adjustments are not available through standard support and directed me to escalate via GitHub.

Reproduction

Launch the CLI against any MCP server that declares experimental.claude/channel:

claude --dangerously-load-development-channels server:<name> \
       --mcp-config <path> \
       --model claude-opus-4-6

Expected (2.1.104 behaviour): channel registers, MCP notifications/claude/channel pushes surface as <channel> tags in the agent's turn.

Actual (2.1.114 behaviour):

--dangerously-load-development-channels ignored (server:<name>)
Channels are not currently available

MCP push arrives over the wire (server-side logs confirm the POST) but the CLI silently drops it.

Decompiled gate (2.1.114)

From ~/.local/share/claude/versions/2.1.114 (minified single-file Bun binary, extracted via strings + grep around the error-string literal):

function IK_(serverName, serverCaps, pluginMeta) {
  if (!serverCaps?.experimental?.["claude/channel"])
    return { action: "skip", kind: "capability" };

  if (!TPH())
    return { action: "skip", kind: "disabled",
             reason: "channels feature is not currently available" };

  if (!K8()?.accessToken)
    return { action: "skip", kind: "auth" };

  const tier = Gq();
  const isTeamOrEnterprise = tier === "team" || tier === "enterprise";
  const policy = isTeamOrEnterprise ? G6("policySettings") : undefined;

  if (isTeamOrEnterprise && policy?.channelsEnabled !== true)
    return { action: "skip", kind: "policy" };

  // ...session / allowlist checks follow. Dev-load bypasses allowlist
  // via `!match.dev` short-circuit; `TPH()` is the earlier blocker.

  return { action: "register" };
}

function TPH() { return h_("tengu_harbor", false); }

The Channels are not currently available message corresponds to kind: "disabled", which fires when TPH() returns false.

Cached flag vs runtime evaluation

~/.claude.json on this machine:

{
  "oauthAccount": {
    "organizationRole": "admin",
    "billingType": "stripe_subscription",
    "accountCreatedAt": "2025-03-06T09:05:43Z",
    "subscriptionCreatedAt": "2025-08-28T10:59:39Z"
  },
  "cachedGrowthBookFeatures": {
    "tengu_harbor": true,
    "tengu_harbor_permissions": true,
    "tengu_harbor_ledger": [
      { "plugin": "discord" },
      { "plugin": "telegram" },
      { "plugin": "fakechat" },
      { "plugin": "imessage" }
    ]
  }
}

So the cached value for tengu_harbor is true, but live evaluation via h_("tengu_harbor", false) returns false. Either the cache is stale and being bypassed, or the flag is being re-evaluated with a different context (account UUID, org UUID, tier) that excludes my account.

Managed settings path is not applicable

/Library/Application Support/ClaudeCode/managed-settings.json with channelsEnabled: true was tested. No effect, which matches the decompiled code: the channelsEnabled check is gated behind isTeamOrEnterprise, and my tier is max.

What I am asking for

1. Confirmation of whether tengu_harbor is still being rolled out to personal Max accounts, or whether it was intentionally disabled between 2.1.104 and 2.1.114.
2. If the flag was rolled back for Max accounts, ideally a public roadmap note so users on that plan know the feature is gone until a re-release.
3. If the flag was meant to stay on for Max, a way to re-enable it for my account, or a documented setting (outside managed-settings.json, since that path is tier-gated) that overrides the check.
4. If neither of those, some form of acknowledgement that the research-preview flag has been tightened, so I can stop hunting for a local misconfiguration.

Happy to provide the full decompiled extraction, the ~/.claude.json with cached flags, and the MCP server logs showing the channel push arriving but being dropped. I have already applied a local workaround (bypassing the CLI channel handler entirely) so this is not urgent for my use case, but I suspect other power-users on personal Max running self-declared MCP channel servers have hit the same wall without the decompilation step.

Thanks.