args is not defined — should be params

The sendPoll block references args throughout (e.g., args.to, args.question, args.options), but the function parameter is named params (line 74). Every other action block in handleTelegramAction correctly uses params. This will cause a ReferenceError at runtime when the sendPoll action is invoked.

Additionally, const accountId on line 353 shadows the outer accountId (line 78), which is inconsistent with all other action blocks that reuse the outer-scope accountId.

All args.* references need to be changed to params.*, and the re-declaration of accountId should be removed in favor of the existing outer-scope variable. For example:

This is a comment left during a code review.
Path: src/agents/tools/telegram-actions.ts
Line: 332:353

Comment:
**`args` is not defined — should be `params`**

The `sendPoll` block references `args` throughout (e.g., `args.to`, `args.question`, `args.options`), but the function parameter is named `params` (line 74). Every other action block in `handleTelegramAction` correctly uses `params`. This will cause a `ReferenceError` at runtime when the `sendPoll` action is invoked.

Additionally, `const accountId` on line 353 shadows the outer `accountId` (line 78), which is inconsistent with all other action blocks that reuse the outer-scope `accountId`.

All `args.*` references need to be changed to `params.*`, and the re-declaration of `accountId` should be removed in favor of the existing outer-scope variable. For example:

```suggestion
    const to = params.to as string | undefined;
    if (!to) {
      throw new Error("sendPoll requires 'to' (chat ID)");
    }
    const question = (params.question ?? params.pollQuestion) as string | undefined;
    if (!question) {
      throw new Error("sendPoll requires 'question'");
    }
    const options = (params.options ?? params.pollOption) as string[] | undefined;
    if (!options || options.length < 2) {
      throw new Error("sendPoll requires at least 2 options");
    }
    const maxSelections =
      typeof params.maxSelections === "number" ? params.maxSelections : undefined;
    const isAnonymous =
      typeof params.isAnonymous === "boolean" ? params.isAnonymous : undefined;
    const silent = typeof params.silent === "boolean" ? params.silent : undefined;
    const replyToMessageId =
      typeof params.replyTo === "number" ? params.replyTo : undefined;
    const messageThreadId =
      typeof params.threadId === "number" ? params.threadId : undefined;
```

How can I resolve this? If you propose a fix, please make it concise.

Missing action gate check for sendPoll

Every other action in this function checks isActionEnabled(...) before proceeding (e.g., sendMessage checks isActionEnabled("sendMessage"), deleteMessage checks isActionEnabled("deleteMessage"), sendSticker checks isActionEnabled("sticker", false)). The sendPoll block is missing this check. Without it, even if actions.poll: false is set in configuration, the action handler will still process sendPoll if called directly, bypassing the adapter's listActions gate.

Consider adding a gate check consistent with the other actions:

This is a comment left during a code review.
Path: src/agents/tools/telegram-actions.ts
Line: 331:331

Comment:
**Missing action gate check for `sendPoll`**

Every other action in this function checks `isActionEnabled(...)` before proceeding (e.g., `sendMessage` checks `isActionEnabled("sendMessage")`, `deleteMessage` checks `isActionEnabled("deleteMessage")`, `sendSticker` checks `isActionEnabled("sticker", false)`). The `sendPoll` block is missing this check. Without it, even if `actions.poll: false` is set in configuration, the action handler will still process `sendPoll` if called directly, bypassing the adapter's `listActions` gate.

Consider adding a gate check consistent with the other actions:
```suggestion
  if (action === "sendPoll") {
    if (!isActionEnabled("poll")) {
      throw new Error("Telegram poll is disabled via actions.poll.");
    }
```

How can I resolve this? If you propose a fix, please make it concise.

The TelegramActionConfig type is missing a poll field, which means the action gate check will always use the default value. For consistency with Discord (polls?: boolean; in DiscordActionConfig) and WhatsApp (polls?: boolean; in WhatsAppActionConfig), the Telegram config should include a poll field.

Update src/config/types.telegram.ts to add:

export type TelegramActionConfig = {
  reactions?: boolean;
  sendMessage?: boolean;
  deleteMessage?: boolean;
  editMessage?: boolean;
  sticker?: boolean;
  poll?: boolean;  // Add this line
};

Note: Discord and WhatsApp use polls (plural), but since Telegram already uses singular forms for other actions (sticker not stickers, reaction not reactions), using poll (singular) is consistent with Telegram's existing convention.

The options parameter should be marked as required when used as a fallback. Currently, if pollOption is undefined, the code reads options without the required: true flag, which could result in options being undefined. This would cause validation to fail later in handleTelegramAction, but it's better to fail early with a clear error message.

Consider updating line 208 to:

const options = readStringArrayParam(params, "pollOption") ?? readStringArrayParam(params, "options", { required: true });

This matches the pattern used for the question parameter on line 207 and follows the principle of failing fast with clear error messages.

The poll action handler is missing support for Telegram-specific poll parameters that are available via CLI and low-level action calls:

1. pollMulti / allowMultiselect - to enable multiple selections
2. pollDurationSeconds - Telegram supports poll duration in seconds (5-600)
3. pollAnonymous / pollPublic - to control poll anonymity (Telegram-specific)

These parameters are supported by the underlying handleTelegramAction("sendPoll", ...) handler (see lines 344-347 in telegram-actions.ts) and are used in the message-action-runner (lines 574-593), but they're not being extracted and passed through from the action adapter.

Consider adding these parameters to ensure feature parity:

const allowMultiselect = typeof params.pollMulti === "boolean" ? params.pollMulti : undefined;
const durationSeconds = readNumberParam(params, "pollDurationSeconds", { integer: true });
const pollAnonymous = typeof params.pollAnonymous === "boolean" ? params.pollAnonymous : undefined;
const pollPublic = typeof params.pollPublic === "boolean" ? params.pollPublic : undefined;
const isAnonymous = pollAnonymous ? true : pollPublic ? false : undefined;
const maxSelections = allowMultiselect && options ? Math.max(2, options.length) : 1;

Then include these in the handleTelegramAction call: maxSelections, durationSeconds, isAnonymous.

The sendPoll action handler is missing support for poll duration parameters. The PollInput type accepts both durationSeconds and durationHours, but the handler only extracts maxSelections (line 357).

To support poll duration for Telegram polls (which use durationSeconds with a range of 5-600 seconds), the handler should:

1. Extract durationSeconds from args:

const durationSeconds = typeof args.durationSeconds === "number" ? args.durationSeconds : undefined;

2. Pass it to the PollInput object:

{ question, options, maxSelections, durationSeconds }

This would enable CLI commands like:

openclaw message poll --channel telegram --to <chat> --poll-question "Q" --poll-option "A" --poll-option "B" --poll-duration-seconds 300

The sendPoll action handler is using an undefined variable args instead of the function parameter params. This will cause a runtime error when the action is invoked.

All references to args in this block should be changed to params:

• Line 332: args.to → params.to
• Line 336: args.question ?? args.pollQuestion → params.question ?? params.pollQuestion
• Line 340: args.options ?? args.pollOption → params.options ?? params.pollOption
• Line 344: args.maxSelections → params.maxSelections
• Line 346: args.isAnonymous → params.isAnonymous
• Line 348: args.silent → params.silent
• Line 349: args.replyTo → params.replyTo
• Line 351: args.threadId → params.threadId
• Line 353: args.accountId → params.accountId

This is consistent with all other action handlers in the same file, which use params.