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:
workingthinkingusing toolscomposingwaitingdonefailedunknown / 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
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
- One status surface per active run/thread/session on channels that support editing.
- Short delay before showing it, so quick turns do not create noise.
- Update on meaningful milestones, not every token.
- Works across long tool phases and internal follow-up turns.
- After restart/disconnect/uncertain ownership, clears or degrades to
unknown instead of pretending the run is still active.
- Provider send/edit failures are non-fatal and cannot block final reply completion or queue finalization.
- Channel-gated rollout is fine; Discord first would already be valuable.
- 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
Not asking for a local dist-bundle patch approach here — this needs a proper runtime/source implementation.
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:
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:
done,failed, orunknownProposed behavior
For channels that support message editing (Discord first would already be useful):
Suggested states:
workingthinkingusing toolscomposingwaitingdonefailedunknown/interruptedThe
unknown/interruptedstate 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
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:
That seems like the main architectural trap to avoid.
Acceptance criteria
unknowninstead of pretending the run is still active.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:
Environment / context
Related issues
Not asking for a local dist-bundle patch approach here — this needs a proper runtime/source implementation.