[Bug]: Cron dashboard should suggest/validate Telegram announce “To” targets from configured groups

[rogerallen1]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When creating/editing a cron job in the web dashboard, Telegram announce delivery is confusing because the To field accepts arbitrary text. I initially entered my agent name (gmail-cleaner) after it offered it, which saved successfully but failed at runtime with:

OutboundDeliveryError: Telegram recipient must be a numeric chat ID

Typing the raw Telegram numeric chat ID manually fixes the job, but the dashboard does not make it clear that To must be a Telegram chat.id such as -1001234567890.

Steps to reproduce

1. Create a cron job in the web dashboard.
2. Set result delivery / announce delivery to Telegram.
3. Set Channel to Telegram.
4. Set To to an agent-ish or configured name such as gmail-cleaner.
5. Save and run the cron job.

Expected behavior

The dashboard should make Telegram delivery targets easier and safer to configure. Possible improvements:

• validate To for Telegram announce delivery before saving
• show helper text that Telegram To must be a numeric chat.id, e.g. -1001234567890
• suggest known/configured Telegram groups/topics from channels.telegram.groups
• if an agent is mapped to exactly one Telegram group/topic, suggest that target
• avoid suggesting or accepting agent names as delivery targets unless they can be resolved

Actual behavior

The job saves, but delivery fails at runtime with:

OutboundDeliveryError: Telegram recipient must be a numeric chat ID

OpenClaw version

2026.6.1

Operating system

ubuntu

Install method

npm

Model

qwen 3.6

Provider / routing chain

lmstudio

Additional provider/model setup details

local

Logs, screenshots, and evidence

Impact and severity

Crons do not accounce

Additional information

The config already contains Telegram group/channel mappings for what the agent can talk to, so it feels like the dashboard should be able to suggest the correct destination or warn when the value is not deliverable.

Have to manually find and type the Telegram chat ID in To

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 16, 2026, 4:48 AM ET / 08:48 UTC.

Summary
Keep open: current main still offers channel account IDs/names as Cron announce recipients and saves arbitrary announce targets; the linked open PR directly owns the canonical conversation-target repair.

Reproducibility: yes. —current source shows that announce suggestions include account IDs/names, announce input receives no corresponding validation, and the raw value is serialized into the Cron delivery payload.

Next step
The linked open PR already owns the focused implementation path, so a second repair job would duplicate active work.

Review details

Best possible solution:

Land a focused Control UI repair that projects the existing Gateway conversation directory into per-agent, channel, and account recipient choices while preserving canonical target/thread pairs and free-form targets where the channel contract allows them.

Do we have a high-confidence way to reproduce the issue?

Yes—current source shows that announce suggestions include account IDs/names, announce input receives no corresponding validation, and the raw value is serialized into the Cron delivery payload.

Is this the best way to solve the issue?

Yes—the existing Gateway conversation directory is a better owner-boundary solution than a Telegram-only numeric regex because it preserves valid nonnumeric Telegram forms plus account and thread identity.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Until the open repair lands, Cron announce delivery can continue to present account names as recipient candidates and persist invalid raw values.

Codex review notes: model internal, reasoning high; reviewed against 32ddbb3be23e.

Label changes

Label justifications:

• P2: This is a bounded existing dashboard defect with a concrete active repair path.
• impact:message-loss: An invalid saved announce recipient can cause the scheduled result delivery to fail.
• impact:ux-friction: The dashboard currently suggests account identities as though they were delivery destinations.

Evidence reviewed

What I checked:

• Current main reproduces the misleading suggestion path: Cron suggestions combine prior job targets with channel account IDs and display names, then expose that list for announce delivery; configured Telegram groups are not consulted. (ui/src/pages/cron/form-suggestions.ts:47, 32ddbb3be23e)
• Announce targets are accepted and serialized without UI validation: The form validates deliveryTo only for webhook mode and serializes the trimmed announce recipient directly into the Cron delivery payload. (ui/src/lib/cron/index.ts:344, 32ddbb3be23e)
• Existing canonical directory supports the requested source of targets: The Gateway discovers configured channel directory entries and preserves their target, account, and thread identity; Telegram’s directory adapter reads channels.telegram.groups. (src/gateway/conversation-list.ts:212, 32ddbb3be23e)
• Telegram’s current target contract is broader than numeric IDs: Telegram normalizes numeric IDs, usernames, and t.me links, with optional topic suffixes; a numeric-only UI validator would reject valid delivery targets. (extensions/telegram/src/targets.ts:63, 32ddbb3be23e)
• Current-source provenance: The relevant current lines trace to the checkout’s shallow history boundary at 717f776; it is contained by current main but not by v2026.7.1-2, so the available source-history evidence is main-only and cannot establish the original introduction. (ui/src/pages/cron/form-suggestions.ts:47, 717f77678a38)
• Canonical open repair: The linked open PR explicitly targets this issue and describes routing Cron suggestions through the existing conversations.list directory while retaining canonical target/thread/account identity. (af87fb666a5c)

Likely related people:

• Peter Steinberger: Current Cron suggestion, Gateway conversation-directory, and Telegram directory lines resolve to the available shallow-history boundary authored by Peter; the trail cannot establish original introduction. (role: recent current-source contributor; confidence: medium; commits: 717f77678a38; files: ui/src/pages/cron/form-suggestions.ts, src/gateway/conversation-list.ts, extensions/telegram/src/directory-config.ts)
• Harjoth Khara: Recent work on authoritative values in Automation-form selects is directly adjacent to the recipient-picker behavior. (role: recent adjacent Control UI contributor; confidence: medium; commits: 115473a59d4f; files: ui/src/pages/cron/view.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.