Summary
On the staging build, the "Use your own Bot Token" Telegram path is broken end-to-end. Every message triggers repeated "🔒 This bot requires operator approval" prompts, no agent reply is ever delivered, and the duplicate count grows with each message. The "Login with OpenHuman" path works correctly and is unaffected.
Problem
This is a regression of #1948 (closed as fixed in v0.53.x). The new behaviour is worse:
This pattern — increasing duplicate count across messages — points to a listener or subscription being registered on each inbound message without being deregistered, so each new message is handled by an increasing number of handler instances.
UI shows Connected throughout when the bot token path is active, confirming the session is established but the approval-state resolution is broken.
Scope
| Path |
Status |
Working? |
| Login with OpenHuman |
Connected |
✅ Works correctly |
| Use your own Bot Token |
Disconnected → Connected |
❌ Broken — approval loop, no agent reply |
The bug is isolated to the bot token path. The shared Telegram path (Login with OpenHuman) is unaffected, which narrows the root cause to the bot-token-specific connection, polling, and approval-gate code paths.
Steps to reproduce
- Settings → Connections → Telegram
- Ignore "Login with OpenHuman" (working) — scroll to "Use your own Bot Token"
- Paste a bot token from @Botfather; optionally fill Chat ID and Allowed Users
- Click Connect — status becomes Connected
- In Telegram, send `/start` → receive approval prompt
- Send any further message (e.g. `wassup`, `hi`)
- Observe: approval prompt fires again per message; no agent reply; duplicate count grows
Expected behaviour
- After connecting with a bot token, messages from users in Allowed Users (or the first sender after `/start`) route to the OpenHuman agent and receive a reply.
- The approval prompt fires at most once for a new/unapproved sender — never on repeat for the same session.
- No duplicate messages.
Actual behaviour (staging)
- Every message triggers `🔒 This bot requires operator approval` + `ℹ️ If operator provides a one-time pairing code, run /bind
`
- No agent reply is delivered at any point
- Duplicate count grows per message (`hi` → 2× each vs `wassup` → 1×)
Hypothesis
Two compounding issues, both specific to the bot token path:
-
Approval state not persisting / stale read — The approval gate re-evaluates on every message and never resolves to "approved", even when UI shows Connected. The Allowed Users list or pairing state is either not written on connect or read from a stale scope in the bot-token handler (the Login with OpenHuman path resolves this correctly, so the shared approval logic is likely fine — the bug is in how the bot-token path writes/reads session state).
-
Listener leak (growing duplicate count) — The bot-token update poller registers a new handler per inbound message without deregistering the old one (structurally similar to #1948 and #1648). Each message is processed by N+1 handlers, producing N+1 approval responses.
Environment
- Build: staging
- Channel: Telegram → Use your own Bot Token
- "Login with OpenHuman" path: working correctly (unaffected)
- Platform: macOS (confirmed from screenshot)
Acceptance criteria
Related
- Original duplicate-approval bug (closed, now regressed): #1948
- Reply duplication fix referenced in #1948: #1648
- Telegram + Discord channels broken (closed): #3712
Summary
On the staging build, the "Use your own Bot Token" Telegram path is broken end-to-end. Every message triggers repeated "🔒 This bot requires operator approval" prompts, no agent reply is ever delivered, and the duplicate count grows with each message. The "Login with OpenHuman" path works correctly and is unaffected.
Problem
This is a regression of #1948 (closed as fixed in v0.53.x). The new behaviour is worse:
This pattern — increasing duplicate count across messages — points to a listener or subscription being registered on each inbound message without being deregistered, so each new message is handled by an increasing number of handler instances.
UI shows Connected throughout when the bot token path is active, confirming the session is established but the approval-state resolution is broken.
Scope
The bug is isolated to the bot token path. The shared Telegram path (Login with OpenHuman) is unaffected, which narrows the root cause to the bot-token-specific connection, polling, and approval-gate code paths.
Steps to reproduce
Expected behaviour
Actual behaviour (staging)
`Hypothesis
Two compounding issues, both specific to the bot token path:
Approval state not persisting / stale read — The approval gate re-evaluates on every message and never resolves to "approved", even when UI shows Connected. The Allowed Users list or pairing state is either not written on connect or read from a stale scope in the bot-token handler (the Login with OpenHuman path resolves this correctly, so the shared approval logic is likely fine — the bug is in how the bot-token path writes/reads session state).
Listener leak (growing duplicate count) — The bot-token update poller registers a new handler per inbound message without deregistering the old one (structurally similar to #1948 and #1648). Each message is processed by N+1 handlers, producing N+1 approval responses.
Environment
Acceptance criteria
Related