Summary

When a Telegram-originated agent turn delegates work to a detached/native subagent and the parent session yields, the user can lose all visible feedback while the child continues running.

From Telegram, these states can look identical:

• the child is still working normally;
• the child is waiting inside a long model request;
• the child is stuck in a long tool call;
• the child is dead/orphaned;
• the child has failed or timed out but the terminal state has not been surfaced yet.

This makes detached subagent work appear unreliable even when the runtime still has internal state and the child is not yet terminal.

Environment

Observed on:

• OpenClaw 2026.6.11
• Gateway uptime: multi-day always-on Docker deployment
• Channel: Telegram
• Runtime: OpenClaw Default
• Model path: openai/gpt-5.5 via OpenAI Codex OAuth
• High-thinking run configuration
• Native detached subagent spawned from a Telegram-originated parent turn

No private workspace paths, chat IDs, user IDs, task names, or session IDs are included here.

Observed behavior

A Telegram message triggered a parent agent turn that delegated work to a detached native subagent. The parent yielded while the child continued.

The child later entered a long openai/gpt-5.5 model request. During that period there was no tool/process activity because the run was waiting inside the model request. The request eventually failed after roughly 15 minutes with a socket-level termination:

TypeError
causeName=SocketError
causeCode=UND_ERR_SOCKET
message=terminated

OpenClaw surfaced this as:

LLM request timed out. rawError=terminated

The terminal event did eventually propagate internally: the subagent was marked failed, the parent received an internal task-completion event, and the parent continued. However, from Telegram the user had no reliable liveness or terminal signal until they manually sent a follow-up status message.

In the same investigation, one runtime artifact reported the child trajectory as successful while the transcript/session state showed the child failed with stopReason:"error" / errorMessage:"terminated". That may be a separate observability bug, but it made the liveness problem harder to diagnose.

Expected behavior

Detached background work spawned from a Telegram-originated turn should have a visible liveness and terminal-notification path.

Recommended behavior:

1. While detached work is active, keep Telegram typing... alive when safe and possible.

2. After a configurable period of silence, send a sparse full-message heartbeat, for example:

   Still working. Current state: child run is waiting on a model response. Last progress: 7 minutes ago.
   

3. On subagent success, failure, timeout, or blocked completion, send a visible terminal message to the originating Telegram chat unless explicitly suppressed.

4. Status? or /status should report active child runs, current phase, last activity time, elapsed time, and known timeout/deadline from deterministic runtime state.

5. Runtime observability should use one consistent terminal source of truth. Trajectory, transcript, session registry, and user-facing status should not disagree about whether a child run succeeded or failed.

Why this matters

Users should not have to manually poke a Telegram session just to learn whether delegated background work is alive. Without a liveness signal, normal long-running work, a hung model request, and a failed child run all look like silence.

This is especially confusing for always-on deployments where Telegram is the primary operator interface.

Non-goals

• Do not send frequent verbose progress spam.
• Do not expose sensitive prompt, tool, model, file, chat, or workspace content in heartbeat messages.
• Do not rely on the model to voluntarily report its own status.
• Do not require the user to send a follow-up message before terminal state becomes visible.

Possible implementation shape

• Track detached subagent activity against the originating Telegram chat/session.
• Maintain metadata-only state: child session key or redacted child id, run id, phase, last activity timestamp, elapsed time, timeout/deadline, and terminal status.
• Use Telegram typing as lightweight liveness while work is active.
• Use rate-limited full-message heartbeats only after suspicious silence.
• Send mandatory terminal messages on success/failure/timeout/blocked completion.
• Make /status or natural-language status requests read from deterministic runtime state, not from model guesses.

Related work

Related issues/PRs that appear adjacent but not sufficient by themselves:

• Subagent lifecycle observability + async supervision controls #38626 — Subagent lifecycle observability + async supervision controls
• [Feature]: Per-session activity state (busy/idle + awaiting_user, awaiting_subagent) via gateway API + WS statechange #39127 — Per-session activity state via gateway API / WS statechange
• [Feature]: Optional session activity watchdog and alerts (blocked by #39127) #39141 — Optional session activity watchdog and alerts
• Feature request: Escalating stall recovery for sub-agents (nudge → kill) #39305 — Escalating stall recovery for sub-agents
• feat(sessions): surface blocked and stale session run statuses #92697 — Surface blocked and stale session run statuses
• feat: show live session activity for running tasks #96672 — Show live session activity for running tasks
• fix: deliver background task completions through owning sessions #97963 — Deliver background task completions through owning sessions
• feat(discord): show subagent progress #95604 — Discord-only subagent progress feedback

The missing piece here is Telegram-visible, non-sensitive liveness and terminal delivery for detached subagent work.