NanoClaw
NanoClaw adds multiple Telegram bots to one host
NanoClaw’s Telegram work adds named bot instances, instance-bound pairing and a setup path that can add another bot without disturbing the first. The stack reports live two-bot verification while keeping single-token installs unchanged.
nanocoai/nanoclaw PR #3438 is the inspected primary source: “feat(setup): the wizard offers "add another Telegram bot" when one is already configured.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- nanocoai/nanoclaw PR #3438 was created 2026-08-21T19:10:27Z and was open at inspection; its title is “feat(setup): the wizard offers "add another Telegram bot" when one is already configured.” - nanocoai/nanoclaw PR #3437 was created 2026-08-21T19:09:50Z and was open at inspection; its title is “docs(add-telegram): add-another-bot path, instance-aware pairing and wiring.” - nanocoai/nanoclaw PR #3436 was created 2026-08-21T19:07:33Z and was open at inspection; its title is “feat(telegram): named bot instances via TELEGRAM_INSTANCES + instance-bound pairing.” - The repository reported 30593 stars, 934 open issues, default branch main, and last push 2026-08-21T20:31:45Z. - The latest tagged-release baseline checked was v2.2.0 published 2026-08-13T20:43:27Z.
What changed
nanocoai/nanoclaw PR #3438 reports: Type of Change [ ] **Feature skill** - adds a channel or integration (source code changes + SKILL.md) [ ] **Utility skill** - adds a standalone tool (code files in.claude/skills/ /, no source changes) [ ] **Operational/container skill** - adds a workflow or agent skill (SKILL.md only, no source changes) [ ] **Fix** - bug fix or security fix to source code [ ] **Simplification** - reduces or simplifies source code [ ] **Documentation** - docs, README, or CONTRIBUTING changes only No box fits: a small setup-wizard feature on an existing seam, no new skill. Description The setup wizard asks "Use the existing bot / Add another bot" when a Telegram token is already configured, then runs the same add-telegram fences. Installs without a token see no change. Why.** People will try to add a second bot from setup. The per-channel pre-step seam already exists (registerChannelPreStep, used by Slack); a Telegram pre-step that answers the skill's own prompts keeps wizard, agent and ncl on one mechanism. What changed.** New setup/channels/telegram-pre-step.ts, registered in companions.ts. No token: returns undefined. Otherwise one select; "add" asks a short name (validated, refused if its token key already exists) and returns { add_another, bot_name, bot_token }; "keep" returns { add_another: 'no', bot_token }. Pre-binding the stored token (read with the host's readEnvFile) means the wizard
nanocoai/nanoclaw PR #3437 reports: Type of Change [ ] **Feature skill** - adds a channel or integration (source code changes + SKILL.md) [ ] **Utility skill** - adds a standalone tool (code files in.claude/skills/ /, no source changes) [ ] **Operational/container skill** - adds a workflow or agent skill (SKILL.md only, no source changes) [ ] **Fix** - bug fix or security fix to source code [ ] **Simplification** - reduces or simplifies source code [x] **Documentation** - docs, README, or CONTRIBUTING changes only (Closest box: SKILL.md, its fixtures, and a test that drives the document; no engine code.) Description Re-running /add-telegram on an install that already has a bot now offers "add another bot". First install unchanged. Why.** The skill only knew the first-bot flow; a rerun re-paired the same bot. The skill engine branches on a prompt variable in document order (when: guards), so the second-bot path fits in the same document and setup, the agent and ncl produce one install. What changed** (.claude/skills/add-telegram/SKILL.md). A probe captures has_default_bot; on a rerun a prompt asks add_another (yes/no). The "create the bot" note is skipped on reruns. Everything else on the first-bot path is untouched. when:add_another=yes: name (^[a-z0-9][a-z0-9-]*$), refuse a name whose token key is already set, second token (its own prompt, never offered the first token), getMe, refuse a token that is
nanocoai/nanoclaw PR #3436 reports: Type of Change [x] **Feature skill** - adds a channel or integration (source code changes + SKILL.md) [ ] **Utility skill** - adds a standalone tool (code files in.claude/skills/ /, no source changes) [ ] **Operational/container skill** - adds a workflow or agent skill (SKILL.md only, no source changes) [ ] **Fix** - bug fix or security fix to source code [ ] **Simplification** - reduces or simplifies source code [ ] **Documentation** - docs, README, or CONTRIBUTING changes only (Closest box: update to the existing Telegram payload on channels plus a doc skill.) Description Run several Telegram bots on one host. Same shape as Slack: Why.** The engine already routes and delivers per instance (#2733). The Telegram payload registered only one key, and its pairing store and interceptor could not tell bots apart: a wrong code sent to one bot cancelled every pending pairing, and a chat paired on a second bot would have overwritten the first bot's row. Explicit list rather than auto-discovering TELEGRAM_BOT_TOKEN_*: a stray duplicate token never starts a second poller, and main needs no change. What changed.** telegram.ts: createTelegramBridge({ envKeySuffix, instanceKey }) (mirrors createSlackBridge); default registration is the zero-suffix call; TELEGRAM_INSTANCES loop registers telegram- with the same defaults; a token for a bot already claimed is skipped with a warning (one poller per bot).
Why it matters
Multi-bot support is an identity problem before it is a setup feature. Tokens, pollers, pairing codes, database rows and delivery routes must agree on which bot owns the interaction. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.
Current
The primary record was open when captured on 2026-08-22. The tagged-release baseline was v2.2.0 published 2026-08-13T20:43:27Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/nanocoai/nanoclaw/pull/3438. Supporting records are https://github.com/nanocoai/nanoclaw/pull/3437 and https://github.com/nanocoai/nanoclaw/pull/3436. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Require explicit instance names, deduplicate tokens, bind pairing and rows to the instance, and verify each bot replies through its own route after restart. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.