#10927·zeroclaw

[Bug]: Telegram voice preferences match destination chats instead of sender identities

Author: Audacity88Created Sep 17, 2026Updated Sep 17, 2026
Labelsbugchannelchannel:corechannel:telegrampriority:p2status:in-progressfollow-uprisk:medium

Affected component

channel

Severity

S2 - degraded behavior

Current behavior

Telegram's is_voice_peer and the configured-peer branch of is_voice_chat compare the resolved voice-peer strings directly with the outbound recipient. That recipient is a destination chat address, whereas peer groups identify senders. A numeric identity can coincide with a private-chat address, but a group-chat address does not identify the sender who requested the reply. Literal comparison also does not implement the documented wildcard matching behavior.

Consequently, a sender configured for voice output can receive text in a group because their identity is compared against the group's chat ID. A wildcard peer entry likewise fails a literal comparison with the recipient. This is the source-established Telegram follow-up from #10489; no live Telegram reproduction was run for this report.

Expected behavior

Resolve configured voice preference against the originating sender using the applicable channel's canonical peer-identity matching, then preserve that decision through ordinary and streaming reply delivery. Keep the destination chat and thread as delivery addresses, not substitutes for sender identity. A different member of the group must not determine this sender's reply modality.

Preserve Telegram's existing voice-only behavior for configured voice replies; do not switch it to Matrix's text-plus-voice behavior as part of this repair. Keep explicit suppression authoritative and preserve existing explicit per-message modality overrides. Operational-reply suppression is tracked separately in #10924.

Steps to reproduce

Proposed controlled regression, not yet executed:
1. Configure a Telegram voice peer group containing a permitted sender's numeric user ID.
2. Deliver a message from that sender in a group with a different chat ID.
3. Verify that reply voice eligibility follows the sender's group membership, while delivery retains the group chat/thread address.
4. Repeat with the wildcard peer entry.
5. Include a non-member sender in the same group and ensure another member's voice preference does not apply to them.
6. Cover ordinary send and streaming finalization, suppression, and existing per-message modality overrides.

Impact

Configured sender voice preferences are missed in group replies or wildcard configurations. Correcting the lookup will activate the already-selected voice-only behavior for those users, so the behavioral effect should be called out in the repair. Private numeric-ID behavior should remain compatible.

Logs / stack traces

No response

ZeroClaw version

3df68fb2236c6f089c25005d0ebb780c9c7fd642

Rust version

Not measured; source-based report.

Operating system

Not platform-specific in the inspected code; no live platform reproduction performed.

Regression?

Unknown

Pre-flight checks

  • I reproduced this on the latest master branch or latest release.
  • I redacted secrets, tokens, and personal data from all submitted content.

Scope boundary

This is sender-bound reply routing, not a change to authorization, proactive destination selection, input-driven mirror tracking, TTS content heuristics, or synthesis-failure fallback. Do not infer a sender for proactive messages. Matrix delivery addressing is separately tracked in #10926.