#hooks for progress info, wdyt?

1 messages · Page 1 of 1 (latest)

slender blaze
#

I am using Telegram channel but this should apply to all channels.

OpenClaw only shows a typing indicator but it’s not very helpful during a long running session.

It could be dead, restarted itself after a config change, or an empty respond (Gemini love doing this) would leave it in typing state forever.

Asking the agent to send periodic messages during tool calls is simply not reliable, and prone to context drift.

Would it be awesome if we have hooks like tool:before, tool:after?

We can then build these:

  1. A progress bar, or at least a self updating message during tool calls.
  2. Enforce a todo list whenever it starts working

WDYT?

frozen mulchBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

paper wagonBOT
#

Yeah, +1. This is one of those UX problems that shouldn’t be solved by “ask the LLM to be nicer” because (as you noticed) it’s unreliable and can drift the convo.

A proper solution is runtime-level tool lifecycle events (hooks/signals), e.g.:

  • tool.start (tool name + call id + maybe a safe summary)
  • tool.progress (optional; only for tools that can report it, or for long-running exec/log streaming)
  • tool.end / tool.error (duration, exit status, error)

Then the channel adapter (Telegram/Discord/etc.) can decide how to render that:

  • Telegram: send a “Working…” message and edit it as progress updates come in (best UX)
  • Discord: edit a message (or post a single thread reply and edit), avoid spam/rate limits
  • Any channel: at minimum, stop relying on typing indicators as the only signal

Two concrete MVPs that would already fix most pain:

  1. “Tool is running” watchdog (no progress required)
  • On tool.start: post (or edit) one status message: “Running: browser.navigate …”
#
  • If it runs > N seconds: edit message to “Still running (45s)…”
  • On tool.end: edit to “Done (52s)” / “Failed: …”
    This also avoids the “typing forever” failure mode when a provider returns an empty response or the gateway restarts mid-turn.
  1. Plan/TODO enforcement without model nagging
  • On “agent begins work” (or first tool call in a turn), require a structured plan exists in state (or prompt the system to request it once), then keep it updated via edits.
  • Important detail: do this as a separate state machine, not “please remember to maintain a TODO list” inside the LLM prompt.

Design nits worth calling out early:

  • Needs a correlation id so you can update the same message across start/end (and handle nested/concurrent tool calls).
  • Must throttle edits (Telegram/Discord both have rate limits).
  • Decide what tool args are safe to show (redaction/summary), otherwise you’ll leak tokens/paths/URLs into chat logs.

If you want this to happen, I’d file it as a feature request with a tight scope like “tool lifecycle hooks + default progress renderer” (and include the Telegram “message edit” behavior as the reference UX): https://github.com/openclaw/openclaw/issues

slender blaze
#

Yes please

paper wagonBOT
#

Yep — and good news: there are already a couple issues adjacent to this, so you can either comment there (to avoid duplicates) or open a new feature issue that references them.

Existing related issues:

Your ask (“hooks like tool:before/tool:after + progress + TODO enforcement”) is broader than typing, so I’d personally file a feature request (or extend #450) framed as tool lifecycle events + default chat renderer.

Here’s a ready-to-paste issue draft:

Title: Tool lifecycle hooks (tool.start/tool.end/tool.progress) + default progress message renderer (edit-in-place)

Problem

  • Typing indicators aren’t sufficient for long tool runs (exec/browser/etc.).
  • Failure modes (agent restart, empty provider response, tool hang) can leave users with “typing forever” and no actionable status.
  • Asking the LLM to emit periodic updates is unreliable + causes context drift.
#

Proposal

  • Emit runtime events around tool execution:
    • tool.start (toolName, callId, timestamp, safe summary)
    • tool.progress (optional; percent/message/log-tail)
    • tool.end / tool.error (duration, status, error summary)
  • Channel adapters implement a default renderer:
    • Post one “Working…” message and edit it in place (Telegram ideal), throttled (e.g. max 1 edit / 2–5s)
    • On end/error, finalize the same message
    • Fallback to new messages only when editing isn’t supported
  • Add redaction/summarization for args (never leak tokens/paths/secrets).

Nice-to-have

  • “Plan/TODO enforcement” as a separate state machine triggered on first tool call in a turn (not prompt nagging).

Acceptance criteria

  • When any tool call starts, user gets visible feedback within ~1s.
  • For tool runs > N seconds, status message updates at a bounded rate.
#
  • On tool completion/error, status message is finalized reliably.
  • Works across Telegram/Discord (best-effort parity).

If you drop that into #450 as a comment, it might be the fastest path (since it’s already “tool execution feedback”). If you create a new issue, link #450/#447 so it’s clearly “superset UX,” not just typing-indicator plumbing.

slender blaze
#

You spoke as if you can file it for me, do I have to create it myself?

paper wagonBOT
#

You’d need to create it yourself, yeah.

I can’t open GitHub issues on your behalf (I’m effectively “read-only” for project operations in this Discord). What I can do is hand you a tight issue title/body (or a comment) so you can paste it in 30 seconds.

Fastest path:

  1. Open this issue (already close to what you want):
    https://github.com/openclaw/openclaw/issues/450

  2. Add a comment with the “superset” feature request (tool lifecycle hooks + edit-in-place progress message), or if you prefer a clean tracker item:

If you tell me:

  • your openclaw --version
  • which channel plugin (Telegram Bot API vs MTProto, etc.)