Auto-mode classifier denies the Telegram plugin's own reply tool as "Unrequested Commit in a Connected App" when answering an inbound Telegram message

Summary

In auto mode, with the official Telegram channel plugin attached, the auto-mode classifier denied the plugin's own mcp__plugin_telegram_telegram__reply tool while Claude was answering a message the user had just sent from Telegram. The denial reason was [Unrequested Commit in a Connected App]. The reply was the requested action: the inbound <channel source="plugin:telegram:telegram"> message is the request, and the plugin's instructions say that tool is the only way to answer it. Two turns later the identical call, same chat_id, same kind of plain-text content, no permission rule yet in effect, was allowed. So the classification is both wrong for this tool and non-deterministic.

A Stop hook in my setup (a Telegram/terminal parity check) then insisted the Telegram reply be sent, so the harness was pushing in two directions at once. That part is my hook, not Claude Code's, but it illustrates the cost: the denial forces the model to choose between a user-visible channel going silent and a rule it has been told not to route around.

Environment

• Claude Code 2.1.292, macOS (darwin arm64), model claude-fable-5-1
• Permission mode: auto
• Plugin: telegram (claude-plugins-official), channel attached; DMs allowlisted
• Date: 2026-10-06, about 13:59 PDT (denied) and 14:05 PDT (allowed)

Steps to reproduce

1. Start a session in auto mode with the Telegram channel plugin attached and a DM allowlisted.
2. Send any message to the session from Telegram.
3. Have Claude answer with mcp__plugin_telegram_telegram__reply, passing the inbound chat_id and short plain text (no files, format omitted).
4. Observe the classifier denial [Unrequested Commit in a Connected App]. It is intermittent; a retry may be allowed.

Expected

A reply to an inbound message on the channel the message arrived on is the requested action and should not be classified as an unrequested commit. At minimum the verdict should be stable across identical calls.

Actual

Denied once with the reason above; the identical call allowed shortly after with no configuration change in between.

Notes

• Workaround that works: a permissions.allow entry for mcp__plugin_telegram_telegram__reply. It should not be needed for a plugin whose purpose is to reply.
• The denial text also instructs the model not to pursue the same outcome through another tool or a later turn, which in this case means "do not answer the user", so the misclassification is not recoverable by the model on its own.