Summary

Add a first-class persistent task-status surface for long-running channel turns (Discord first, generic abstraction later).

Current typing indicators, partial streaming, narration, and heartbeat-style updates help, but they do not provide a single authoritative status surface that tells the user whether a task is still working, waiting, done, failed, or interrupted.

Problem

For multi-step or multi-minute tasks on chat surfaces, users often cannot distinguish:

• still running
• waiting on some internal follow-up
• stuck
• interrupted by restart/disconnect
• or fully done

Periodic narration and fixed-interval heartbeats can help, but they add message noise and still do not provide one durable status object to look at.

Discord typing is also not a sufficient contract by itself:

• it expires
• it can disappear during long work
• it can also get stuck or otherwise mislead the user
• it does not model terminal states like done, failed, or unknown

Proposed behavior

For channels that support message editing (Discord first would already be useful):

• Create one bot-authored status message near the start of a run if the task exceeds a short delay.
• Edit that same message in place as the run progresses.
• Keep it session/thread scoped rather than creating a stream of separate progress messages.
• End in an explicit terminal state.

Suggested states:

• working
• thinking
• using tools
• composing
• waiting
• done
• failed
• unknown / interrupted

The unknown / interrupted state matters a lot: after restart, disconnect, or uncertain ownership, the system should fail closed instead of implying that work is still active.

Why this feels distinct from adjacent issues

• [Feature]: Feature Request: Configurable fixed-interval progress heartbeat for long-running tasks (e.g. every 60s)  #46851 asks for a fixed-interval progress heartbeat. Useful, but a heartbeat ticker is not the same thing as a single durable task-status surface.
• Feature request: Mid-stream message injection (soft steer) #10960 is about mid-stream injection / soft steer. Related, but different.
• Older narration/progress issues focus on more visibility in general. This request is narrower and more structural: one authoritative editable status surface with explicit terminal semantics.

Important implementation constraint

I tried a local proof-of-concept against the installed runtime just to pressure-test the UX shape. The editable-status-message model felt promising, but it also exposed a safety requirement that a real implementation should encode from day one:

Status transport must be best-effort only.

If the provider send/edit call fails (network issue, permission issue, rate limit, provider outage, etc.), that failure must not block the main reply finalizer, queue unlock, or follow-up scheduling.

In other words:

• status updates should be swallowed/logged on failure
• terminal status delivery must never be allowed to skip the normal completion path

That seems like the main architectural trap to avoid.

Acceptance criteria

1. One status surface per active run/thread/session on channels that support editing.
2. Short delay before showing it, so quick turns do not create noise.
3. Update on meaningful milestones, not every token.
4. Works across long tool phases and internal follow-up turns.
5. After restart/disconnect/uncertain ownership, clears or degrades to unknown instead of pretending the run is still active.
6. Provider send/edit failures are non-fatal and cannot block final reply completion or queue finalization.
7. Channel-gated rollout is fine; Discord first would already be valuable.
8. Configurable/optional if needed.

Why this matters

This would reduce the "is it still working?" ambiguity without relying on fake perpetual typing or chat spam.

It also gives users a clearer lifecycle contract:

• accepted
• still active
• waiting
• finished
• failed
• interrupted / unknown

Environment / context

• OpenClaw 2026.3.13
• Long-running multi-step tasks on chat surfaces such as Discord

Related issues

• [Feature]: Feature Request: Configurable fixed-interval progress heartbeat for long-running tasks (e.g. every 60s)  #46851
• Feature request: Mid-stream message injection (soft steer) #10960
• Discord typing indicator persists after agent run completes #27926
• Discord: persistent 'typing' indicator not cleared when streaming=block mode is active #26961
• Typing indicator stops during long tool executions #447

Not asking for a local dist-bundle patch approach here — this needs a proper runtime/source implementation.