Incident shape
A human approval request can be created correctly, but the runtime selects a presentation path no human can actually reach. The request later times out and is reported as if the human simply did not answer.
That collapses two very different states:
DELIVERED + unanswered
vs
NEVER DELIVERABLE
Concrete reproduction
NousResearch/hermes-agent#120859 (2026-09-24):
NousResearch/hermes-agent#120859
The operator configured a selected approval transport. Some approval paths honored it; protected instruction-file writes and some action gates did not. They fell back to the built-in prompt surface instead.
In the reproducer, the built-in callback intentionally represents a front-end that never draws that panel. The request then waits through the approval timeout and returns a message equivalent to “timed out without a user response / silence is not consent.”
The human was never given a reachable surface.
A follow-up reproduction split this into two code paths and verified which ones consulted the configured transport.
Why this looks like a guardable failure
A useful self-test would deliberately make the configured approval surface unreachable and assert that the system reports undeliverable / no presentation surface immediately (or via a distinct outcome).
The guard should fail if the runtime instead:
- waits for the normal human-response timeout, and
- records the outcome as “unanswered” / “human silence.”
Pseudo-contract:
approval request created
-> chosen surface unreachable
-> expected: UNDELIVERABLE
-> forbidden: UNANSWERED
Related variant
OpenClaw users have also reported routing approvals from Slack-triggered workflows into Telegram because the original channel could not resolve them:
openclaw/openclaw#48529
That is a different implementation, but the same operational question: did the human ignore the request, or did the system fail to put an actionable decision surface where the human was?
If this is outside the catalog's intended scope because the incident did not originate in your own production fleet, closing this is completely fine.
Incident shape
A human approval request can be created correctly, but the runtime selects a presentation path no human can actually reach. The request later times out and is reported as if the human simply did not answer.
That collapses two very different states:
Concrete reproduction
NousResearch/hermes-agent#120859 (2026-09-24):
NousResearch/hermes-agent#120859
The operator configured a selected approval transport. Some approval paths honored it; protected instruction-file writes and some action gates did not. They fell back to the built-in prompt surface instead.
In the reproducer, the built-in callback intentionally represents a front-end that never draws that panel. The request then waits through the approval timeout and returns a message equivalent to “timed out without a user response / silence is not consent.”
The human was never given a reachable surface.
A follow-up reproduction split this into two code paths and verified which ones consulted the configured transport.
Why this looks like a guardable failure
A useful self-test would deliberately make the configured approval surface unreachable and assert that the system reports undeliverable / no presentation surface immediately (or via a distinct outcome).
The guard should fail if the runtime instead:
Pseudo-contract:
Related variant
OpenClaw users have also reported routing approvals from Slack-triggered workflows into Telegram because the original channel could not resolve them:
openclaw/openclaw#48529
That is a different implementation, but the same operational question: did the human ignore the request, or did the system fail to put an actionable decision surface where the human was?
If this is outside the catalog's intended scope because the incident did not originate in your own production fleet, closing this is completely fine.