Summary
When a user message triggers an internal sessions_spawn subagent run, the main session may already send a successful reply, but Telegram continues showing typing for a long period (e.g. ~65s) until the internal subagent finishes. In many cases, no second user-visible message is sent.
This creates a confusing UX:
- user receives a valid reply
- typing continues as if assistant is still composing another reply
- typing disappears without additional output
Environment
- OpenClaw:
2026.2.24 (stable)
- Channel: Telegram (direct chat)
- Gateway: local loopback (
127.0.0.1:18789)
- Observed on Linux host
Timeline (example)
08:10:00 user sends message
08:10:09 main session triggers sessions_spawn (internal sub-session created)
08:10:22 main session reply delivered to user
08:10:22 ~ 08:11:21 Telegram typing indicator remains active
08:11:21 internal sub-session completes; typing disappears
- no second message is delivered
Expected behavior
After the main user-visible reply is delivered, typing should be cleared unless there is an explicit pending user-visible follow-up message.
Actual behavior
Typing remains active while internal background/subagent work is still running, even if no follow-up message will be sent.
Impact
- Misleads users into waiting for a second message
- Feels like "stuck typing" / "ghost reply"
- Especially bad in production Telegram workflows
Suspected area
- Typing lifecycle around
sessions_spawn / follow-up queue
- Idle/cleanup path not decoupled from internal background run state
Suggested fixes
- Decouple typing state from internal subagent lifecycle once a final user-visible message is sent.
- Add hard timeout for typing indicator renewal in Telegram path.
- Only keep typing alive if a concrete outbound user message is pending.
- Add structured logs for typing start/renew/clear with
sessionKey + runId for easier diagnosis.
Notes
This is reproducible in real usage where main chat dispatches internal subagent runs for operational tasks.
Related: #27317 (sub-agent silent message drop when output exceeds Telegram 4096-char limit) — that issue covers the "no reply at all" case; this issue covers the "typing indicator leak" even when a reply was successfully sent.
Summary
When a user message triggers an internal
sessions_spawnsubagent run, the main session may already send a successful reply, but Telegram continues showing typing for a long period (e.g. ~65s) until the internal subagent finishes. In many cases, no second user-visible message is sent.This creates a confusing UX:
Environment
2026.2.24(stable)127.0.0.1:18789)Timeline (example)
08:10:00user sends message08:10:09main session triggerssessions_spawn(internal sub-session created)08:10:22main session reply delivered to user08:10:22 ~ 08:11:21Telegram typing indicator remains active08:11:21internal sub-session completes; typing disappearsExpected behavior
After the main user-visible reply is delivered, typing should be cleared unless there is an explicit pending user-visible follow-up message.
Actual behavior
Typing remains active while internal background/subagent work is still running, even if no follow-up message will be sent.
Impact
Suspected area
sessions_spawn/ follow-up queueSuggested fixes
sessionKey+runIdfor easier diagnosis.Notes
This is reproducible in real usage where main chat dispatches internal subagent runs for operational tasks.
Related: #27317 (sub-agent silent message drop when output exceeds Telegram 4096-char limit) — that issue covers the "no reply at all" case; this issue covers the "typing indicator leak" even when a reply was successfully sent.