BUG: Telegram allow_from with numeric user ID does not work when the user has a username

[ackness]

Summary

Telegram messages are rejected by allow_from even when the configured value is the correct user ID (as a string), if the sender has a Telegram username.

Environment

• Project: picoclaw
• Command: picoclaw gateway (also reproducible with --debug)
• Config uses allow_from as documented

Config

{
  "channels": {
    "telegram": {
      "enabled": true,
      "token": "REDACTED",
      "allow_from": ["123456789"]
    }
  }
}

Steps to reproduce

1. Enable Telegram channel with a valid bot token.
2. Set allow_from to a numeric Telegram user ID string (e.g. "123456789").
3. Start gateway.
4. Send a message to the bot from that Telegram account.

Actual behavior

• The bot does not process/reply to the message.
• With --debug, logs show the message is rejected by allowlist.

Expected behavior

• A numeric user ID string in allow_from should allow that user’s messages, as shown in docs/examples.

Suspected cause

Telegram sender ID is constructed as "<id>|<username>" when username exists, but allowlist matching is strict string equality.
So "123456789" does not match "123456789|myusername".

Workarounds

• Set allow_from to "<id>|<username>", or
• Leave allow_from empty (allow all users).

Suggested fix

Match Telegram allowlist primarily against pure user.ID (string), and optionally keep backward compatibility for "<id>|<username>" entries.

Code references

1. Telegram sender ID is built as id|username:
   

   picoclaw/pkg/channels/telegram.go

   Lines 164 to 167 in 13fcbe6

   	senderID := fmt.Sprintf("%d", user.ID)
   	if user.Username != "" {
   	senderID = fmt.Sprintf("%d|%s", user.ID, user.Username)
   	}

2. Allowlist check is strict string equality:
   

   picoclaw/pkg/channels/base.go

   Lines 45 to 52 in 13fcbe6

   	func (c *BaseChannel) IsAllowed(senderID string) bool {
   	if len(c.allowList) == 0 {
   	return true
   	}
   	for _, allowed := range c.allowList {
   	if senderID == allowed {
   	return true

[carzygod]

Meet same issue here .

[banghasan]

finally.. thx u

[huaaudio]

Resolved in #83

[wglnngt]

same as feishu.