[BUG] Telegram channel plugin: inbound messages fail with "out of extra usage" after 2-3 turns on Max subscription; fakechat works indefinitely on same account

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When running Claude Code with --channels plugin:telegram@claude-plugins-official on a Claude Max subscription, inbound Telegram messages succeed for the first 2-3 turns and then start failing with:

LLM request rejected: You're out of extra usage. Add more at claude.ai/settings/usage and keep going.

The fakechat plugin works indefinitely on the same account, same session model, same auth, same machine. Direct keyboard input in the same Claude Code session also works without issue. The Sonnet/Opus usage counters on the claude.ai dashboard do not increment for the failing turns, suggesting they're being routed through a separate accounting path that isn't the subscription pool.

This contradicts the Channels docs, which state:

"They require claude.ai login. Console and API key authentication is not supported."

If channels can only use claude.ai login, the "out of extra usage" error path should not be reachable at all.

Environment

• Claude Code v2.1.92
• Bun 1.3.11
• OS: Ubuntu 24.04 on AWS EC2
• Auth: Claude Max subscription (OAuth, no ANTHROPIC_API_KEY set)
• Telegram plugin: telegram@claude-plugins-official v0.0.4
• Model: claude-sonnet-4-6
• Subscription quota at time of failure: ~70% weekly / ~85% session remaining
• Account "extra usage" pool: empty (zero credits, never purchased)

Expected: all messages reply (subscription quota has plenty of room).
Actual: first 2-3 messages reply normally; subsequent ones return the "out of extra usage" rejection in the chat. Direct typing into the Claude Code TUI in the same session continues to work fine throughout.

Differential test against fakechat

Same machine, same user, same Claude Code binary, same Max account, same --channels mechanism, switched only the plugin:

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

Sent 5+ consecutive messages via /upload. All 5 succeeded, no billing error. Round-tripped through the reply tool normally. This rules out: account-level flag, subscription exhaustion, channels-feature-wide quota, cwd, username, hostname, environment variables, working directory contents.

What I've already ruled out

• ❌ Subscription exhausted (dashboard shows ~70% weekly remaining)
• ❌ Extra-usage exhausted (none was ever purchased; docs say channels can't use it anyway)
• ❌ Username/path containing flagged substrings (tested under a fresh soma user with neutralized $HOME, $USER, cwd, content, git remotes — no change)
• ❌ Channels-wide hidden quota (fakechat works indefinitely on the same account)
• ❌ The claude/channel/permission capability declaration (removed it from server.ts capabilities — same failure pattern)
• ❌ The notifications/claude/channel/permission_request handler (commented out — same failure pattern)
• ❌ Telegram bot name / description (named neutrally)
• ❌ Direct keyboard input billing (same session, same model, never fails)

What's odd

• Failures don't appear on the usage dashboard. Successful interactive turns increment Sonnet usage; failed channel turns leave it flat. The failed turns are being accounted for somewhere else, not the subscription.
• The error message is misleading. It tells the user to add extra usage at claude.ai/settings/usage, but per the Channels docs, channel-routed turns can only use claude.ai login auth — extra-usage credits would not be applicable even if purchased.
• The 2-3 message threshold is consistent. Across multiple session restarts (different patches applied), telegram fails reliably after 2-3 inbound messages and fakechat reliably doesn't.

Suspected cause

A billing classifier somewhere in the channel-routing path is flagging Telegram-sourced turns differently from fakechat-sourced turns and routing them through a non-subscription accounting bucket that has a near-empty default allowance. Removing the permission-relay capability from the plugin manifest does not affect the classification, so the discriminator is likely keying off something else — possibly the channel name, the meta envelope shape (telegram passes user, user_id, ts; fakechat passes minimal metadata), or a whitelist that includes fakechat but not telegram.

Impact

Telegram channels are effectively unusable for me today. The advertised "always-on assistant via Telegram bridge" pattern works for a brief warmup window then dies, with no clear remediation path because the error message points users to a billing setting that the docs explicitly say isn't applicable.

What Should Happen?

It should reply correctly, without rate limiting.

Error Messages/Logs

Steps to Reproduce

1. Install plugin and pair a single-user Telegram bot per the official setup:

/plugin install telegram@claude-plugins-official
/telegram:configure <bot-token>
/telegram:access pair <code>
/telegram:access policy allowlist

1. Launch headless in tmux:

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

1. DM the bot 4-5 short messages in a row.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.92

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_