fix(chat): require per-channel sender allowlist for inbound commands

[jtalborough]

Summary

Adds a fail-closed, per-channel sender allowlist so only authorized senders can drive agents through chat channels (Telegram / Lark / WeChat).

Why (security)

dispatch_command currently routes purely on the command verb — the inbound sender_id is logged and used for per-sender context, but it is never authorized. The chat commands it routes to are not read-only: /task spawns and drives an agent with the host's full tool access, and /approve always enables auto-approval that removes the human-in-the-loop for subsequent tool calls.

The practical consequence: anyone who can message the bot (e.g. anyone who finds a Telegram bot's handle, or is in a group it's added to) can run arbitrary tasks → effectively unauthenticated remote code execution on the host, especially for an always-on / internet-reachable deployment. chat_id only scopes outbound messages; inbound getUpdates delivers from any chat.

What this does

• A fail-closed authorization gate at the top of dispatch_command (one place → covers all backends). Only sender ids listed in the channel's config_json.allowed_senders may drive the bot.
• Empty/unset allowlist authorizes no one. A blocked sender is replied with their own sender id so the operator can add it from the channel settings.
• chat_channel/authz.rs — pure is_sender_allowed() with unit tests.
• Unauthorized reply is localized (all 10 languages).
• "Allowed Sender IDs" field added to the add/edit channel dialogs.

Validation

cargo test/cargo clippy -D warnings (server mode) and eslint pass.

Notes

• The new dialog field labels are English-only for now — happy to wire them through i18n/messages/* if you'd prefer that before merge.
• Discovered while hardening a self-hosted deployment; reporting with the fix attached rather than as a bare issue. Glad to coordinate on disclosure/versioning however you prefer.

🤖 Generated with Claude Code

[xintaofei]

First off — thank you for this. 🙏 Reporting a real authorization gap with the fix attached (plus unit tests and fully localized replies) is exactly the kind of contribution we love to get. The design is solid: fail-closed by default, a single gate in dispatch_command that covers all three backends at once, authentic per-platform sender IDs, and config read fresh from the DB so allowlist edits take effect without a restart. Really nice work.

I went through it carefully (and had a second reviewer double-check the security-sensitive parts). Here's where it stands — a few things to sort out before we merge, mostly because main has moved since you opened this.

1. Rebase needed — and it's security-relevant, not just textual

command_dispatcher.rs got a sizable rewrite on main (interactive button callbacks, forum-topic follow-ups), so GitHub shows conflicts. The part that matters: dispatch_command now starts with

if let Some(data) = callback_data {
    return DispatchResponse::current(handle_callback(...), target);
}

Your gate is anchored just before the // Strip prefix comment, which now sits below that callback branch. Rebased mechanically, interactive folder/agent picker callbacks would slip past the gate. Could you move the authorization check to the very top of dispatch_command, above the callback_data branch, so the one gate dominates everything?

Severity here is genuinely low — handle_callback only does cfg:folder: / cfg:agent: selection, so the /task and /approve RCE vectors stay protected either way — but it's cleanest to close it while rebasing. One more thing to carry through: the Telegram config now also has a topic_mode field, so the dialog's config rebuild should preserve that too.

2. One functional gap worth fixing before this ships for WeChat

The WeChat QR flow (weixin_check_qrcode_core in src-tauri/src/commands/chat_channel.rs) rewrites the whole config_json to { "base_url": ... } on every confirmation. That was harmless before, but now it wipes allowed_senders — so after a WeChat QR (re)auth the allowlist is empty and the channel, correctly and fail-closed, denies everyone, including the operator. Since the UI reconnects right after QR success and disables editing while connected, it's a little painful to recover from (disconnect → edit → reconnect, and it recurs on the next re-auth).

Could the QR path merge base_url into the existing config instead of replacing it, and keep allowed_senders? A small regression test around re-auth would be lovely. (Telegram and Lark aren't affected by this one.)

Non-blocking — take or leave

• The two new dialog labels are English-only. Totally fine as a follow-up to wire through i18n/messages/* — you'd already offered, no need to block on it. 😄
• Lark falls back to the sentinel "unknown" when open_id is absent. Denied by default, so it's just a minor footgun if anyone ever allowlists that literal string; dropping identity-less events would be marginally safer.

---

None of this takes away from the core, which is exactly the protection we want. Happy to help with the rebase or the WeChat config-merge fix if that's easier on your end — just say the word. Thanks again for flagging this and for doing it so thoroughly. 🙌