In `--channels` sessions, the reply tool is intermittently never called despite the turn completing with a real, coherent response

Summary

In a --channels plugin:telegram@claude-plugins-official session, a turn can complete successfully (no error, real generated text, stop_reason: end_turn) while calling zero tools at all — no reply, nothing. The generated text is lost; it never reaches the user. This happens intermittently within the same session, alternating with turns that correctly call reply, with no observable difference in the input that would explain why one succeeds and the next doesn't.

This looks related to (but is more specific than) #84157 — that issue was about the channel's MCP server never connecting; this is about tool-calling reliability after a healthy connection, mid-conversation.

This is very likely the same underlying bug as #69988 (auto-closed for inactivity 2026-08-08, not_planned, never actually addressed) — but with an important difference worth re-raising it for: that report's theory was that this only manifests after long --continue sessions with many compaction cycles (60MB transcript, 16 compactions), and that "a fresh session immediately and fully restores correct behavior." My reproduction contradicts that theory being the whole story: it happened on the second message of a brand-new session — no --continue, a fresh --session-id per restart, session age measured in tens of seconds, not days. Session age/compaction may still be a contributing factor that increases frequency, but it isn't required to trigger the bug at all.

Reproduction

Two machines, both on CLI 2.1.239: macOS (Darwin 25.5.0) and Ubuntu 24.04 (systemd-managed daemon, non-root user). Same symptom on both.

Isolated to rule out plugin customization as the cause: the telegram plugin's server.ts was patched with custom instructions on both machines. To rule that out, I swapped one machine to the completely unmodified stock server.ts from claude-plugins-official (verified byte-for-byte, zero custom code) and restarted. Same failure happened on stock, in the same session where a prior message had succeeded:

03:56:32 USER MSG: <channel source="plugin:telegram:telegram" ...>
03:56:34 assistant tool_use: []            <- empty turn, thinking/routing only
03:56:34 assistant tool_use: ['mcp__plugin_telegram_telegram__reply']   <- correctly replies
03:56:35 assistant text: "Sent."
03:57:49 USER MSG: <channel source="plugin:telegram:telegram" ...>
03:57:56 assistant tool_use: []
03:57:59 assistant tool_use: []            <- turn ends with real generated text, ZERO tool calls
                                               text: "Yeah, totally buildable — it's basically two agents (a monit..."
                                               (this text was never delivered anywhere)

Confirmed via the raw session transcript JSONL (~/.claude/projects/<channels-project>/<session-id>.jsonl), not just debug logs — the assistant message for the second turn is content: [{"type": "text", "text": "..."}] with no tool_use block whatsoever, despite the MCP server's own tool-use instructions being unchanged between the two turns.

What's been ruled out

• Not a plugin/patch bug — reproduces identically on completely stock, unmodified server.ts.
• Not stale/backlogged session state — reproduces on fresh sessions with a fresh --session-id.
• Not instruction truncation — the "use the reply tool" instruction is the first array element in the MCP server's stated instructions, well within any truncation limit.
• Not ENABLE_TOOL_SEARCH/deferred tool loading — tested with ENABLE_TOOL_SEARCH=false (forces all tool schemas to load upfront instead of gating reply behind a search Claude might not perform) — no change, still intermittent, just at 6-7x the per-turn API cost from the larger tool-schema payload.
• Not a competing session / guardian process killing anything — verified only one claude --channels process running at any time.

Impact

For an always-on Telegram/Discord-style channel bot, this means conversations silently drop replies at random — from the user's side it looks like the bot "went quiet" for that message, with zero error surfaced anywhere (not in --debug-file, not in the MCP server's logs, nothing). There's no reliable client-side mitigation: a crash-recovery retry mechanism can rescue a dropped reply if the session happens to die and restart afterward, but there's no recovery path when the session stays alive and simply drops a reply mid-conversation, which is the common case.

Environment

• CLI 2.1.239, both claude-sonnet-5 model
• macOS 25.5.0 and Ubuntu 24.04 (VPS, systemd-managed, non-root)
• telegram@claude-plugins-official plugin, both stock 0.0.7 and custom-patched versions
• skipDangerousModePermissionPrompt: true, defaultMode: auto on both