Fable 5 sessions inconsistently gated to "usage credits" despite subscription plan quota — unattended/channels sessions blocked ~80% of the time

ENVIRONMENT

• Claude Code 2.1.215 (pinned, autoupdater disabled), macOS Darwin 25.5 (Apple Silicon)
• Max subscription; plan includes weekly Fable 5 quota (works fine in desktop app and plain interactive terminal sessions on the same machine/account)
• Auth: long-lived OAuth token from claude setup-token (regenerated fresh today — no change in behavior)
• Use case: 24/7 unattended daemon via launchd running claude --model claude-fable-5 --channels plugin:telegram@claude-plugins-official --dangerously-skip-permissions (PTY via script/tmux)

PROBLEM
On the same account, same machine, same binary, and the SAME setup-token, the Fable 5 entitlement check is inconsistent per session:

• Interactive sessions (desktop app, hand-opened terminals): reliably use subscription plan quota. No dialog.
• Unattended daemon/channels sessions: ~80% of sessions (5 of 6 measured on 2026-07-22, PT) hit a BLOCKING modal on their first turn:

"Fable 5 now uses usage credits / Fable 5 runs on usage credits, purchased separately from your plan. / You don't have usage credits yet. / 1. Set up usage credits on claude.ai / 2. Switch to Sonnet 5 and continue"

Evidence that it is per-session server-side bucketing (not config/token):

• 12:13 PT session: replied normally on Fable 5 (plan quota) — same token
• 12:27 PT session: frozen at the credits modal — same token, same everything
• Regenerating the setup-token (fresh browser authorization) did not change the ratio
• claude -p (print mode) probes with the same token always succeed on Fable 5 — only interactive turns hit the gate

IMPACT
For an unattended channels session there is no TTY to answer the modal, so the session freezes permanently. Worse: the Telegram channel poller keeps consuming incoming messages and injecting them into the frozen session, so USER MESSAGES ARE SILENTLY EATEN until an external watchdog kills the session. This makes Fable 5 unusable for any unattended/bridge deployment even though the subscription includes quota.

EXPECTED

1. Entitlement decision should be consistent for the same account/token — if the plan includes Fable 5 quota, unattended sessions should use it like interactive ones do.
2. Regardless of bucketing: headless/channels sessions should NEVER get a blocking interactive modal. Provide a non-interactive behavior (flag or env var, e.g. fail the turn with a clear error, or auto-fallback model) so unattended sessions degrade gracefully instead of freezing and eating messages.

SECONDARY ISSUE (possibly related, same setup)
The channels plugin MCP server (--channels plugin:telegram@claude-plugins-official) is intermittently skipped at startup: no connection attempt at all (no MCP log file created for the plugin, while HTTP MCP servers in the same session initialize fine). Roughly coin-flip per start, with occasional multi-hour windows where every start drops the channel. plugin.json mcpServers manifest present; enabledPlugins set; same behavior across script/tmux PTY wrappers and clean launchd test jobs. We work around it with a startup self-check that kills and retries until the channel registers. Happy to provide debug logs for both issues.

ADDENDUM: Attempted to submit this via Claude Code's built-in /bug — the feedback endpoint returned 403 for a session authenticated with a claude setup-token long-lived OAuth token (the same auth type affected by the entitlement inconsistency described above). Desktop-app-authenticated sessions on the same account work normally.