openclaw - 💡(How to fix) Fix IACP thread close-detection: conservative iacp.thread.closed event for cross-agent thread audit [1 comments, 2 participants]

Summary

OpenClaw wake-socket based cross-agent workflows need a conservative operator-visible event for thread closure, primarily for audit and handoff clarity.

Request: add an iacp.thread.closed event emitted only by conservative close detection. False negatives are acceptable; false positives are disruptive.

Proposed event

Event name: iacp.thread.closed

Payload:

{
  "schema": "openclaw.iacp.thread.closed.v1",
  "thread_id": "string",
  "last_wake_id": "string|null",
  "closed_at": "ISO-8601 timestamp",
  "reason": "explicit_marker|idle_timeout",
  "participants": ["string"]
}

Conservative detection

Initial implementation should only emit on explicit close markers in the most recent wake/thread message, such as:

• [THREAD-CLOSED]
• closing thread
• no further blockers
• thread closed

An idle-timeout heuristic may be useful later, but should remain disabled by default and operator-enabled only.

Rationale

Cross-agent wake workflows currently show delivery and injection state, but not a reliable closure marker. A conservative close event gives operator UIs and audit trails a clean lifecycle boundary without guessing from normal conversational text.

The local Smith Crafts patch tracks thread_id -> wake_ids in process memory and emits only on explicit markers. Neutral conversational messages were tested not to emit this event.

Related issues

• Prior wake socket / active-session delivery: #83809
• Wake event bridge and TUI rendering: #84113
• Wake inbox drain durability: #84237