The worker result and the coordinator response are separate durable facts. The reported local Desktop Bot finished a job, yet the server-side caller waited because delivery of the settled receipt was not triggered; restarting did not reliably drain it. This resembles an orphaned-job problem but does not prove the same software defect in a different system.…
Inspect the ClaimsCase · DiggingBeagle record
Hermes Desktop Bot can strand completed worker results behind a missing relay acknowledgment
A reporter describes work completed by a local Desktop Bot while the coordinating cloud run remains pending and restart fails to reclaim the settled result.
Scope
One public issue and a proposed experimental fix are reported; no upstream merge or widespread prevalence is established.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade D
- AI role
- AGAINST AI
Basis and provenance
The pinned Claim and its primary disclosure support the described controlled result, but do not establish a population-wide rate or calibrated impact. The only available supporting evidence is the reporter's or advisory author's own account; independent reproduction has not been shown. Impact remains unbanded because no calibrated impact rubric for this particular evidence is established.
Assessed Nov 2, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV02-HERMES-DESKTOP-SETTLED-RELAY-A · Hermes Agent issue 147756: settled Desktop Bot replies not recovered
At a glance
Durable acknowledgments and idempotent recovery matter more than a blind retry when a delegated operation may already have committed.
Read the implicationsOne public issue and a proposed experimental fix are reported; no upstream merge or widespread prevalence is established. The report does not establish exactly-once side effects under all reconnect paths or a merged recovery fix.
Limits and uncertaintyFull account
The worker result and the coordinator response are separate durable facts. The reported local Desktop Bot finished a job, yet the server-side caller waited because delivery of the settled receipt was not triggered; restarting did not reliably drain it. This resembles an orphaned-job problem but does not prove the same software defect in a different system. Re-running the task instead of reconciling receipts risks duplicate side effects.
The desktop-side worker can complete an action and persist its local receipt while the coordinator loses the response during the claim or acknowledgment path. A restarted coordinator that does not drain the settled outbox may continue waiting for work already done. This is a more dangerous retry condition than an ordinary failed request: blindly re-executing the command could produce duplicate external effects. The issue uses a harmless local test and does not prove customer transaction duplication, but it exposes the missing distinction between execution completion and delivery of the result.
Mechanism and trust boundary
- 01
Worker completes an assigned task
A local agent records a settled execution receipt.
Boundary: Tool execution into local durable result
- 02
Coordinator misses receipt delivery
A claim or outbox signal times out after the work is already done.
Boundary: Local completion into remote acknowledgment
- 03
Restart does not reconcile the result
The caller remains waiting while the completed work is stored elsewhere.
Boundary: Worker restart into orphaned response state
Claims & evidence
CLM-2026-NOV02-HERMES-DESKTOP-SETTLED-RELAY-AThe issue documents a harmless command result that settled locally but did not reach the coordinator because the expected outbox push or claim acknowledgment was missing.supported
Basis: reported finding
- supportsHermes Agent issue 147756: settled Desktop Bot replies not recoveredprimary disclosure
Issue 147756, completed local receipt, cloud claim timeout and restart behavior
Implications
Durable acknowledgments and idempotent recovery matter more than a blind retry when a delegated operation may already have committed.
Controls and mitigations
- Replay pending outbox receipts on startup, reconcile run IDs against completed local effects and avoid re-execution without an idempotency proof.
- Use durable result IDs and an outbox drain on reconnect; reconcile the already-settled receipt before permitting any retry of a state-changing action.
Unknowns and contradictions
- One public issue and a proposed experimental fix are reported; no upstream merge or widespread prevalence is established.
- The report does not establish exactly-once side effects under all reconnect paths or a merged recovery fix.
Sources and citation
Material revision history
- Nov 2, 2026 · Canonical change recorded · new in release · revision 214