Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When the agent is mid-work on a user request and its attention is switched to a higher-priority task (e.g. handling a high-frequency hook such as autonomy-guard confirmations, config changes, gateway restarts, other operational tasks), the originally promised output may never be delivered unless the user explicitly asks for progress again.

This happens even without a Gateway restart. It feels like the agent lacks a durable "pending work" queue / task stack, so interruptions silently drop commitments.

Why this matters

• A user can receive "I'll send this when ready" but the follow-up is not sent.
• Hooks like autonomy-guard run at high frequency, increasing interruption rate.
• This degrades trust: dropped commitments look like the agent forgot or ignored the user.

Steps to reproduce

1. In a direct chat (e.g. Telegram), ask the agent to produce a deliverable that takes a few minutes (e.g. "summarize this YouTube video" or "extract transcript + write detailed interpretation").
2. Before the agent sends the final deliverable, trigger an interruption task that has higher urgency/priority, e.g.:
   • adjusting autonomy-guard policy / verifying blocks and allowlists,
   • handling cron delivery failures,
   • operational debugging that requires restarting gateway or checking status,
   • any multi-step tool workflow unrelated to the original request.
3. Observe that the agent completes the interruption task but does not return to deliver the originally promised output.
4. Only after the user asks "progress?" does the agent produce the result.

Expected behavior

• Agent maintains a durable "pending deliverables" stack/queue for each session.
• If a turn commits to deliver an output ("I'll send it when ready"), the system should ensure one of:
  • the reply is actually sent, or
  • the agent explicitly defers with an ETA and automatically resumes, or
  • a reminder mechanism triggers (internal) and prompts the agent to complete/clear the pending item.

Actual behavior

• Interruptions can cause pending deliverables to be silently dropped until user re-prompts.

OpenClaw version

2026.3.12

Operating system

Ubuntu 24.04

Install method

No response

Model

GPT5.2

Provider / routing chain

provider with api key

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Proposed fixes / design ideas

• Pending Deliverables Queue: core runtime tracks "commitments" and requires them to be resolved (sent/deferred/cancelled) before the agent can declare completion.
• Task Stack / Auto-resume: after the interrupting task completes, auto-resume the previous in-flight task unless user cancels.
• Durable TODO integration: provide a first-class persisted TODO list per session, with one-shot reminder scheduling, and/or an API for agents to push items into it.
• Hook-aware scheduling: mark certain hooks (e.g. autonomy-guard) as preemptive but require the agent to persist state before switching.

Environment

• Channel: Telegram
• Frequent interrupter: autonomy-guard policy changes / high-frequency confirmations
• Observed without requiring Gateway restart