--channels plugin shows 'Channels are not currently available' but inbound notifications are ignored

Root cause is the same as #36460 — server-side feature flag gates channel registration.

Your debug output confirms the plugin side is working perfectly. The notifications/claude/channel JSON-RPC is well-formed and delivered over stdio. The problem is on Claude Code's side.

The channel registration function (JK9 in the v2.1.80 binary) runs 7 eligibility gates before it will register a channel handler for any MCP server. Gate 2 checks a GrowthBook feature flag called tengu_harbor:

function ua_() { return Tq("tengu_harbor", false) }

When this returns false, JK9 returns {action: "skip", kind: "disabled", reason: "channels feature is not currently available"} — which is the exact message you're seeing. The notification arrives but there's no registered handler to route it into the conversation.

Verify yourself:

strings ~/.local/share/claude/versions/2.1.80 | grep "tengu_harbor"

Full 7-gate breakdown in my comment on #36460: https://github.com/anthropics/claude-code/issues/36460#issuecomment-4095918939

This is a server-side rollout flag — no local fix exists. Anthropic controls when it's enabled per account.

Since this is a server-side rollout flag, is there any way to opt in for early access? I'd love to test this feature — my setup is already working correctly on the plugin side, just waiting on the flag to be enabled. Happy to provide any additional debug info if helpful.

Same issue here. macOS Darwin 25.3.0, Claude Code 2.1.80, telegram@claude-plugins-official v0.0.1.

On startup: --channels ignored (plugin:telegram@claude-plugins-official)

Outbound tools (reply, react, edit) work fine. Inbound notifications never surface in the conversation. Plugin side confirmed healthy — single process, active polling, valid token.

One detail that may help: inbound worked perfectly during my first session (2026-03-19 evening), then broke on every subsequent session. Suggests the feature gate may evaluate differently on initial plugin install vs. subsequent startups.

Possibly related: #36431, #36472

I saw same behavior as @dvaladares -- worked on the first session. Did not work after there. All logging indicates everything went fine but nothing appears in terminal. I think there's a genuine bug.

Same issue here.

• OS: Arch Linux 6.18.13
• Claude Code: v2.1.81
• Auth: claude.ai OAuth (not API key)
• Plugin: telegram@claude-plugins-official v0.0.1

What I tried (none worked):

1. Removed DISABLE_TELEMETRY from settings.json
2. Removed CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC from settings.json
3. Removed DISABLE_ERROR_REPORTING and DISABLE_AUTOUPDATER as well
4. Verified no shell profile (.bashrc/.zshrc/.profile) sets these vars
5. Confirmed clean env output — no blocking vars in the environment
6. Multiple session restarts after each change

Result: Still getting --channels ignored (plugin:telegram@claude-plugins-official) and Channels are not currently available on every startup. Outbound MCP tools (reply, react, edit_message) work fine. Plugin polling is healthy. The tengu_harbor feature gate is the blocker.

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

Codex fixed it for me. FYI.

Claude Code 2.1.80 Telegram dev-channel allowlist bug needs live CLI patching

• Trigger:
• Telegram channel plugin loads and its MCP server connects, but Claude Code still prints:
• plugin:telegram@claude-plugins-official · not on the approved channels allowlist
• Channel notifications skipped: plugin telegram@claude-plugins-official is not on the approved channels allowlist
• This still happens even when launching with both:
• --channels plugin:telegram@claude-plugins-official
• --dangerously-load-development-channels plugin:telegram@claude-plugins-official
• Scope:
• Bun-installed Claude Code 2.1.80 on hosts in this repo when using the official Telegram channel plugin as a development channel.
• Root cause:
• In the installed CLI, the startup path correctly parses --dangerously-load-development-channels, but the parsed list is not applied to the runtime channel state used by the later allowlist check.
• The result is that the Telegram plugin can start and connect, but channel registration is still rejected as if the dev-channel allowlist flag had never been supplied.
• Diagnosis path to re-run after future Claude Code updates:
• First confirm the failure is at channel registration, not plugin loading:
• check the debug log for plugin:telegram:telegram: if you see Successfully connected followed by Channel notifications skipped, the plugin and token path are fine and the bug is in channel gating.
• Then inspect the installed CLI source, not docs:
• search the live cli.js for --dangerously-load-development-channels, allowedChannels, getChannelAllowlist, and tengu_harbor_ledger.
• verify whether the parser branch for dangerouslyLoadDevelopmentChannels writes anything back into the runtime channel list before the later Channel notifications skipped check runs.
• Compare that parser branch with the existing interactive dev-channel acceptance path:
• the acceptance path mutates allowedChannels with dev = true;
• the broken parser path only parses the flag, then drops the result on the floor.
• Treat plugin README text as secondary evidence only:
• the authoritative source for this bug is the installed runtime plus the debug log, not the plugin README.
• Temporary local workaround in this repo:
• Keep a live local patch against the Bun-installed Claude Code cli.js.
• Re-derive the patch by following the diagnosis path above after each Claude Code update, instead of trusting line numbers or reusing an old diff blindly.

Confirming this bug still exists in Claude Code 2.1.81 (installed via Homebrew on macOS).

Setup:

• Plugin: telegram@claude-plugins-official v0.0.1
• Launch flags: --dangerously-load-development-channels plugin:telegram@claude-plugins-official
• Bun installed and accessible at ~/.local/bin/bun

What works:

• ✅ MCP server connects successfully
• ✅ Plugin polls Telegram correctly (updates are consumed from API)
• ✅ Outbound messages work (can send via mcp__plugin_telegram_telegram__reply)

What doesn't work:

• ❌ Inbound channel notifications are not routed into the conversation
• ❌ No "Channel notifications skipped" message visible, but messages from Telegram never reach the assistant

Debug log shows:

MCP server "plugin:telegram:telegram": Successfully connected
MCP server "plugin:telegram:telegram": Connection established with capabilities: {"hasTools":true,...}

The plugin is functioning correctly on the MCP side, but Claude Code is not routing the notifications/claude/channel notifications into the active conversation.

Since Claude Code is installed as a compiled binary (not patchable JS), the workaround from the previous comment cannot be applied.

Please fix the --dangerously-load-development-channels flag so it properly updates the runtime channel allowlist.

Install from npm and you can format Claude Code "binary" (minified JS). Then ask Codex to work on CC.

+1 — Experiencing the same issue. Bot receives messages and sends typing indicator, but the <channel> tag never surfaces in the Claude Code session. Running in CLI mode with claude --dangerously-skip-permissions plugin:telegram@claude-plugins-official. The feature flag gating explanation matches what I'm seeing.

+1 — Experiencing the same. Filed #37184. tengu_harbor flag appears to be the gate.

Session: Morpheus (ae19) | Task: 6gChXr7Cp3fPP5RG

Confirmed reproducible on my end as well.
Environment:

• Claude Code version: 2.1.81
• OS: macOS
• Plugin: telegram@claude-plugins-official v0.0.1

Exact same behavior: plugin polls Telegram successfully, notifications/claude/channel notifications arrive over stdio, but Claude Code does not route them into the conversation or generate any response. The "Channels are not currently available" message is also shown at startup.
Reproduces consistently. Hope this helps with prioritization.

Subscribing — we're hitting the same issue with the Discord plugin. Using a 60-second polling loop as a workaround. Looking forward to the fix.

Hi all!
I created a plugin to work around the Claude-Telegram issue (didn't create a solution for Discord yet).
https://github.com/StavPartouche/claude-channels-workaround
Just install the plugin, run /telegram-bridge:setup, follow the steps, and you should be good to go!

I found that this issue occurs when telemetry is disabled in my Claude Code settings (DISABLE_TELEMETRY). If DISABLE_TELEMETRY is removed, it returns to normal. I hope this helps everyone.

Hi all! I created a plugin to work around the Claude-Telegram issue (didn't create a solution for Discord yet). https://github.com/StavPartouche/claude-channels-workaround Just install the plugin, run /telegram-bridge:setup, follow the steps, and you should be good to go!

This works for me 👍🏻 ! btw, you need to uninstall the perivous offical plugin to complete the setup.

Just running /reload-plugins fixed it for me since I had already set things up and paired my Telegram bot

The "Channels are not currently available" message combined with working polling but no response processing suggests the channel listener isn't connected to the conversation pipeline.
Workaround 1 — Use Remote Control instead of channels:

claude

Remote Control provides a web/mobile interface for sending messages to Claude. Combined with a simple Telegram bot that forwards messages to the RC endpoint, you can achieve similar functionality.
Workaround 2 — Use pipe mode with a polling script:

while true; do
  MSG=$(curl -s "https://api.telegram.org/bot$TOKEN/getUpdates?offset=$OFFSET" | jq -r '.result[-1].message.text // empty')
  if [ -n "$MSG" ]; then
    RESPONSE=$(echo "$MSG" | claude -p)
    curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" -d "chat_id=$CHAT_ID&text=$RESPONSE"
    OFFSET=$(($(curl -s "https://api.telegram.org/bot$TOKEN/getUpdates" | jq '.result[-1].update_id') + 1))
  fi
  sleep 5
done

This creates a simple bridge without depending on the channels plugin.
Workaround 3 — Check version compatibility:

claude --update

Channels is a relatively new feature. Ensure you're on the latest version where it may be more stable.
Workaround 4 — File-based message passing:
Set up a watched file that the Telegram bot writes to, and a UserPromptSubmit hook that reads from it:

echo "$MESSAGE" > /tmp/telegram-inbox.txt

This is crude but avoids the channels infrastructure entirely.

While this issue is active for Telegram; if anyone is interested trying async task manager with always on Claude code agents using Claude channels, feel free to give it a try to AgentRQ. Looking forward to getting some feedback and improving together.

Workaround: use --dangerously-load-development-channels server:<name> instead of --channels plugin:<name>@<marketplace>

We've confirmed that the --channels plugin:telegram@claude-plugins-official path does not deliver inbound notifications/claude/channel to the session, while a bare .mcp.json server entry with --dangerously-load-development-channels works end-to-end on the same machine, same token, same Claude Code version (2.1.92).

Steps

1. Add the plugin's MCP server directly to your project's .mcp.json (or ~/.claude.json for global):

{
  "mcpServers": {
    "telegram": {
      "command": "bun",
      "args": [
        "run", "--cwd",
        "/Users/<you>/.claude/plugins/cache/claude-plugins-official/telegram/0.0.4",
        "--shell=bun", "--silent", "start"
      ]
    }
  }
}

(Adjust the version path to match your cached plugin version.)

1. Launch with the development flag instead of --channels:

claude --dangerously-load-development-channels server:telegram

1. Send a message from Telegram — it arrives as a <channel source="telegram" ...> tag and Claude responds via the reply tool.

Why this works

The --dangerously-load-development-channels server:<name> flag activates channel routing for a bare MCP server entry (keyed by the name in .mcp.json). It bypasses the plugin resolution + allowlist path that --channels plugin:<name>@<marketplace> uses. The MCP server itself is identical — same binary, same capability negotiation — but the CLI-side activation path is different and apparently not affected by the bug.

Environment

• Claude Code 2.1.92
• macOS 15.4 (Darwin 25.3.0, arm64)
• Telegram plugin 0.0.4
• Auth: claude.ai OAuth (not API key)

This also works for Discord and custom channel servers — any plugin that advertises experimental.claude/channel can be registered as a bare .mcp.json entry and activated with --dangerously-load-development-channels server:<name>.

Update: We've published a full Rust drop-in replacement for the official Bun-based Telegram plugin: hdcd-telegram (v0.1.0).

• 3.5 MB static binary vs ~100 MB Bun runtime
• ~5 MB RAM per instance vs ~100 MB
• <50 ms startup vs 2-3 seconds
• Immediate shutdown on stdin EOF (no zombie 409 Conflict)
• Full feature parity: all 8 message types, 4 tools, access control, permission relay, voice transcription via whisper
• Compatible with existing access.json and .env — zero migration

Works with the --dangerously-load-development-channels server:telegram workaround described above. Pre-built binaries for Linux, macOS (Intel + Apple Silicon), and Windows available on the releases page.

## Workaround: use --dangerously-load-development-channels server:<name> instead of --channels plugin:<name>@<marketplace> We've confirmed that the --channels plugin:telegram@claude-plugins-official path does not deliver inbound notifications/claude/channel to the session, while a bare .mcp.json server entry with --dangerously-load-development-channels works end-to-end on the same machine, same token, same Claude Code version (2.1.92). ### Steps 1. Add the plugin's MCP server directly to your project's .mcp.json (or ~/.claude.json for global): { "mcpServers": { "telegram": { "command": "bun", "args": [ "run", "--cwd", "/Users/<you>/.claude/plugins/cache/claude-plugins-official/telegram/0.0.4", "--shell=bun", "--silent", "start" ] } } } (Adjust the version path to match your cached plugin version.) 2. Launch with the development flag instead of --channels:

Thanks for posting. I followed your instructions and it didn't work:

❯ (base) clone45@BRET-PRIMARY-HOME:~/.claude$ claude --dangerously-load-development-channels server:telegram
  
  Claude─Code─v2.1.92

  --dangerously-load-development-channels ignored (server:telegram)
  Channels are not currently available

@maciek-hyperdev I've tried with the official plugin and with yours, and I get the same issue with both:

• When I send a message, the bot starts "typing" for a few seconds, then stops.
• I never get a reply.
• My message doesn't appear in Claude Code's logs.
• If I tail the logs of your plugin, I see a call to notifications/claude/channel.
• If I send /start or /help or /status I do get a response back from the plugin.

How can I troubleshoot this further?

Do you think that relates to https://github.com/anthropics/claude-code/issues/41275?

What Claude subscription do you use? I have maxx. Didn't test on any other.

What Claude subscription do you use? I have maxx. Didn't test on any other.

Same, Max 20x, and the official Telegram channel worked for me yesterday, I don't think it's a server-side feature flag thing.

@clone45 Thanks for trying the workaround! The ignored (server:telegram) message suggests Claude Code isn't picking up the MCP server entry before evaluating the --dangerously-load-development-channels flag.

Could you share a few details so we can help debug?

1. OS + architecture (e.g. macOS 15.x arm64, Ubuntu 24.04 x86_64)
2. Claude Code version — output of claude --version
3. Auth method — claude.ai OAuth or API key?
4. Your .mcp.json config (redact any tokens) — specifically where the file lives (project root vs ~/.claude.json) and the exact server entry
5. Is the MCP server starting at all? — when you launch Claude, do you see the telegram server listed under connected MCP servers?

Common gotchas we've seen:

• The server name in .mcp.json must exactly match the name after server: in the flag (e.g. "telegram" → server:telegram)
• The .mcp.json must be in the project directory you launch claude from, or in ~/.claude.json for global
• Bun must be on your PATH at launch time

Also — we've since published hdcd-telegram v0.1.1, a Rust drop-in replacement that's simpler to configure (single binary, no Bun dependency). Might be worth a try if you're still stuck with the Bun-based plugin setup.

@ricardbejarano Thanks for the detailed report — and for trying hdcd-telegram!

The symptoms you describe ("typing" indicator fires but no reply, notifications/claude/channel visible in plugin logs but Claude Code doesn't surface it) point to Claude Code receiving the notification but not routing it into the conversation. This is the same core issue as the original bug, but interesting that it worked for you yesterday.

To help us narrow it down, could you share:

1. Claude Code version — claude --version
2. OS + architecture
3. How you're launching — exact CLI command (with flags)
4. Which .mcp.json are you using? (project-level or ~/.claude.json?) — redacted config would help
5. Claude Code startup output — specifically, does it say --dangerously-load-development-channels ignored or does it show the channel as active?
6. Plugin logs — the last ~20 lines around when you send a Telegram message (both for official plugin and hdcd-telegram, if you have them)
7. Did anything change between yesterday (working) and today? — Claude Code update, config change, different project directory?

Re: #41275 — it could be related if the channel registration path changed in a recent update. Knowing your exact version will help us cross-reference.

Also, we're about to release hdcd-telegram v0.1.1 with improved diagnostics and connection logging that should make this kind of issue easier to trace. Worth trying once it's out.

@clone45 @ricardbejarano — We've just updated the hdcd-telegram README with clearer setup instructions. A few things that may help:

How the bot token is discovered:
hdcd-telegram automatically reads TELEGRAM_BOT_TOKEN from ~/.claude/channels/telegram/.env on startup — the same file the official Telegram plugin uses. You do NOT pass the token in .mcp.json. If the file doesn't exist or the token is missing, the binary will fail at startup with a clear error.

Minimal working setup (3 files):

1. Bot token — ~/.claude/channels/telegram/.env:

``
TELEGRAM_BOT_TOKEN=123456789:AAHxxx...
``

1. MCP server — .mcp.json in your project (or ~/.claude.json for global):

``json
{
"mcpServers": {
"telegram": {
"command": "/path/to/hdcd-telegram",
"args": []
}
}
}
`
The server name **must** be "telegram" to match server:telegram` in the launch flag.

1. Launch:

``bash
claude --dangerously-load-development-channels server:telegram
``

Common issues we've seen:

• .mcp.json in the wrong directory (must be in the directory you run claude from, or use ~/.claude.json for global)
• Binary path in "command" is wrong or not executable (chmod +x)
• Another process still polling the same bot token (kills with 409 Conflict) — pkill -f hdcd-telegram first
• For group chats: privacy mode must be disabled in @BotFather (/setprivacy → Disable) before adding the bot to the group

Full updated docs: https://github.com/gohyperdev/hdcd-telegram#quick-start

@maciek-hyperdev here's what I got as of right now:

---

On one hand, I have:

• Claude Code 2.1.84 with --dangerously-skip-permissions
• The official Telegram plugin v0.0.4 running via the --channels flag (successfully connected as per /mcp output and the fact that it doesn't show any error like it does when the plugin is not working)
• Running on a macOS Sequoia 15.6.1 VM
• The VM runs on UTM 4.7.5
• The host runs macOS Sequoia 15.7.4

This works just fine.

---

On the other hand, I have:

• Claude Code 2.1.96 with --append-system-prompt '...' --permission-mode bypassPermissions
• I've tried both:
• the official Telegram plugin v0.0.4 (both via --channels and --dangerously-load-development-channels
• and hdcd-telegram v0.1.0 (via --dangerously-load-development-channels)
• Running on a Docker container on OrbStack 2.0.5
• The host runs macOS Sequoia 15.7

This doesn't work.

---

Both scenarios use the same account, they're both logged in in the same way (OAuth browser "paste this token" flow).

In the non-working scenario, both the official Telegram plugin as well as yours successfully connect to Telegram. I know this because I can /setup or text them and the plugin responds with the usual responses. Both, however, fail to notify Claude Code. Even when copying the same access.json from the working scenario to skip having to pair again, the message arrives at the plugin (which is why it starts "typing") but it never shows up in the Claude Code session like it does on the working scenario. Eventually, both plugins stop "typing" and I get no response.

I've tried turning off the working scenario before starting the latter, to see if maybe the channels feature flag is limited to one session. It didn't fix it.

I've also carried the same ~/.claude.json file from the working one to the broken one, to no success either.

So yeah, I'm not done trying to get things more "apples to apples" to figure out what's going on, but any help or pointers would be greatly appreciated.

@ricardbejarano Thanks for the thorough comparison — this is really valuable data!

The key difference between your two setups is clear:

| | Working | Not working |
|---|---|---|
| Claude Code | 2.1.84 | 2.1.96 |
| Platform | macOS VM (UTM) | Docker (OrbStack) |
| Channel flag | --channels | --channels and --dangerously-load-development-channels |

Two things stand out:

1. Version difference (2.1.84 vs 2.1.96)

The fact that 2.1.84 works with --channels but 2.1.96 doesn't suggests a regression in a recent Claude Code update. This is important — could you try downgrading the Docker instance to 2.1.84 to confirm?

npm install -g @anthropic-ai/claude-code@2.1.84

If 2.1.84 works in Docker too, that confirms a regression and would be worth filing as a separate issue with both versions.

2. Docker/OrbStack environment

Docker containers sometimes behave differently with stdio-based MCP servers. A few things to check:

• Is the hdcd-telegram binary running inside the container or on the host? (It needs outbound HTTPS to api.telegram.org)
• Are the ~/.claude/channels/telegram/.env and access.json files mounted/accessible inside the container?
• Does the container have the same OAuth identity? (claude config get should show the same account)

Suggested next step

The version difference is the strongest lead. If you can test 2.1.84 in Docker and it works, we know it's a regression between .84 and .96. That would give Anthropic a clear window to bisect.

claude.ai login only: API key and Console authentication do not work with Channels; you must be authenticated with a claude.ai account on Pro, Max, Team, or Enterprise.

I find this in https://www.lowcode.agency/blog/claude-code-channels-setup-telegram-discord

@maciek-hyperdev all this troubleshooting for nothing. I was carrying auth wrong. Once I logged in it worked.

Status clarification for everyone following this issue

After extensive testing and community research (credit to @soumikbhatta's analysis in #36460), here's where things stand:

This is not a bug — it's an intentional feature gate. Claude Code's channel functionality is controlled by a server-side feature flag (tengu_harbor in GrowthBook). When this flag is disabled for your account, all inbound channel notifications are silently dropped — regardless of which plugin you use, which marketplace it comes from, or which CLI flags you pass.

What works and what doesn't:

| Path | Inbound messages | Outbound tools (reply, react) |
|---|---|---|
| --channels plugin:telegram@claude-plugins-official | Blocked by feature flag | Works |
| --channels plugin:*@any-marketplace | Blocked by feature flag | Works |
| --dangerously-load-development-channels server:<name> | Works (bypasses the flag) | Works |

The workaround (--dangerously-load-development-channels server:<name> with a manual .mcp.json entry) still works reliably because it follows a different code path that doesn't check the feature flag. See our earlier comment for setup instructions.

What this means for plugin authors and users:

• The official Telegram plugin works correctly on the plugin side — it's not broken
• Third-party plugins and marketplaces have the same limitation
• The feature flag appears to be part of a gradual rollout — some accounts have it enabled, others don't
• There's no local fix or setting that can override it

We'll continue maintaining the workaround instructions and helping users in this thread. If Anthropic has a timeline or opt-in process for broader channels rollout, that would be very helpful information for the community.

@ricardbejarano Glad you got it working! Thanks for reporting back — this is a crucial finding.

@oashua Great catch on the auth requirement — that's documented but easy to miss.

Key takeaway for everyone: Channels require claude.ai OAuth login

This is worth highlighting because it's been a hidden blocker for multiple users in this thread:

Channels only work with claude.ai OAuth authentication. API keys and Console authentication do not work — the channel registration silently fails.

If you're running Claude Code in Docker, CI, or any headless environment, make sure you're authenticated via the OAuth flow (claude login), not via ANTHROPIC_API_KEY.

Quick check:

claude config get authMethod

Should return oauth (not apiKey).

This likely explains several "it was working, then it stopped" reports — if a session switches auth methods (e.g., Docker container with API key vs local with OAuth), channels break silently.

Adding this to the hdcd-telegram README now.

Windows datapoint: workaround does not bypass feature flag

Environment:

• Windows 11 Home (10.0.26200)
• Claude Code 2.1.97
• Official Telegram plugin 0.0.4
• Auth: claude.ai OAuth (Max plan)
• Shell: bash (Git Bash)

What works:

• ✅ MCP server connects (/mcp shows telegram · ✔ connected)
• ✅ Outbound messages work (reply tool sends messages to Telegram successfully)
• ✅ Plugin receives inbound messages (Telegram shows "typing..." indicator)

What doesn't work:

• ❌ --dangerously-load-development-channels server:telegram — no error shown, but inbound notifications never reach the conversation
• ❌ Tried with both plugin 0.0.1 and 0.0.4
• ❌ Tried with both Claude Code 2.1.81 and 2.1.97
• ❌ Disabled official plugin to avoid duplicate MCP conflict — same result

Key observation: The bot shows "typing..." in Telegram (confirming the MCP server receives the message), but Claude Code silently drops the notifications/claude/channel notification. This matches the feature flag behavior, not a config issue.

It appears the --dangerously-load-development-channels server:<name> workaround confirmed on macOS does not bypass the tengu_harbor feature flag on Windows.

@Kullendorff Thanks for the detailed Windows datapoint — this is new and important information.

Your observation suggests the --dangerously-load-development-channels workaround may not work on Windows even though it works reliably on macOS. This is a significant platform difference worth tracking.

A few things to verify:

1. Auth check — can you confirm the OAuth login is active in this specific session?

``bash
claude config get authMethod
`
Should return oauth`. Even with Max plan, if the session falls back to API key auth, channels silently fail (confirmed by multiple users).

1. Shell environment — Git Bash on Windows can sometimes affect stdio communication. Have you tried from PowerShell or cmd.exe?

1. Claude Code 2.1.97 — this is newer than what most of us have tested with (macOS confirmed working on 2.1.92-2.1.96). If 2.1.97 changed the channel registration path, it could be a regression.

1. MCP server name — is the name in your .mcp.json exactly "telegram" matching server:telegram in the flag?

If all of the above check out, this could be a Windows-specific issue in how Claude Code handles the --dangerously-load-development-channels flag — possibly related to stdio buffering differences on Windows. That would be worth filing as a separate issue.

For reference, @Xch13 got hdcd-telegram working on Windows (v2.1.92) after fixing OAuth auth — so the channel substrate does work on Windows under the right conditions.

@maciek-hyperdev Confirmed — auth is claudeAiOauth (Max plan, 5x rate-limit tier). OAuth is active and valid in this session:

credentials.json → claudeAiOauth
subscriptionType: "max"
rateLimitTier: "default_claude_max_5x"
accessToken, refreshToken: present and valid

So auth is definitively not the blocker here. This appears to be a genuine Windows-specific issue where --dangerously-load-development-channels does not bypass the tengu_harbor feature flag, even with valid OAuth on a Max plan.

Happy to run any additional diagnostics if it helps narrow down the Windows code path.

@Kullendorff Thanks for confirming the auth — this rules out the most common blocker.

With OAuth confirmed working on Max plan, this looks like a genuine Windows-specific issue where --dangerously-load-development-channels doesn't bypass the feature flag. On macOS the same flag reliably enables channel routing (confirmed by multiple users on 2.1.92-2.1.96).

This is worth filing as a separate issue — something like:

[Windows] --dangerously-load-development-channels does not enable inbound channel notifications - Windows 11 (10.0.26200), Git Bash - Claude Code 2.1.97 - Auth: claudeAiOauth, Max plan - MCP server connects, outbound tools work, but notifications/claude/channel never delivered to conversation - Same setup works on macOS

The Windows stdio handling differs from macOS/Linux (line ending conversion, buffering behavior), which could affect how the JSON-RPC notifications are delivered over the MCP subprocess pipe.

If you file it, link it here and we'll add our cross-platform observations. This would give Anthropic a clear, actionable bug report separate from the broader feature-flag discussion.

@maciek-hyperdev Filed the separate Windows issue as suggested:

#46125 — [Windows] --dangerously-load-development-channels does not enable inbound channel notifications

Includes full repro steps, environment details, everything tested, and the cross-platform comparison. Linked back here and to #36460 and #36964.

--channels ignored (plugin:telegram@claude-plugins-official)

--dangerously-load-development-channels ignored (server:telegram)

issue still exists

Linux datapoint + binary analysis of the gate ordering

Environment:

• Ubuntu Linux (6.17.0-20-generic)
• Claude Code 2.1.100
• Official Telegram plugin v0.0.4
• Auth: claude.ai OAuth (Max plan)

Channels were working 2026-04-09, broke 2026-04-10 — no config changes, just the feature flag flipping.

--dangerously-load-development-channels cannot bypass tengu_harbor

I extracted and decompiled the channel registration gate function (Y4$) from the v2.1.100 binary. Here's the check order:

Step 1: claude/channel capability check → skip if server doesn't declare it
Step 2: kLH() [tengu_harbor flag] → skip if false  ← BLOCKS HERE
Step 3: Auth check (accessToken)
Step 4: Org policy check (channelsEnabled)
Step 5: Session flags check (--channels list)
Step 6: Dev flag / allowlist check (--dangerously-load-development-channels)

The tengu_harbor GrowthBook check at step 2 runs before the f.dev flag at step 6. The function returns early with {action:"skip", kind:"disabled", reason:"channels feature is not currently available"} before it ever evaluates whether --dangerously-load-development-channels was passed.

This means the --dangerously-load-development-channels workaround reported earlier in this thread can only bypass the allowlist check (step 6) — it cannot bypass tengu_harbor (step 2). Users who reported success with this flag likely had tengu_harbor enabled for their accounts at the time.

Relevant decompiled snippet

function Y4$(H, $, q) {
  if (!$?.experimental?.["claude/channel"])
    return { action: "skip", kind: "capability", reason: "server did not declare claude/channel capability" };
  if (!kLH())  // ← tengu_harbor check, runs BEFORE dev flag
    return { action: "skip", kind: "disabled", reason: "channels feature is not currently available" };
  // ... auth, policy, session checks ...
  if (f.kind === "plugin") {
    if (!f.dev) { /* allowlist check */ }  // ← dev flag only helps HERE
  } else if (!f.dev) {
    return { action: "skip", kind: "allowlist", reason: "..." };
  }
  return { action: "register" };
}

Workaround

Using telegram-bridge@claude-channels-workaround by @StavPartouche — bypasses the channel system entirely by polling Telegram's Bot API and piping to claude --print. Works but loses session persistence.

Would really appreciate any timeline on when tengu_harbor will be re-enabled for Max plan users.

Hey — just checking in on this since the thread's been quiet for about a week. Is there any update on the tengu_harbor flag for Max plan accounts? Channels have been unavailable for 9+ days now and it's blocking a few workflows I've built around them.

Totally understand if there's a reason it's been rolled back — even a quick note on status or rough timeline would be really helpful for planning around it.

Thanks!

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?

Built a working workaround for this — file queue + bash watcher + tmux, zero token cost at idle, generalizes to any MCP channel plugin (Discord, Slack, webhooks). Generic pattern with pseudocode:
→ https://github.com/LozzKappa/claude-code-telegram-bot/blob/main/mcp-channel-workaround.md

@LozzKappa That is a roundabout hack and, although I'm sure we're all happy you made it work, doesn't really help this issue.

hello has this been addressed?

Possibly related, distinct symptom in the same --channels / MCP-ingest area: #69440 (mid-surrogate truncation of a channel notification persists a lone surrogate into the transcript, causing 400 no low surrogate in string on every subsequent request).