Telegram OpenAPI Skill
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Anyone or any agent workflow using the token can act as the Telegram bot within the bot's permissions.
The skill requires a Telegram bot token, which authorizes actions as that bot. This is expected for Telegram Bot API use, but it is still account authority that should be protected.
A Telegram bot token from BotFather.
Use a dedicated bot token, limit the bot's chat/channel privileges, avoid sharing the token, and rotate it if exposed.
The agent could post messages or media to chats the bot can access if directed or if a workflow invokes these commands.
The skill exposes Telegram write operations such as sending messages. The documentation frames these as actions to confirm first, so this is purpose-aligned but still user-impacting.
## Write Examples (Confirm Intent First) # Send a text message telegram-openapi-cli post:/sendMessage
Review chat IDs, message contents, and media paths before allowing write operations, especially for public channels or group chats.
Switching between webhook and polling can change how the bot receives updates and may interrupt another running bot process.
The skill documents webhook deletion and polling setup. This is correct for Telegram behavior, but changing webhook state can disrupt an existing bot integration.
getUpdates and webhook delivery are mutually exclusive: - if a webhook is configured, call `post:/deleteWebhook` before polling with `post:/getUpdates`
Confirm the bot is not used by another production service before deleting or changing webhooks, and keep `drop_pending_updates` false unless you intentionally want to discard updates.
A polling subscription may keep running, consume bot updates, and write incoming update data to a local file until stopped.
The skill includes a daemon-backed polling example that continues collecting Telegram updates and writing them to a local file sink. This is disclosed and aligned with polling-based reads.
uxc subscribe start https://api.telegram.org post:/getUpdates ... --mode poll ... --sink file:/tmp/telegram-updates.ndjson
Run polling only when needed, use an appropriate sink path, protect any stored update logs, and stop the subscription when finished.
If a webhook is set to the wrong endpoint, Telegram updates for the bot could be sent to an unintended service.
The skill can configure Telegram webhooks, causing Telegram update data to be delivered to a specified HTTPS endpoint. This is expected webhook functionality, but the destination must be trusted.
telegram-openapi-cli post:/setWebhook url=https://example.com/telegram-webhook certificate=/tmp/public.pem secret_token=secret123
Use only trusted webhook URLs, use a strong secret token rather than example values, and verify webhook status after changes.
If the remote schema changes unexpectedly, the linked CLI behavior could differ from the reviewed artifact.
The user-directed setup links a CLI to a remote OpenAPI schema fetched from GitHub's main branch. This is disclosed, but it is less pinned than using the bundled schema or a commit-specific URL.
uxc link telegram-openapi-cli https://api.telegram.org --schema-url https://raw.githubusercontent.com/holon-run/uxc/main/skills/telegram-openapi-skill/references/telegram-bot.openapi.json
Prefer the bundled schema or a pinned commit URL for repeatable behavior, and review schema changes before relinking.
