[Bug]: Telegram forum topic loses ACP/OpenCode routing after heavy bound turn; topic recovers only after gateway restart and then fails again under load
**Title**
Telegram forum topic loses ACP/OpenCode routing after heavy bound turn; topic recovers only after gateway restart and then fails again under load
**Body**
I’m seeing a topic-local failure in OpenClaw’s Telegram ACP thread binding.
Environment:
* Host/runtime: OpenClaw Gateway running locally on Linux (WSL2, kernel 5.15), Node.js v22.22.1; gateway service is `systemd` managed and reported as `running` (`openclaw status`).
* OpenClaw version/channel: stable channel, app/npm latest reported as `2026.3.11` (`openclaw status`).
* Transport: Telegram bot channel enabled, using forum topics in group `-1003351905082` (Waggelgroep); issue reproduced in topic context (this thread is topic `1`).
* Telegram routing config: `channels.telegram.threadBindings.enabled=true` and `channels.telegram.threadBindings.spawnAcpSessions=true` in `~/.openclaw/openclaw.json`.
* Group/topic policy: Telegram group policy is allowlisted (`groupPolicy=allowlist`), messages from authorized sender `5558998798`; routing is topic-aware (forum thread context preserved).
* ACP/OpenCode path: ACP runtime/plugin is enabled (`acpx` enabled in config); sessions are persisted under `~/.openclaw/agents/opencode/sessions/`.
* Session evidence of topic isolation: persisted OpenCode session metadata includes topic-scoped keys (`groupId` values like `-1000000005082:topic:<id>`) and explicit `threadId`, confirming per-topic routing context instead of global group routing.
* Operational symptom: after high-volume / long bound turns in a topic, follow-up messages in the same topic stop routing to the bound ACP/OpenCode session; restarting gateway restores routing temporarily (slash-command work), but the very next message kills it again.
**Strongest evidence from logs**
1. **Message reaches Telegram gateway path**
* OpenClaw logs raw Telegram updates for the bound topic, including ordinary follow-up messages like `"."`.
2. **Message reaches ACP/OpenCode**
* OpenCode loads the persistent session, accepts `POST /session/.../message`, starts `session.prompt step=0`, and resolves tools.
3. **OpenCode remains alive after the topic appears dead**
* OpenCode continues emitting `message.part.updated`, `message.part.delta`, and tool/subagent activity after the handoff point.
4. **Telegram side wedges**
* OpenClaw logs `typing TTL exceeded (60000ms), auto-stopping typing indicator` instead of a normal usable completion in the topic.
**Correlation with heavy turns**
This seems much more likely on complex turns, especially when sub-agent/task delegation is involved. In the logs, heavier runs create a developer subagent session and generate a denser nested event stream. I’m treating this as a correlation, not definitive proof of cause.
**Likely non-causes**
* This does **not** look like “OpenCode never launched”. There are logs proving the bound session received the message and continued processing.
* This does **not** look like simple agent-permission inheritance from the orchestrator. The developer subagent is created and proceeds with its own work; what is denied there is further `task` delegation, not the whole execution path.
* A separate Telegram chunking bug with `---` exists, but that is a different issue; in my case, the more severe failure persists even after isolating around that. Telegram channel settings support different chunking/streaming modes, so this appears distinct from the already-known delivery fragility around formatting/preview. ([[OpenClaw](https://docs.openclaw.ai/channels/telegram?utm_source=chatgpt.com)][1])
**Working theory**
This looks like a bug in the Telegram topic-bound ACP bridge/routing layer inside OpenClaw:
* inbound topic message is accepted,
* bound ACP session receives and processes it,
* but outbound propagation or topic-local routing state wedges under heavier nested event streams,
* and after that the topic may stop reaching OpenClaw at all until gateway restart.