Bug Report
Version: Latest (as of 2026-02-17)
Severity: High — causes runaway token spend
Description
A sessions_spawn subagent completion notification keeps firing every ~5-10 seconds indefinitely after the spawned task completes. The notification is never marked as delivered/acknowledged, creating an infinite loop.
Reproduction
- Spawn a subagent via
sessions_spawn (in our case, task: renzo-fba-price-check, session: c88dd8e0)
- Subagent completes successfully
- Completion notification fires back to the parent session
- Parent session processes notification and responds with
NO_REPLY
- Notification fires again ~5-10 seconds later
- Loop continues indefinitely
Observed Impact
- Notification loop ran for 8+ hours (11:52 PM to 7:53 AM EST, Feb 16-17 2026)
- Hundreds of duplicate
NO_REPLY cycles
- Significant token waste on the parent session
Expected Behavior
Completion notification should fire once, be acknowledged, and not repeat.
Likely Cause
The completion notification delivery/acknowledgment mechanism is not persisting the "delivered" state, so the notification re-enters the queue on each heartbeat or poll cycle.
Environment
- OpenClaw gateway on macOS (Darwin arm64)
- Multiple agent sessions via Slack
- Spawned session completed successfully (no error state)
Bug Report
Version: Latest (as of 2026-02-17)
Severity: High — causes runaway token spend
Description
A
sessions_spawnsubagent completion notification keeps firing every ~5-10 seconds indefinitely after the spawned task completes. The notification is never marked as delivered/acknowledged, creating an infinite loop.Reproduction
sessions_spawn(in our case, task:renzo-fba-price-check, session:c88dd8e0)NO_REPLYObserved Impact
NO_REPLYcyclesExpected Behavior
Completion notification should fire once, be acknowledged, and not repeat.
Likely Cause
The completion notification delivery/acknowledgment mechanism is not persisting the "delivered" state, so the notification re-enters the queue on each heartbeat or poll cycle.
Environment