Bug
The daemon opens two concurrent TCP connections to api.telegram.org on startup, causing getUpdates to return 409 Conflict on every poll. Messages still get through via retries, but logs are spammed indefinitely.
Evidence
$ ss -tnp | grep 149.154
ESTAB pid=XXXX,fd=17 → api.telegram.org:443
ESTAB pid=XXXX,fd=18 → api.telegram.org:443
Single daemon process, two connections. Only one should exist for polling.
Reproduction
- 3 agents running identical code, same Bun version, same plugins
- Only one agent consistently has the issue
- Clean restart (stop → delete session.json + daemon.pid → wait 35s → start) does not fix it
- Stopping the daemon and calling
getUpdates manually returns 200 OK — conflict is internal
Root cause (suspected)
startPolling() in src/commands/telegram.ts has no guard against being called twice:
export function startPolling(debug = false): void {
telegramDebug = debug;
(async () => {
await ensureProjectClaudeMd();
await poll();
})().catch((err) => {
console.error(`[Telegram] Fatal: ${err}`);
});
}
If initTelegram() is invoked twice before the first poll() enters its while loop, two polling loops run concurrently.
Suggested fix
let isPolling = false;
export function startPolling(debug = false): void {
if (isPolling) return;
isPolling = true;
// ...
}
Environment
- ClaudeClaw v1.0.0
- Bun 1.3.10
- Debian 12
Bug
The daemon opens two concurrent TCP connections to
api.telegram.orgon startup, causinggetUpdatesto return409 Conflicton every poll. Messages still get through via retries, but logs are spammed indefinitely.Evidence
Single daemon process, two connections. Only one should exist for polling.
Reproduction
getUpdatesmanually returns200 OK— conflict is internalRoot cause (suspected)
startPolling()insrc/commands/telegram.tshas no guard against being called twice:If
initTelegram()is invoked twice before the firstpoll()enters itswhileloop, two polling loops run concurrently.Suggested fix
Environment