Summary

When an exec approval times out and OpenClaw suppresses the stale follow-up, operators need a structured event they can consume from status/inbox surfaces. Today our local deployment patches the Slack/gateway code to append a small log file because the native signal is only a warning line.

Operator impact

Suppressed approval-timeout follow-ups are meaningful operational events: they can explain why an agent is still blocked, why a Slack follow-up did not appear, or why an operator needs to inspect the approval queue. If the only signal is free-form logging, downstream status tools have to scrape logs or miss the condition.

Current local workaround

Our local image patch records suppressed approval-timeout follow-ups to:

<runtimeRoot>/approval-timeouts.log

Then operator-inbox/status code reads that file and surfaces a count/recent work item. This works, but it is a deployment-specific side channel that should be replaceable by the gateway's normal structured event stream.

Proposed native behavior

Emit a structured event on the gateway event/log stream when a stale approval-timeout follow-up is suppressed, for example:

{
  "type": "exec.approval.timeout-suppressed",
  "approvalId": "...",
  "ts": "2026-06-30T00:00:00.000Z"
}

The exact envelope can follow OpenClaw's existing event schema; the important part is a stable event type and enough identifiers/timestamps for operator tooling.

Acceptance criteria

• Suppressed stale approval-timeout follow-ups emit a machine-readable event.
• The event is available through the same structured logs/event stream operators already consume.
• The event includes at least the approval id and timestamp.
• Existing Slack suppression behavior remains unchanged; this only adds observability.