2.1.198: --channels plugin MCP server silently not spawned when --model claude-fable-5 (works on opus-4-8 and on 2.1.197)

Summary

On Claude Code 2.1.198, a session launched with --channels plugin:telegram@claude-plugins-official and --model claude-fable-5 never spawns the channel plugin's MCP server — silently. The identical invocation with --model "claude-opus-4-8[1m]" spawns it fine. Pinning the claude binary back to 2.1.197 also fixes it with fable-5, so it's specific to 2.1.198 (or newer) + fable-5.

Environment

• Claude Code 2.1.198 (native build, macOS 15 / Darwin 25.5.0, Apple Silicon)
• telegram plugin 0.0.6 from claude-plugins-official, user-scope install
• Max plan, headless bots in tmux panes (no channelsEnabled org setting involved — personal account)
• Bun installed; plugin works on other models/versions

Repro

# fails silently on 2.1.198:
TELEGRAM_BOT_TOKEN=<token> TELEGRAM_STATE_DIR=~/.claude/channels/telegram/mybot \
  claude --model claude-fable-5 --permission-mode bypassPermissions \
  --channels plugin:telegram@claude-plugins-official

# works on the same binary:
#   --model "claude-opus-4-8[1m]"           -> plugin server spawns within ~1s
# works with fable-5 on the previous binary:
#   ~/.local/share/claude/versions/2.1.197  -> plugin server spawns within ~1s

Observed (fable-5 + 2.1.198)

• Session boots normally to the composer; other MCP servers (stdio, user-configured) spawn fine.
• The plugin's bun run ... telegram/0.0.6 ... start child process is never created (verified via process table).
• No new log file is created under ~/Library/Caches/claude-cli-nodejs/<cwd>/mcp-logs-plugin-telegram-telegram/.
• No error in the pane, and a claude --debug run prints nothing channel-related at all — the flag appears to be accepted but not acted on.
• The plugin's own state-dir diag log receives no boot line (the plugin logs one immediately on spawn, on every other model/version combination).

Ruled out

• Plugin cache/marketplace state: versions match (0.0.6 both sides), marketplace resolvable; an opus session on the same machine/minute spawns the server from the same cache.
• Pairing/state-dir contents: byte-identical structure to a working bot's.
• Local plugin modifications: the cached plugin carries a small local patch to server.ts (poller-slot arbitration), but an opus session spawns the server from the same patched cache minutes apart, and the failure is upstream of any plugin code executing (the CLI never creates the child process or its log file). Not re-verified against a pristine cache.

Expected

Either the channel plugin spawns under fable-5, or an explicit error/warning is emitted saying channels are unavailable for the selected model. If this is intentional model gating for Fable 5 (safety-tier restrictions on autonomous channels would be understandable), the ask reduces to: emit an explicit message and document it. The silent skip is the painful part — for a headless Telegram-driven bot, the session looks healthy but is unreachable (it answers into its tty and nobody sees it).

Confidence

The failing cell (fable-5 + 2.1.198) reproduced across 5 independent restarts on two different launch mechanisms (manual restart script and an automated watchdog). The passing cells (opus-4-8 + 2.1.198; fable-5 + 2.1.197) are single observations each, but both were first-try successes on the identical launch path minutes apart on the same machine.

Possibly related

• #43585 (channels unavailable at startup despite feature flag enabled and MCP server connected; closed)
• #66657 (Fable 5 safety classifier scoring the static request preamble rather than the user message)